java设计模式--七大原则
2016-05-14 20:45:38
设计模式到底是五大、六大还是七大，一直傻傻分不清楚，网上总是有说那些原则可以归为一个，我纠结了半天，突然发现自己是舍本逐末了，只要清楚这些原则的设计思想，其他的理解自然是水到渠成。
1、开放-封闭原则
2、单一职责原则
3、里氏代换原则
4、依赖倒转原则
5、迪米特法则
6、接口隔离原则
7、合成/聚合复用原则
一、开放封闭原则（open-closed principle）
一个软件实体应当对外拓展开放，对修改关闭。
在设计一个模块时，应当使得这个模块可以在不被修改的前提下被扩展。也就是说，应当可以在不必修改源代码的情况下修改这个模块的行为。
设计的目的便在于面对需求的改变而保持系统的相对稳定，从而使得系统可以很容易的从一个版本升级到另一个版本。
例子：银行业务员
先前的模式：
每个银行业务员都要负责储户的付款、取款、转账等业务，当业务变更时，所有银行业务员的职责都要发生变化，业务少了自然能够轻松，业务多了所有人都要培训，拓展性不好，而通常来说，储户的需求是不断增加的。
/* * 银行业务员 */ public class BankWorker { //负责存款业务 public void saving() { System.out.println("进行存款操作"); } //负责取款业务 public void drawing() { System.out.println("进行取款操作"); } //负责转账业务 public void zhuanzhang() { System.out.println("进行转账操作"); } //负责基金的申购 public void jijin() { System.out.println("进行基金申购操作"); } }
public class MainClass { public static void main(String[] args) { BankWorker bankWorker = new BankWorker(); //存款 bankWorker.saving(); //取款 bankWorker.drawing(); //转账 bankWorker.zhuanzhang(); //基金 bankWorker.jijin(); } }
修改后的模式:
一个银行业务员专门负责一个业务，非常方便业务的增加，只要继续安排对应的银行业务员即可。
/* * 银行业务员接口，是所有银行业务员的抽象父类。 */ public interface BankWorker { public void operation(); }
/* * 负责取款业务的业务员 */ public class DrawingBankWorker implements BankWorker{ public void operation() { System.out.println("进行取款操作"); } }
/* * 负责存款业务的业务员 */ public class SavingBankWorker implements BankWorker { public void operation() { System.out.println("进行存款操作"); } }
/* * 负责转账业务的业务员 */ public class ZhuanZhangBankWorker implements BankWorker { public void operation() { System.out.println("进行转账操作"); } }
/* * 负责基金业务的业务员 */ public class JiJinBankWorker implements BankWorker { public void operation() { System.out.println("进行基金申购操作"); } }
public class MainClass { public static void main(String[] args) { BankWorker bankWorker = new SavingBankWorker(); bankWorker.operation(); BankWorker bankWorker2 = new DrawingBankWorker(); bankWorker2.operation(); BankWorker bankWorker3 = new ZhuanZhangBankWorker(); bankWorker3.operation(); BankWorker bankWorker4 = new JiJinBankWorker(); bankWorker4.operation(); } }
当需求变化时，不是修改原来代码，而是通过添加代码实现。这样，程序的扩展性好，也易于维护和升级，而具体想要达到这样的效果，需要使用接口和抽象类：将那些无法封闭的变化抽象出来，进行隔离，允许拓展。
开放封闭原则的优越性：
1.通过扩展已有的软件系统，可以提供新的行为，以满足对软件的新需求，使变化中的软件有一定的适应性和灵活性。
2.已有的软件模块，特别是最重要的抽象模块不能再修改，这就使变化中的软件系统有一定的稳定性和延续性。
二、单一职责原则（single resposibility principle）
就一个类而言，应该仅有一个引起它变化的原因。
每一个职责都是一个变化的轴线，当需求变化时会反映为类的职责的变化。如果一个类承担的职责多于一个，那么引起它变化的原因就有多个。一个职责的变化甚至可能会削弱或者抑制类完成其他职责的能力，从而导致脆弱的设计。像山寨手机，有很多功能，如拍照、摄像、手机游戏、网络摄像头、GPS、炒股等等。虽然功能多，但是每一个功能都不强。
如果一个类里面有各种各样的代码，什么算法、数据库访问之类的都写在一起，这样无论任何需求要来，都需要更改这个类，维护麻烦，复用不可能，也缺乏灵活性。
例子：接受客户端输入并提交到数据库。
原有设计：
一个类负责接受客户端输入，对客户端输入进行校验，连接数据库，并提交数据到数据库。
import java.util.Scanner; public class SaveToDB { private String username; private String upassword; //获得客户端输入 public void shuru() { Scanner scanner = new Scanner(System.in); System.out.println("请输入用户名"); username = scanner.nextLine(); System.out.println("请输入密码"); upassword = scanner.nextLine(); } //进行数据校验 public boolean validate() { if(username == null || "".equals(username.trim())) { //trim()方法删除字符串起始和结尾的空格，返回调用字符串对象的一个副本 System.out.println("用户名不能为空"); return false; } if(upassword == null || "".equals(upassword.trim())) { System.out.println("密码不能为空"); return false; } return true; } //连接数据库 public void getConnection() { System.out.println("获得数据库连接"); } //进行数据操作 public void save() { System.out.println("将" + username + "保存到了数据库"); System.out.println("将" + upassword + "保存到了数据库"); } }
import java.util.Scanner; public class MainClass { public static void main(String[] args) { //接受客户端的输入 SaveToDB std = new SaveToDB(); std.shuru(); if(std.validate()) { std.getConnection(); std.save(); } } }
现有设计：
一个功能也就是一个职责由一个类来负责。
import java.util.Scanner; public class Input { private String username; private String upassword; //获得客户端输入 public void shuru() { Scanner scanner = new Scanner(System.in); System.out.println("请输入用户名"); username = scanner.nextLine(); System.out.println("请输入密码"); upassword = scanner.nextLine(); } public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } public String getUpassword() { return upassword; } public void setUpassword(String upassword) { this.upassword = upassword; } }
public class Validator { //进行数据校验 public boolean validate(String username, String upassword) { if(username == null || "".equals(username.trim())) { System.out.println("用户名不能为空"); return false; } if(upassword == null || "".equals(upassword.trim())) { System.out.println("密码不能为空"); return false; } return true; } }
public class DBManager { //连接数据库 public static void getConnection() { System.out.println("获得数据库连接"); } }
public class DAOImp { //进行数据操作 public void save(String username,String upassword) { System.out.println("将" + username + "保存到了数据库"); System.out.println("将" + upassword + "保存到了数据库"); } }
public class MainClass { public static void main(String[] args) { Input input = new Input(); input.shuru(); Validator validator = new Validator(); if(validator.validate(input.getUsername(), input.getUpassword())){ DBManager.getConnection(); DAOImp dao = new DAOImp(); dao.save(input.getUsername(), input.getUpassword()); } } }
三、里氏代换原则（Liskov substitution principle）
里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化，而里氏代换原则是对实现抽象化的具体步骤的规范。
LSP是继承复用的基石，一个软件实体如果使用的是一个基类的话，那么一定适用于其子类，而且察觉不出基类和子类对象的区别。也就是说，在软件里面，把基类替换成它的子类，程序的行为没有变化，软件单位的功能不会受到影响。这样基类才能真正被复用，而子类也能够在基类的基础上增加新的行为。但是，反过来的代换不成立，也就是说，一个软件实体如果使用的是一个子类的话，那么它不能适用于其基类。
例子1：人和男人
public class Person { public void display() { System.out.println("this is a person"); } }
public class Man extends Person { public void display() { System.out.println("this is a man"); } }
public class MainClass { public static void main(String[] args) { Person person = new Person(); display(person); Man man = new Man(); display(man); } public static void display(Person person) { person.display(); } }
显然，方法display既适用于父类Person，又适用于子类Man。但如果将方法display(Person person)修改为以下形式，只能接受子类Man。
public static void display(Man person) { person.display(); }
例子2：长方形和正方形
长方形有两个属性：width height；正方形有一个属性：side。正方形不是长方形的子类，可以将他们看成两个独立的类。
如果我们强制正方形继承长方形，
public class ChangFX { private long width; private long height; public long getWidth() { return width; } public void setWidth(long width) { this.width = width; } public long getHeight() { return height; } public void setHeight(long height) { this.height = height; } }
public class ZhengFX implements ChangFX{ private long side; public long getHeight() { return this.getSide(); } public long getWidth() { return this.getSide(); } public void setHeight(long height) { this.setSide(height); } public void setWidth(long width) { this.setSide(width); } public long getSide() { return side; } public void setSide(long side) { this.side = side; } }
public class MainClass { public static void main(String[] args) { ChangFX changfx = new ChangFX(); changfx.setHeight(10); changfx.setWidth(20); test(changfx); ZhengFX zhengfx = new ZhengFX(); zhengfx.setHeight(10); zhengfx.setWidth(20); test(zhengfx); } public static void test(ChangFX changfx) { System.out.println(changfx.getHeight()); System.out.println(changfx.getWidth()); } }
这样骗过了java编译器，但是上述定义的长方形和正方形并不是真的符合里氏代换原则，不妨在MainClass中增加下面方法，程序会陷入死循环中。
public static void resize(Changfx changfx) { while(changfx.getHeight() <= changfx.getWidth()) { changfx.setHeight(changfx.getHeight() + 1); test(changfx); } }
如果我们构造一个抽象的四边形类，里面只有取width和height的抽象方法，没有对width和height赋值的方法，让长方形和正方形都是四边形的子类，这样LSP就不会被破坏。
public interface Sibianxing { public long getWidth(); public long getHeight(); }
public class ChangFX implements Sibianxing{ private long width; private long height; public long getWidth() { return width; } public void setWidth(long width) { this.width = width; } public long getHeight() { return height; } public void setHeight(long height) { this.height = height; } }
public class ZhengFX implements Sibianxing{ private long side; public long getHeight() { return this.getSide(); } public long getWidth() { return this.getSide(); } public void setHeight(long height) { this.setSide(height); } public void setWidth(long width) { this.setSide(width); } public long getSide() { return side; } public void setSide(long side) { this.side = side; } }
public class MainClass { public static void main(String[] args) { ChangFX changfx = new ChangFX(); changfx.setHeight(10); changfx.setWidth(20); test(changfx); ZhengFX zhengfx = new ZhengFX(); zhengfx.setHeight(10); test(zhengfx); } public static void test(Sibianxing sibianxing) { System.out.println(sibianxing.getHeight()); System.out.println(sibianxing.getWidth()); } }
例子3：鸟和企鹅
public interface Bird { public void fly(); }
public class Laoying implements Bird { public void fly() { System.out.println("老鹰在飞"); } }
public class Maque implements Bird { public void fly() { System.out.println("麻雀在飞"); } }
public class Qie{ public void fly(){ //企鹅不会飞 } }
public class MainClass { public static void main(String[] args) { fly(new Laoying()); fly(new Maque()); fly(new Qie()); } public static void fly(Bird bird) { bird.fly(); } }
可以看到企鹅虽然属于鸟类，但并不会飞，不必强求它实现上述定义的Bird接口。这里的企鹅和鸟之间不存在里氏代换原则。
四、依赖倒转原则（dependency inversion principle）
传统的过程式设计倾向于使高层次的模块依赖于低层次的模块，抽象层依赖于具体层
倒转后：
依赖倒转是开-闭原则的基础，具体内容是：
1.抽象不应该依赖于细节（具体），细节（具体）应该依赖于抽象。
2.高层模块不依赖底层模块，两者都依赖抽象。
例子： 组装电脑
/* * 主板抽象类 */ public abstract class MainBoard { public abstract void doSomething(); }
/* * 华硕主板 */ public class HuaShuoMainBoard extends MainBoard{ public void doSomething() { System.out.println("this is huashuoMainBoard"); } }
/* * 微星主板 */ public class WeiXingMainBoard extends MainBoard { public void doSomething() { System.out.println("this is weixingMainBoard"); } }
/* * 硬盘的抽象类 */ public abstract class HardDisk { public abstract void doSomething(); }
/* * 希捷硬盘 */ public class XiJieHardDisk extends HardDisk { public void doSomething() { System.out.println("this is xijieHardDisk"); } }
/* * 西数硬盘 */ public class XiShuHardDisk extends HardDisk { public void doSomething() { System.out.println("this is xishuHardDisk"); } }
/* * 内存的抽象类 */ public abstract class Memory { public abstract void doSomething(); }
/* * 金士顿内存 */ public class JinShiDunMemory extends Memory { public void doSomething() { System.out.println("this is jinshidunMemory"); } }
/* * 金邦内存 */ public class JinBangMemory extends Memory { public void doSomething() { System.out.println("this is jinbangMemory"); } }
/* * 电脑 */ public class Computer { private MainBoard mainBoard; private Memory memory; private HardDisk harddisk; public MainBoard getMainBoard() { return mainBoard; } public void setMainBoard(MainBoard mainBoard) { this.mainBoard = mainBoard; } public Memory getMemory() { return memory; } public void setMemory(Memory memory) { this.memory = memory; } public HardDisk getHarddisk() { return harddisk; } public void setHarddisk(HardDisk harddisk) { this.harddisk = harddisk; } public void display() { mainBoard.doSomething(); memory.doSomething(); harddisk.doSomething(); } }
public class MainClass { public static void main(String[] args) { Computer computer = new Computer(); computer.setMainBoard(new HuaShuoMainBoard()); computer.setMemory(new JinShiDunMemory()); computer.setHarddisk(new XiJieHardDisk()); computer.display(); System.out.println("-------------"); computer.setMainBoard(new WeiXingMainBoard()); computer.display(); } }
如果将Computer类改为下列形式，主要是违背了第二条，高层次模块依赖于低层次模块。
public class Computer { private HuaShuoMainBoard mainBoard; private JinShiDunMemory memory; private XiJieHardDisk harddisk; public HuaShuoMainBoard getMainBoard() { return mainBoard; } public void setMainBoard(HuaShuoMainBoard mainBoard) { this.mainBoard = mainBoard; } public JinShiDunMemory getMemory() { return memory; } public void setMemory(JinShiDunMemory memory) { this.memory = memory; } public XiJieHardHardDisk getHarddisk() { return harddisk; } public void setHarddisk(XiJieHardHardDisk harddisk) { this.harddisk = harddisk; } public void display() { mainBoard.doSomething(); memory.doSomething(); harddisk.doSomething(); } }
在工厂方法模式、模板方法模式、迭代子模式中都有明显的依赖倒转。
五、迪米特法则（law of Demeter）
迪米特法则最初是用来作为面向对象的系统设计风格的一种法则，于1987年秋天由lan holland在美国东北大学为一个叫做迪米特的项目设计提出的。 迪米特法则(Law of Demeter )又叫做最少知识原则，也就是说，一个对象应当对其他对象尽可能少的了解，应可能少的与其他对象发生相互作用，使得系统功能模块相对独立。在类的结构设计上，每一个类都应当尽量降低成员的访问权限。
迪米特法则： 如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一类的某一个方法的话，可以通过第三者转发这个调用。其根本思想是强调了类之间的耦合性。类之间的耦合越弱，越有利于复用，一个处于弱耦合的类被修改，不会对有关系的类造成波及。
例子：不要和陌生人说话
这里，“某人”没有通过“朋友”，而是直接和“陌生人”联系了
public class SomeOne { public void play(Friend friend){ System.out.println("someone play"); friend.play(); } public void play(Stranger stranger) { System.out.println("someone play"); stranger.play(); } }
public class Friend { public void play(){ System.out.println("friends paly"); } }
public class Stranger { public void play(){ System.out.println("stranger play"); } }
public class MainClass { public static void main(String[] args) { SomeOne zhangsan = new SomeOne(); zhangsan.play(new Friend()); zhangsan.play(new Stranger()); } }
“某人”通过“朋友”和“陌生人”联系
public class SomeOne { public void play(Friend friend){ System.out.println("someone play"); friend.play(); Stranger stranger = friend.getStranger(); stranger.play(); } }
public class Friend { public void play(){ System.out.println("friends paly"); } public Stranger getStranger() { return new Stranger(); } }
public class Stranger { public void play(){ System.out.println("stranger play"); } }
public class MainClass { public static void main(String[] args) { SomeOne zhangsan = new SomeOne(); zhangsan.play(new Friend()); } }
在SomeOne类中还有Stranger，而且“某人”和“朋友”的关系设置也不太合理，继续修改为：
public class SomeOne { private Friend friend; public Friend getFriend() { return friend; } public void setFriend(Friend friend) { this.friend = friend; } public void play(Friend friend){ System.out.println("someone play"); friend.play(); } }
public class Friend { public void play(){ System.out.println("friends paly"); } public void playWithStranger() { Stranger stranger = new Stranger(); stranger.play(); } }
public class Stranger { public void play(){ System.out.println("stranger play"); } }
public class MainClass { public static void main(String[] args) { SomeOne zhangsan = new SomeOne(); zhangsan.setFriend(new Friend()); zhangsan.getFriend().playWithStranger(); } }
在外观模式和终结者模式中，迪米特法则很明显。
6、接口隔离法则(Interface Segregation Principle）
客户端不应该依赖那些它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
如下图所示，类A依赖接口I中的方法1、方法2、方法3，类B是对类A依赖的实现。类C依赖接口I中的方法1、方法4、方法5，类D是对类C依赖的实现。对于类B和类D来说，虽然他们都存在着用不到的方法（也就是图中红色字体标记的方法），但由于实现了接口I，所以也必须要实现这些用不到的方法。
interface I { public void method1(); public void method2(); public void method3(); public void method4(); public void method5(); } class A{ public void depend1(I i){ i.method1(); } public void depend2(I i){ i.method2(); } public void depend3(I i){ i.method3(); } } class B implements I{ public void method1() { System.out.println("类B实现接口I的方法1"); } public void method2() { System.out.println("类B实现接口I的方法2"); } public void method3() { System.out.println("类B实现接口I的方法3"); } //对于类B来说，method4和method5不是必需的，但是由于接口A中有这两个方法， //所以在实现过程中即使这两个方法的方法体为空，也要将这两个没有作用的方法进行实现。 public void method4() {} public void method5() {} } class C{ public void depend1(I i){ i.method1(); } public void depend2(I i){ i.method4(); } public void depend3(I i){ i.method5(); } } class D implements I{ public void method1() { System.out.println("类D实现接口I的方法1"); } //对于类D来说，method2和method3不是必需的，但是由于接口A中有这两个方法， //所以在实现过程中即使这两个方法的方法体为空，也要将这两个没有作用的方法进行实现。 public void method2() {} public void method3() {} public void method4() { System.out.println("类D实现接口I的方法4"); } public void method5() { System.out.println("类D实现接口I的方法5"); } } public class Client{ public static void main(String[] args){ A a = new A(); a.depend1(new B()); a.depend2(new B()); a.depend3(new B()); C c = new C(); c.depend1(new D()); c.depend2(new D()); c.depend3(new D()); } }
我们需要将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系，也就是采用接口隔离原则，如下所示。
interface I1 { public void method1(); } interface I2 { public void method2(); public void method3(); } interface I3 { public void method4(); public void method5(); } class A{ public void depend1(I1 i){ i.method1(); } public void depend2(I2 i){ i.method2(); } public void depend3(I2 i){ i.method3(); } } class B implements I1, I2{ public void method1() { System.out.println("类B实现接口I1的方法1"); } public void method2() { System.out.println("类B实现接口I2的方法2"); } public void method3() { System.out.println("类B实现接口I2的方法3"); } } class C{ public void depend1(I1 i){ i.method1(); } public void depend2(I3 i){ i.method4(); } public void depend3(I3 i){ i.method5(); } } class D implements I1, I3{ public void method1() { System.out.println("类D实现接口I1的方法1"); } public void method4() { System.out.println("类D实现接口I3的方法4"); } public void method5() { System.out.println("类D实现接口I3的方法5"); } }
接口隔离原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
采用接口隔离原则对接口进行约束时，要注意以下几点：
- 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
- 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
- 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
7 .合成/聚合复用原则(Composite/Aggregate Reuse Principle)
这个原则涉及到为聚合(Aggregation) 关系和合成(Composition) 关系，在“设计模式--UML类图”中有所介绍。
这个原则指复用时要尽量使用合成/聚合关系（关联关系），少用继承。
通过继承来进行复用的主要问题在于继承复用会破坏系统的封装性，因为继承会将基类的实现细节暴露给子类，由于基类的内部细节通常对子类来说是可见的，所以这种复用又称“白箱”复用，如果基类发生改变，那么子类的实现也不得不发生改变；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性；而且继承只能在有限的环境中使用（如类没有声明为不能被继承）。
由于组合或聚合关系可以将已有的对象（也可称为成员对象）纳入到新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能，这样做可以使得成员对象的内部实现细节对于新对象不可见，所以这种复用又称为“黑箱”复用，相对继承关系而言，其耦合度相对较低，成员对象的变化对新对象的影响不大，可以在新对象中根据实际需要有选择性地调用成员对象的操作；合成复用可以在运行时动态进行，新对象可以动态地引用与成员对象类型相同的其他对象。
总之，合成/聚合可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。使用继承要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，降低复杂度，但滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。
如果两个类之间是“Has-A”的关系应使用合成或聚合，如果是“Is-A”关系可使用继承。"Is-A"是严格的分类学意义上的定义，意思是一个类是另一个类的"一种"；而"Has-A"则不同，它表示某一个角色具有某一项责任。
例子：我们需要办理一张银行卡，如果银行卡默认都拥有了存款、取款和透支的功能，那么我们办理的卡都将具有这个功能，此时使用了继承关系：
为了灵活地拥有各种功能，此时可以分别设立储蓄卡和信用卡两种，并有银行卡来对它们进行聚合使用。此时采用了合成复用原则:
