我正在进行代码审查，发现一个使用所有静态方法的类。入口方法接受多个参数，然后开始调用其他静态方法，传递入口方法接收到的全部或部分参数。
它不像具有很大程度上不相关的实用函数的数学类。在我自己的正常编程中，我很少编写 Resharper 弹出并说“这可能是静态方法”的方法，当我这样做时，它们往往是无意识的实用方法。
这个模式有什么问题吗？如果类的状态保存在字段和属性中或使用参数在静态方法之间传递，这只是个人选择的问题吗？
UPDATE：正在传递的特定状态是来自数据库的结果集。该类的职责是根据数据库的结果集填充 Excel 电子表格模板。我不知道这是否有什么区别。
这有什么问题吗
图案？这只是一个问题吗
个人选择，如果a的状态
类保存在字段和属性中
或在静态中传递
使用参数的方法？
从我自己的个人经验来看，我曾经开发过 100 个 KLOC 应用程序，这些应用程序具有非常非常深的对象层次结构，所有内容都继承并覆盖其他所有内容，所有内容都实现了六个接口，甚至接口继承了六个接口，系统实现了每个接口书中的设计模式等
最终结果：一个真正的 OOP-tastic 架构，具有如此多的间接级别，以至于调试任何东西都需要几个小时。我最近开始使用这样的系统，其中的学习曲线对我来说是“一堵砖墙，后面是一座山”。
有时，过于热心的 OOP 会导致类变得如此精细，以至于实际上是一种净危害。
相比之下，许多函数式编程语言，甚至是面向对象的语言，如 F# 和 OCaml（以及 C#！），都鼓励扁平化和浅层的层次结构。这些语言的库往往具有以下属性：
- 大多数对象都是 POCO，或者最多具有一到两级继承，其中对象只不过是逻辑相关数据的容器。
- 您可以使用模块（相当于静态类）来控制对象之间的交互，而不是类之间相互调用。
- 模块往往作用于非常有限的数据类型，因此范围很窄。例如，OCaml List 模块表示对列表的操作，Customer 模块便于对客户进行操作。虽然模块与类上的实例方法具有或多或少相同的功能，但与基于模块的库的主要区别在于，模块更加独立，粒度更小，并且往往对其他模块有很少的依赖性（如果有的话）。
- 通常不需要子类对象重写方法，因为您可以将函数作为第一类对象传递以进行专门化。
- 虽然C#不支持这个功能，functors https://stackoverflow.com/questions/2370240/would-you-please-explain-ocaml-functors-to-me/2374070#2374070提供一种对专用模块进行子类化的方法。
大多数大型库的广度往往大于深度，例如 Win32 API、PHP 库、Erlang BIF、OCaml 和 Haskell 库、数据库中的存储过程等。因此，这种编程风格是实战测试，并且似乎在以下环境中运行良好：现实世界。
在我看来，设计最好的基于模块的 API 往往比设计最好的 OOP API 更容易使用。然而，编码风格在 API 设计中同样重要，因此，如果团队中的其他人都在使用 OOP，并且有人以完全不同的风格实现某些内容，那么您可能应该要求重写以更紧密地匹配您的团队编码标准。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
