《设计模式六大原则》由会员分享，可在线阅读，更多相关《设计模式六大原则（22页珍藏版）》请在金锄头文库上搜索。
1、设计模式六大原则单一职责原则(Single Responsibility Principle定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。问题由来：类T负责两个不同的职责：职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T 时，有可能会导致原本运行正常的职责P2功能发生故障。解决方案：遵循单一职责原则。分别建立两个类T1、T2,使T1完成职责P1功能，T2完成职责P2功能。 这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风 险。说到单一职责原则，很多人都会不屑一顾。因为它太简单了。稍有经验的程序员即使从来没有
2、读 过设计模式、从来没有听说过单一职责原则，在设计软件时也会自觉的遵守这一重要原则，因为这是常识。 在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便 是遵循单一职责原则。虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写 出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？因为有职责扩散。所谓职责扩散， 就是因为某种原因，职责P被分化为粒度更细的职责P1和P2。比如：类T只负责一个职责P,这样设计是符合单一职责原则的。后来由于某种原因，也许是需 求变更了，也许是程序的设计者境界提高了，需要将职责P细分为粒度更细的职责
3、P1, P2,这时如果要 使程序遵循单一职责原则，需要将类T也分解为两个类T1和T2,分别负责P1、P2两个职责。但是在程序 已经写好的情况下，这样做简直太费时间了。所以，简单的修改类T,用它来负责两个职责是一个比较不 错的选择，虽然这样做有悖于单一职责原则。举例说明，用一个类描述动物呼吸这个场景：class Animalpublic void breathe(String animal)Systemout .println(animal+呼吸空气);public class Clientpublic static void main(String args)Animal animal =ne
4、w Animal();animal.brea the牛)；animal.brea the羊)；animal.brea the猪)；运行结果：牛呼吸空气羊呼吸空气猪呼吸空气程序上线后，发现问题了，并不是所有的动物都呼吸空气的，比如鱼就是呼吸水的。修改时如果遵循单一 职责原则，需要将Animal类细分为陆生动物类Terrestrial，水生动物Aquatic，代码如下：class Terrestrialpublic void breathe(String animal)Systemou亡.println(animal+呼吸空气);class Aquaticpublic void breathe(S
5、tring animal)Systemou亡.println(animal+呼吸水);public class Clientpublic static void main(String args)Terrestrial terrestrial =new Terrestrial();terrestrial.breathe牛)；terrestrial.breathe羊)；terrestrial.breathe猪)；Aquatic aquatic =new Aquatic();aqua tic.brea the鱼)；运行结果：牛呼吸空气羊呼吸空气猪呼吸空气鱼呼吸水我们会发现如果这样修改花销是很大的，
6、除了将原来的类分解之外，还需要修改客户端。 而直接修改类Animal来达成目的虽然违背了单一职责原则，但花销却小的多，代码如下：class Animalpublic void breathe(String animal)if (鱼.equals(animal)Syste: ou亡.println(animal+ 呼吸水);elseSyste: ou亡.println(animal+ 呼吸空气);public class Clientpublic static void main(String args)Animal animal =new Animal();animal.brea the牛)；
7、animal.brea the羊)；animal.brea the猪)；animal.brea the鱼)；可以看到，这种修改方式要简单的多。但是却存在着隐患：有一天需要将鱼分为呼吸淡水 的鱼和呼吸海水的鱼，则又需要修改Animal类的breathe方法，而对原有代码的修改会对调 用“猪” “牛” “羊”等相关功能带来风险，也许某一天你会发现程序运行的结果变为“牛呼吸 水”了。这种修改方式直接在代码级别上违背了单一职责原则，虽然修改起来最简单，但隐患却 是最大的。还有一种修改方式：class Animalpublic void breathe(String animal)Systemou亡.p
8、rintln(animal+呼吸空气);public void breathe2(String animal)Systemou亡.println(animal+呼吸水);public class Clientpublic static void main(String args)Animal animal =new Animal();animal.brea the牛）；animal.brea the羊）；animal.brea the猪）； animal.brea the2鱼）；可以看到，这种修改方式没有改动原来的方法，而是在类中新加了一个方法，这样虽然也 违背了单一职责原则，但在方法级别上却
9、是符合单一职责原则的，因为它并没有动原来方法的代 码。这三种方式各有优缺点，那么在实际编程中，采用哪一中呢？其实这真的比较难说，需要根 据实际情况来确定。我的原则是：只有逻辑足够简单，才可以在代码级别上违反单一职责原则； 只有类中方法数量足够少，才可以在方法级别上违反单一职责原则；例如本文所举的这个例子，它太简单了，它只有一个方法，所以，无论是在代码级别上违反 单一职责原则，还是在方法级别上违反，都不会造成太大的影响。实际应用中的类都要复杂的多， 一旦发生职责扩散而需要修改类时，除非这个类本身非常简单，否则还是遵循单一职责原则的好。遵循单一职责原的优点有： 可以降低类的复杂度，一个类只负责一项
10、职责，其逻辑肯定要比负责多项职责简单的多；提高类的可读性，提高系统的可维护性； 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都需 要遵循这一重要原则。里氏替换原则（Liskov Substitution Principle肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则 最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。定义1如果对每一个类型为T1的对象01,都有类型
11、为T2的对象02,使得以T1定义的所有程序P在 所有的对象01都代换成02时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。定义2：所有引用基类的地方必须能透明地使用其子类的对象。问题由来：有一功能P1,由类A完成。现需要将功能P1进行扩展，扩展后的功能为P,其中P由原有功 能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会 导致原有功能P1发生故障。解决方案：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外， 尽量不要重写父类A的方法，也尽量不要重载父类A的方法。继承包含这样一层含义：父类中凡是已经实现好
12、的方法（相对于抽象方法而言），实际上是在设 定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方 法任意修改，就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。比如使用继承 会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则 当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生 故障。举例说明继承的风险，我们需要完成一个两数相减的功能，由类A来负责。class Apublic int
13、func1(int a, int b)return a-b;public class Clientpublic static void main(String args)A a =new A();Systemou亡.println(100-50=+a.func1(100, 50);Systemou亡.println(100-80=+a.func1(100, 80);运行结果：100-50=50100-80=20后来，我们需要增加一个新的功能：完成两数相加，然后再与100求和，由类B来负责。即类B需要 完成两个功能： 两数相减。 两数相加，然后再加100。由于类A已经实现了第一个功能，所以类B继
14、承类A后，只需要再完成第二个功能就可以了，代码 如下：class B extends Apublic int func1(int a, int b)return a+b;public int func2(int a, int b)return func1(a,b)+100;public class Clientpublic static void main(String args)B a =new B();Systemou亡.println(100-50=+b.func1(100, 50);Systemou亡.println(100-80=+b.func1(100, 80);System.ou
15、t.println100+20+100=+b.func2(100, 20);类B完成后，运行结果：100-50=150100-80=180100+20+100=220我们发现原本运行正常的相减功能发生了错误。原因就是类B在给方法起名时无意中重写了父类的方 法，造成所有运行相减功能的代码全部调用了类B重写后的方法，造成原本运行正常的功能出现了错误。 在本例中，引用基类A完成的功能，换成子类B之后，发生了异常。在实际编程中，我们常常会通过重写 父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用 多态比较频繁时，程序运行出错的几率非常大。如果非要重写父类的方法，比较通用的做法是：原来的父 类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合，组合等关系代替。里氏替换原则通俗的来讲就是：子类可以扩展父类
