在您的软件项目中使用"Utils"类是否很好？

Question

通常,在软件开发过程中,我需要各种实用功能.像压缩文件一样,提取zip文件,启动Web浏览器,获得缩放图像...

我所做的是,我将所有这些实用程序函数作为静态函数放在名为"Utils"的单个类中

这是一个好习惯吗？当函数的数量越来越大时,事情会变得无法管理吗？

Answer 1

绝对是最好的做法!您不希望将所有这些实用程序功能与其他应用程序业务逻辑混合使用.但是,随着您的utils文件和/或类的增长,建议根据它们提供的功能对它们进行分组.

例如,在Web应用程序中,您最终可能会得到这样的包结构.

org.sample.web.model
org.sample.web.utils
org.sample.web.validators
org.sample.web.validators.utils

Answer 2

是的,实用程序类是一个好主意,但是,与所有面向对象的编程一样,您应该以最大的内聚力,最小的耦合为目标.

最大内聚意味着单个类中的所有内容都应该彼此密切相关.最小耦合意味着类之间不应存在不必要的依赖关系.

换句话说,将压缩与图像处理结合在一起或在单个类中启动外部进程是一个坏主意.无论如何都有一个压缩实用程序类和一个图像处理实用程序类,但不要将它们放在一起.

这样做类似于使用单身模式作为上帝对象,一个贫民窟,你只需要倾倒所有应该更好组织的垃圾.我想说在开发过程中使用超级实用程序类是可以的,但要确保在发货之前更好地组织代码.维护将更容易.

这是一个好习惯吗？

不,从长远来看,虽然临时完成时很有用.

当函数的数量越来越大时,事情会变得无法管理吗？

是的,毫无疑问.

Answer 3

不,我认为公用事业课程不是一个好习惯.从语境学的角度来看,"公用事业"这个词过于宽泛,即使你把它分成多个类别,也只会成为一个倾向于"太难"以适应正确的类设计的东西.

举个例子来看一个伪虚构的StringUtils类.您可以使用数百种方法对不同的方案进行编码/解码,大小写转换,处理空白等.我认为更好的方法是使用策略模式来处理这些转换,这甚至可能允许客户端的可能性代码引入新的转换而无需编辑/重新编译原始代码.您将获得更强大,更灵活,更易维护的系统.