原文地址: http://www.jdon.com/jivejdon/thread/38090
由 Robert Martin提出的S.O.L.I.D 原则,用来更好编写面向对象程序,更灵活应对变化。
S - Single Responsibility Principle 单一职责,简称SRP
这个我前面几篇文章刚刚写:对象的责任与职责
如何从职责和协作中发现丰富对象?
比 如:报表的内容和报表的格式都会变化改变,但是这两种变化的性质不同,一个是实质内在,一个是表面上的,SRP认为这是问题的两个方面,其实代表不同的职 责,应该将它们分离放入不同的类或模块中,而不应该放在一起,否则的话,因为不同原因发生变化,导致对方变动,比如报表格式变新的样式,这个变化是不应该 涉及到内容的。
这个模式和GoF模式中职责链模式Chain-of-responsibility pattern类似,体现了职责分离,分散关注Separation of concerns等OO思想。当然,也只有认识到事物高凝聚Cohesion本质,才能发现耦合。
O - Open/Closed Principle 开闭原则
我一直使用变化和不变来说明,封装不变部分,开放变化部分,一般使用接口继承实现方式来实现“开放”应对变化,说大白话就是:你不是要变化吗?,那么我就让你继承实现一个对象,用一个接口来抽象你的职责,你变化越多,继承实现的子类就越多。
L - Liskov Substitution Principle 里氏替换原则 简称LSP
这是一个针对行为职责可替代的原则,如果S是T的子类型,那么S对象就应该在不改变任何抽象属性情况下替换所有T对象。这里的抽象属性是指对象的字段属性。
我 们使用接口时经常碰到一个问题,需要使用接口子类中的方法,而接口中没有这个方法,那么只能要么修改接口,要么将接口downcast为具体子类。为什么 会出现这个尴尬现象?有几种情况导致,其中一种情况是是将当前的类重构到接口时,没有将类中所有方法extract到接口中,可能因为这些被你漏掉的方法 不属于当前接口,那么,它又违背了单一职责原理,说明你当前这个类的方法设计得又不合理。
所以,如果单一职责设计的足够好,那么LSP原则则是检验的方法。LSP原则是对对象职责和协作的一种检验约束方法,此外还有DBC(design by contract)原则,为了保证实现接口的子类职责行为的约束,DBC三要素都必须被重视满足:
1.Preconditions前置条件不能在子类中被强化。
2.Postconditions后置条件不能在子类中被弱化。
3.子类自身不变性Invariants必须在子类自己中封装满足。这也是前面“不改变任何抽象属性”的意思。
I - Interface Segregation Principle接口分离 简称ISP原则
这 类似General Responsibility Assignment Software Patterns中高凝聚原则 High Cohesion Principle ,这是解决胖接口,接口很大很丰富,就要进行解耦切分,把一个接口切分为多个接口,把一个大的职责切分为小职责以及这些职责之间的协作交互。
切分时必须依据高凝聚原则,单一职责进行切分。
这 个原则起源于施乐公司,他们需要建立了一个新的打印机系统,可以执行诸如装订的印刷品一套,传真多种任务。此系统软件创建从底层开始编制,并实现了这些任 务功能,但是不断增长的软件功能却使软件本身越来越难适应变化和维护。每一次改变,即使是最小的变化,有人可能需要近一个小时的重新编译和重新部署。这是 几乎不可能再继续发展,所以他们聘请罗伯特Robert帮助他们。
他们首先设计了一个主要类Job,几乎能够用于实现所有任务功能. 只要调用Job类的一个方法就可以实现一个功能,Job类就变动非常大,是一个胖模型啊,对于客户端如果只需要一个打印功能,但是其他无关打印的方法功能 也和其耦合,ISP原则建议在客户端和Job类之间增加一个接口层,对于不同功能有不同接口,比如打印功能就是Print接口,然后将大的Job类切分为 继承不同接口的子类,这样有一个Print Job类,等等。
D - Dependency Inversion Principle 依赖反转原则 DIP
a.高级别模块不应依赖于低层次的模块。双方应依赖于抽象。
b.抽象不应当取决于细节。细节应该依赖抽象。
Dependency Injection 依赖注入模式也是属于这种类型变种,GoF设计模式中适配器模式中,高层次类只依赖于adapter接口. 而被适配者低层次也只依赖adapter接口。
SOLID原则如今在DCI架构中能够得到真正实现和发展。