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

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

最终结果：一个真正的面向OOP的架构，具有如此多的间接级别，因此调试任何东西都需要数小时。我最近开始使用这样的系统工作，在我看来，学习曲线被描述为“一堵砖墙，然后是一座山”。

有时，过度狂热的OOP会导致类过于精细，以至于实际上造成了净危害。

相比之下，许多功能性编程语言，甚至是F＃和OCaml（以及C＃！）之类的OO语言，都鼓励扁平和浅层次的学习。这些语言的库通常具有以下属性：

• 大多数对象是POCO，或具有最多一或两个继承级别，其中这些对象只不过是逻辑相关数据的容器而已。
• 您可以使用模块（等同于静态类）来控制对象之间的交互，而不必彼此调用。
• 模块倾向于作用于数量非常有限的数据类型，因此范围很窄。例如，“ OCaml列表”模块表示对列表的操作，“客户”模块可简化对客户的操作。尽管模块具有与类上的实例方法大致相同的功能，但是与基于模块的库的主要区别在于模块更加独立，不那么精细，并且对其他模块的依赖很少。
• 通常不需要子类的对象重写方法，因为您可以将函数作为一流对象进行传递以进行专门化。
• 尽管C＃不支持此功能，但函子提供了一种对专业化模块进行子类化的方法。

大多数大型库往往比深度库更广泛，例如Win32 API，PHP库，Erlang
BIF，OCaml和Haskell库，数据库中的存储过程等。因此，这种编程风格经过了严格的测试，并且在现实中。

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