开放封闭原则说使用抽象/策略设计模式，这样我们就不需要改变现有代码，我完全理解。当我看到例子时，似乎很容易。但在现实生活中，会有很多域对象，如果我们使用Open closed原则，我最终将会有数千个类。
我的问题是，人们是否遵循这个大项目并创建了这么多课程？
如果所有业务逻辑都转到域对象，那么我很困惑，人们在服务类中编写的逻辑是什么（通过服务类，我的意思是服务层中的类（web-＆gt; service-＆gt; dao）。为愚蠢的问题道歉，但我很好奇在复杂的大项目中设计的标准方法是什么。
答案 0 :(得分：2)
这些当然不是愚蠢的问题，让我尽力为你解答。
关于开放式原则，它与特定的设计模式或其他模式无关，而是与类应该为扩展打开并关闭以进行修改的一般概念。
项目中的课程数量不应该吓倒你。不幸的是，我曾在许多课程被认为是坏事的公司工作过（＃34;很难遵循代码......＆＃34;，＆＃34;知识基础太大......＆＃34;，以及其他荒谬的想法。）
事实是，当你的班级很少时，他们很可能是大班，因为所有的商业逻辑都必须去某个地方，对吧？这通常（几乎总是）意味着你的每个类都在做很多事情。当然，通过在每个课程中做这么多，你打破了单一责任原则（又名SRP，另一个非常重要的OOP原则），这使得系统更难维护，而且代码库更难理解。 / p>
关于现实生活中的情况，没有人回答。我有机会为真正关心面向对象原则的公司工作，并严格执行它们（好！），也适用于那些仍然处于程序编码风格的公司（不太好......）。所有这些公司都是有利可图的，交付给客户等。不同之处在于，在后一类公司中，将代码理解为新的（甚至是经验丰富的）员工要困难得多，而且要困难得多。改变它（更不用说测试它了。）
关于您关于服务层实现的其他问题，我可以从我自己的经验证明，通常服务层本身非常薄。通常，实现服务层接口的类使用一个或多个业务对象来完成工作，基本上导致非常短且连贯的方法（好！）。这也是OOP原理的一个很好的例子，这次是Inversion-of-Control（又名IoC），因为服务层实现中的一个好习惯是将所有业务对象注入其中，而不是在构造函数中创建它们。
希望这能回答你的问题。