使用所有静态方法的类有什么问题吗？

Question

我正在进行代码审查,并遇到了一个使用所有静态方法的类.入口方法需要几个参数,然后开始调用其他静态方法传递入口方法接收的全部或部分参数.

它不像Math类具有很大程度上不相关的实用函数.在我自己的正常编程中,我很少编写Resharper弹出的方法并说"这可能是一个静态方法",当我这样做时,它们往往是无意识的实用方法.

这种模式有什么问题吗？如果类的状态保存在字段和属性中,或者使用参数在静态方法中传递,这只是个人选择的问题吗？

更新:传递的特定状态是数据库中的结果集.该类的职责是从DB的结果集中填充Excel电子表格模板.我不知道这有什么不同.

Answer 1

您所描述的只是结构化编程,可以在C,Pascal或Algol中完成.这没有什么本质上的错误.有有情况是OOP是比较合适的,但OOP不是最终答案,如果手头的问题最好是通过结构化编程提供再一类充满了静态方法是要走的路.

Answer 2

这种模式有什么问题吗？如果类的状态保存在字段和属性中,或者使用参数在静态方法中传递,这只是个人选择的问题吗？

从我个人的经验来看,我已经研究了100个KLOC应用程序,这些应用程序具有非常深的对象层次结构,一切都继承并覆盖其他所有内容,一切都实现了六个接口,甚至接口继承了六个接口,系统实现了每一个书中的设计模式等

最终结果:真正的OOP-tastic架构具有如此多的间接层,因此需要花费数小时来调试任何内容.我最近开始使用这样的系统开始工作,其中学习曲线被描述为"砖墙,后面是山".

有时过于热心的OOP会导致课程变得如此精细,以至于它实际上是一种净伤害.

相比之下,许多函数式编程语言,甚至像F#和OCaml(以及C#!)这样的OO都鼓励平坦和浅层的层次结构.这些语言的库往往具有以下属性:

• 大多数对象都是POCO,或者最多只有一个或两个继承级别,其中对象不仅仅是逻辑相关数据的容器.
• 您可以使用模块(相当于静态类)来控制对象之间的交互,而不是相互调用类.
• 模块往往作用于非常有限的数据类型,因此范围很窄.例如,OCaml List模块表示列表上的操作,Customer模块促进对客户的操作.虽然模块与类上的实例方法具有或多或少相同的功能,但与基于模块的库的关键区别在于模块更加自包含,更不精细,并且往往对其他模块具有很少的依赖性.
• 通常不需要子类化对象覆盖方法,因为您可以将函数作为特化的第一类对象传递.
• 虽然C#不支持此功能,但仿函数提供了一种子类化专用模块的方法.

大多数大型库往往比更深,例如Win32 API,PHP库,Erlang BIF,OCaml和Haskell库,数据库中的存储过程等.所以这种编程风格是战斗测试,似乎在现实中.

在我看来,最好设计的基于模块的API往往比最好设计的OOP API更容易使用.但是,编码风格在API设计中同样重要,因此如果团队中的其他人都在使用OOP并且有人以完全不同的方式实现某些内容,那么您应该要求重写以更紧密地匹配您的团队编码标准.

Answer 3

是否有助于重新解释这个问题:

您能否将静态方法操作的数据描述为具有以下内容的实体:

• 一个明确的意思
• 保持内部状态一致的责任.

在这种情况下,它应该是一个实例化的对象,否则它可能只是一堆相关的函数,就像数学库一样.