java在现实生活中设计开放封闭原则

Question

开放封闭原则说，使用抽象/策略设计模式，这样我们就不需要改变现有的代码，我完全理解这一点。当我看到例子时，似乎很容易。但在现实生活中，会有大量的领域对象，如果我们使用开放封闭原则，我将得到数以千计的类。

我的问题是，人们会在大型项目中遵循这个原则并创建这么多的类吗？

另外，如果所有的业务逻辑都流向域对象，那么人们在服务类中编写的逻辑是什么(所谓的服务类，我指的是服务层中的类(web-> service ->dao)。我为愚蠢的问题道歉，但我很好奇在复杂的大型项目中设计的标准方法是什么。

Answer 1

这些问题当然不是愚蠢的问题，让我尽我所能为你解答。

关于开放-关闭原则，它与特定的设计模式或另一种设计模式无关，而是与类应该开放以供扩展和关闭以进行修改这一一般概念有关。

你在一个项目中拥有的类的数量不应该吓倒你。不幸的是，我曾在许多被认为是坏事的公司工作(“很难遵循代码.”、“知识库太大.”以及其他类似的荒谬想法)。

事实是，当你没有几个类时，它们很可能是大类，因为所有的业务逻辑都必须去某个地方，对吗？这通常(几乎总是)意味着您的每个类都在做很多事情。当然，通过在每个类中做这么多工作，您违反了单个责任原则(也就是SRP，另一个非常重要的OOP原则)，这使得系统更难维护，代码基础更难理解。

关于现实生活中的情况，没有一个答案。我有机会为那些真正关心面向对象原则并严格执行这些原则的公司工作(很好!)，也有机会为那些仍然坚持过程编码风格的公司工作(不太好……)。所有这些公司都是盈利的，交付给客户等等。不同的是，在后一类公司中，将代码理解为新员工(甚至是经验丰富的员工)要困难得多，而且更改代码要困难得多(更不用说测试代码了)。

关于您关于服务层实现的另一个问题，我可以从我自己的经验中证明，通常服务层本身非常薄。通常，实现服务层接口的类使用内部的一个或多个业务对象来完成任务，基本上会产生非常简短和一致的方法(很好!)。这也是OOP原理的一个很好的例子，这次是控制反转( IoC)，因为服务层实现中的一个好做法是将所有业务对象注入到它，而不是在构造函数中创建它们。

希望这能回答你的问题。