使用所有静态方法的类有什么问题吗？ [英] Is there anything wrong with a class with all static methods?

问题描述

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

I'm doing code review and came across a class that uses all static methods. The entrance method takes several arguments and then starts calling the other static methods passing along all or some of the arguments the entrance method received.

它不像Math类与实用功能基本无关。在我自己的正常编程中，我很少编写Resharper弹出的方法并说这可能是一个静态方法，当我这样做时，它们往往是无意识的实用方法。

It isn't like a Math class with largely unrelated utility functions. In my own normal programming, I rarely write methods where Resharper pops and says "this could be a static method", when I do, they tend to be mindless utility methods.

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

Is there anything wrong with this pattern? Is this just a matter of personal choice if the state of a class is held in fields and properties or passed around amongst static methods using arguments?

UPDATE ：传递的特定状态是数据库中的结果集。该类的职责是从数据库的结果集中填充Excel电子表格模板。我不知道这是否有任何区别。

UPDATE: the particular state that is being passed around is the result set from the database. The class's responsibility is to populate an excel spreadsheet template from a result set from the DB. I don't know if this makes any difference.

推荐答案

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

Is there anything wrong with this pattern? Is this just a matter of personal choice if the state of a class is held in fields and properties or passed around amongst static methods using arguments?

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

Speaking from my own personal experience, I've worked on 100 KLOC applications which have very very deep object hiearchies, everything inherits and overrides everything else, everything implements half a dozen interfaces, even the interfaces inherit half a dozen interfaces, the system implements every design pattern in the book, etc.

最终结果：一个真正的OOP-tastic架构如此多的间接级别，调试任何东西需要几个小时。我最近开始使用这样的系统开始工作，其中学习曲线被描述为砖墙，后面是一座山。

End result: a truly OOP-tastic architecture with so many levels of indirection that it takes hours to debug anything. I recently started a job with a system like this, where the learning curve was described to me as "a brick wall, followed by a mountain".

有时过于热心的OOP结果在类中如此精细以至于它实际上是一个净损害。

Sometimes overzealous OOP results in classes so granular that it actually a net harm.

相比之下，许多函数式编程语言，甚至像F＃和OCaml（以及C＃！）这样的OO都鼓励平和浅层的。这些语言的库往往具有以下属性：

By contrast, many functional programming languages, even the OO ones like F# and OCaml (and C#!), encourage flat and shallow hiearchy. Libraries in these languages tend to have the following properties:

• 大多数对象是POCO，或者最多只有一个或两个继承级别，其中对象只不过是逻辑相关数据的容器。


• 除了相互调用的类之外​​，还有控制对象之间交互的模块（相当于静态类）。 li>
  
• 模块往往会对数量非常有限的数据类型起作用，因此范围很窄。例如，OCaml List模块表示列表上的操作，Customer模块促进对客户的操作。虽然模块与类上的实例方法具有或多或少相同的功能，但与基于模块的库的关键区别在于模块更加自包含，更不精细，并且往往对其他模块具有很少的依赖性。


• 通常不需要子类化对象覆盖方法，因为你可以将函数作为特化的第一类对象传递。


• 虽然C＃没有支持此功能，仿函数提供了一种手段子类化专门化模块。

• Most objects are POCOs, or have at most one or two levels of inheritance, where the objects aren't much more than containers for logically related data.
• Instead of classes calling into each other, you have modules (equivalent to static classes) controlling the interactions between objects.
• Modules tend to act on a very limited number of data types, and so have a narrow scope. For example, the OCaml List module represents operations on lists, a Customer modules facilitates operations on customers. While modules have more or less the same functionality as instance methods on a class, the key difference with module-based libraries is that modules are much more self-contained, much less granular, and tend to have few if any dependencies on other modules.
• There's usually no need to subclass objects override methods since you can pass around functions as first-class objects for specialization.
• Although C# doesn't support this functionality, functors provide a means to subclass an specialize modules.

大多数大型库往往比更深层更宽，例如Win32 API，PHP库，Erlang BIF，OCaml和Haskell库，数据库中的存储过程等。所以这种编程风格是战斗测试，似乎在现实世界中运行良好。

Most big libraries tend to be more wide than deep, for example the Win32 API, PHP libraries, Erlang BIFs, OCaml and Haskell libraries, stored procedures in a database, etc. So this style of programming is battle testing and seems to work well in the real world.

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

In my opinion, the best designed module-based APIs tend to be easier to work with than the best designed OOP APIs. However, coding style is just as important in API design, so if everyone else on your team is using OOP and someone goes off and implements something in a completely different style, then you should probably ask for a rewrite to more closely match your teams coding standards.

这篇关于使用所有静态方法的类有什么问题吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！