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

时间:2014-04-03 04:41:35

标签: java

开放封闭原则说使用抽象/策略设计模式,这样我们就不需要改变现有代码,我完全理解。当我看到例子时,似乎很容易。但在现实生活中,会有很多域对象,如果我们使用Open closed原则,我最终将会有数千个类。

我的问题是,人们是否遵循这个大项目并创建了这么多课程?

如果所有业务逻辑都转到域对象,那么我很困惑,人们在服务类中编写的逻辑是什么(通过服务类,我的意思是服务层中的类(web-> service-> dao)。为愚蠢的问题道歉,但我很好奇在复杂的大项目中设计的标准方法是什么。

1 个答案:

答案 0 :(得分:2)

这些当然不是愚蠢的问题,让我尽力为你解答。

关于开放式原则,它与特定的设计模式或其他模式无关,而是与类应该为扩展打开并关闭以进行修改的一般概念。

项目中的课程数量不应该吓倒你。不幸的是,我曾在许多课程被认为是坏事的公司工作过(#34;很难遵循代码......","知识基础太大......",以及其他荒谬的想法。)

事实是,当你的班级很少时,他们很可能是大班,因为所有的商业逻辑都必须去某个地方,对吧?这通常(几乎总是)意味着你的每个类都在做很多事情。当然,通过在每个课程中做这么多,你打破了单一责任原则(又名SRP,另一个非常重要的OOP原则),这使得系统更难维护,而且代码库更难理解。 / p>

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

关于您关于服务层实现的其他问题,我可以从我自己的经验证明,通常服务层本身非常薄。通常,实现服务层接口的类使用一个或多个业务对象来完成工作,基本上导致非常短且连贯的方法(好!)。这也是OOP原理的一个很好的例子,这次是Inversion-of-Control(又名IoC),因为服务层实现中的一个好习惯是将所有业务对象注入其中,而不是在构造函数中创建它们。

希望这能回答你的问题。