设计模式-六大设计原则（附加实际开发建议以及计算器例子）

使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式使代码编制真正工程化，是软件工程的基石脉络，如同大厦的结构一样。

文章结构：

1.单一职责原则（SRP）；
2.里氏替换原则（LSP）；
3.依赖倒置原则（DIP）；
4.接口隔离原则（ISP）；
5.迪米特原则（LoD）；
6.开闭原则（OCP）。
7.以计算器设计为例子综合展示各大原则以及相关设计模式。

一、单一职责原则（Single Responsibility Principle，SRP原则）：

定义：

应该有且仅有一个原因引起类的变更。也就是一个接口或类只负责一件事。

使用原因：

假设一个类负责两大职责，那么当业务变化，一个职责需要变化时就要修改这个类，所以就可能导致另一个职责会发生变化。

优点：

1.类的复杂度降低，实现什么职责都又清晰明确的定义；
2.可读性高，复杂性降低；
3.可维护性高，易维护；
4.变更引起的风险降低。（一个接口修改只对应的实现类有影响，对其他的接口无影响，对系统扩展性、维护性有多大帮助）。

例子：

//这样设计的话，有个后果可以看见：如果我要让帅哥类拥有一个跳舞的技能，那么我要修改哪里呢？？修改People类？那就全崩了。所以我们应该把帅哥类拆分出来成为另一个类来继承People。
public class People{public void say(String name){System.out.println("我是"+name);}
}
//场景类
public class Client{public static void main(String []args){People people=new People();people.say("帅哥")；people.say("美女")；people.say("大叔")；}
}

单一职责原则使用建议：

接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

但是呢，类的设计也要结合实际，很多时候非单一职责的情况的，我们就要去妥协一下子：
1.只有逻辑足够简单，才可以在代码级别上违背ＳＲＰ；
2.只有类中方法数量足够少，才可以在方法级别上违背ＳＲＰ；
3.实际应用中的类都要复杂的多，一旦发生职责扩散而需要修改类时，除非这个类本身非常简单，否则还是要遵循ＳＲＰ。

二、里氏变换原则（Liskov Substitution Principle，LSP原则）：

定义：

所有引用基类的地方必须能透明地使用其子类对象。即：只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或寻常。（子类可完整实现父类的业务）。

设计原因：

有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。

这个定义有四层含义：

###　（一）、子类必须完全实现父类的方法：
也就是在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明违背LSP原则。（在编写类的实现时用父类对象，调用时传入其子类实现向上转型即可完成设计。是传入子类对象，在方法实现向上转型成父类）。

针对这一含义，实际的开发有些注意点：

1.业务增多时，类的设计思路：

（1）（不推荐）在moudle类中增加instanceof的判断（即每增加所有与这个类的父类有关系的类都要修改）。
（2）（推荐，维护人员经常干）新增类脱离继承，简历一个独立的父类，可与原来的那个父类建立关联委托关系。

2.具体应用场景类的设计关键：

子类是否能完整地实现父类的业务。（如果子类不能完整实现父类的方法，或者父类的某些方法在子类中已经发生变化，则应该简历断开父子继承关系，采用依赖、聚集、组合等关系。）

（二）子类可以有自己的个性：

也就是子类可以有自己的方法和属性。

注意：在调用那个类时，不要使用父类对象传递。因为向下转型是不安全的。

（三）覆盖或实现父类的方法时输入参数可以被放大。

注意：

1.子类中方法的前置条件（传递的参数）必须与父类中被覆写的方法的前置条件相同或者更宽松。

2.如果父类的输入参数类型宽于子类的输入参数类型，那么会出现父类存在的地方，子类就未必可存在。因为一旦把子类作为参数传入，调用者可能进入子类的方法。

（四）、覆写或实现父类的方法时输出结果可以被缩小：

含义：

父类的一方法的返回值是一个类型T，子类的相同方法（重载或覆写）的返回值为S，那么LSP原则要求S必须小于或等于T。也就是说S和T是同一类型或者S是T的子类。

LSP原则的目的：

增强程序的健壮性，使版本升级时，即使增加子类，原有的子类还可以继续运行。

实际项目做法：项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑。可是！！使用LSP原则的时候要尽量避免子类的“个性”,因为LSP原则只可以正着用不能反着用。

例子：

public class Father {public Collection doSomeing(HashMap map){System.out.println("父类被执行。。。");return map.values();  }
}
public class Son extends Father{public Collection doSomeing(Map map){System.out.println("到子类啦");return map.values();}
}
//场景类一。
public class Client{public static void invoker(){Father f=new Father();     //这里就是直接使用父类的对象HashMap map=new HashMap();f.doSomeing(map);}public static void main(String []args){invoker();}
}
//跟场景类一结果一样的场景二：
//分析:为啥会一样结果呢？？因为我们设计子类的时候，输入的参数的范围相对于父类扩大了，子类就可以代替父类传递到父类的调用者中，子类的方法就不会被执行啦。但是呢，如果想让子类的方法被执行，就必须覆写父类的方法了。
public class Client{public static void invoker(){Son son=new Son();HashMap map=new HashMap();son.doSomeing(map);}public static void main(String []args){invoker();}
}

三、依赖倒置原则（Dependence Inversion Principle，DIP原则）：

定义：简而言之，就是面向接口编程。

（1）模块间的依赖通过抽象发生，实现类之间不发生之间的依赖关系，其依赖关系是通过接口或抽象类产生的；
（2）接口或抽象类不依赖于实现类；
（3）实现类依赖接口或抽象类。

设计原因：

类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

DIP原则优点：

减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

使用：

分析！！分析两个类是否有依赖关系，有则制定出两者之间的接口（或抽象类）即可独立开发。

依赖的三种写法：

（一）、在类中通过构造函数声明依赖对象。（按照依赖注入的说法，叫做构造函数注入）。

public interface IDriver{public void drive();       //是司机就会开车.这是个司机接口
}
public class Driver implements IDriver{private ICar car;public Driver (ICar _car){    //构造函数注入依赖this.car=_car;}//司机主要职责就是开车public void drive(){this.car.run();  //对象事务一级级地传递，传递到车对象}
}

（二）在抽象中设置Setter方法声明依赖关系（依照依赖注入的说法，这叫Setter依赖注入）。

public interface IDriver{public interface IDriver{public void setCar(ICar car); //车辆型号public void drive();}public class Driver implements IDriver{private ICar car;public void setCar(ICar car){   //setter函数注入依赖this.car=car;  }public void driver(){this.car.run();}}
}

（三）接口声明依赖对象

//分析：在IDriver中，通过传入ICar接口实现**抽象之间**的依赖关系。Driver实现类也传入了ICar接口，而是什么类型Car就需要在高层声明了。
public interface ICar {//是汽车就会跑public void run();
}
public interface IDriver{//是司机就会开车public void drive(ICar car);   //在接口就注入依赖，注入的是接口之间的依赖
}
publi class Driver implements IDriver{//司机主要职责就是开车public void drive(ICar car){car.run();}
}

使用DIP原则的规则以及注意点：

（一）、每个类尽量都又接口或抽象类，或者两者都具备。

（依赖倒置的基本要求，有了抽象才可能依赖倒置）

（二）变量的表面类型尽量是接口或者抽象类。

（但不是所有类型都要抽象，比如一个工具类一般不需接口或抽象类）

（三）任何类都不应该从具体类派生。

（比如：项目处于开发状态，不应从具体类派生出子类。但有维护的口占情况，这时则可以不考虑，但要求不超过两层继承）。

（四）尽量不要覆写基类的方法

（如果基类是一个抽象类，而且方法已经实现，子类应尽量不要覆写。类间依赖的是抽象，覆写抽象方法对依赖的稳定性有影响。）

（五）结合里氏替换原则使用

（原则：接口负责定义public属性和方法，并且声明与其他对象的的依赖关系，抽象类负责公共构造部分的实现，是实现类准确地实现业务逻辑，同时在适当的时候对父类进行细化）。

DIP原则是6个设计原则中最难实现的原则，是实现开闭原则的重要途径。

四、接口隔离原则（Interface Segregation Principle，ISP原则）：

定义：

客户端不应该依赖它不需要的接口，类间的依赖关系应该建立在最小的接口上。（一句话：接口尽量细化，同时接口中的方法尽量少。）

做法：

把大接口分解为几个小接口。（例子：美女的接口分解为外貌美女、气质型美女）

注意：

单一职责要求的是类和接口职责单一，注重的是职责！！！这属于业务逻辑的划分。

接口隔离原则是对接口进行规范约束：（四层含义）开发注意点

（1）接口要尽量小。

根据接口隔离原则拆分接口时，首先必须满足单一职责原则！

（2）接口要高内聚。

高内聚：提高接口、类、模块的处理能力，减少对外的交互。要求接口–尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利。

（3）定制服务：

原因：模块之间必然会有耦合，有耦合就要有相互访问的接口（可能是Java中的interface，也可能为一个类或单纯数据交换）设计时需要为各个访问者（客户端）定制服务。

定义：就是单独为一个getItem提供优良的服务

要求做法：只提供访问者需要的方法。

项目开发时接口设计规则:

（一）一个接口只服务于一个子模块或业务逻辑
（二）通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉“，而不是肥嘟嘟的一堆方法。
（三）已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理。
（四）了解环境，不要盲从。每个项目或产品都有特定的环境因素，别看到大师做接口就做接口。环境不同，接口拆分的标准不同，有一点点的妥协原则的。

例子：

//外貌型美女
public interface GoodBodyGirl{//美丽的外貌public void goodLooking{}//好身材public void niceFigure{}
}
//气质型美女
public interface GreatTemperametGirl{//气质public void greatTemperament();
}

（五）迪米特原则（Law Of Demeter，LOD原则）：

定义：

一个对象应该只对其他对象有最少的了解。（也就是说你的类多复杂都不关我的事，我只关心你的public事物）

设计原因：

类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

含义有四层：

（一）只和朋友交流：类与类的联系不要跨越。

（也就是我想叫我的朋友的朋友去干活，就必须通过我的朋友去告诉我的朋友的朋友）
类与类之间的关系是建立在类间的，而不是方法之间，因此一个方法尽量不引入一个类中不存在的对象。

（二）朋友之间也是有距离的：

一个雷公开的public属性或方法越多，修改时设计的面也就越大，变更引起的风险扩散也越大。

注意：尽量不公布太多public方法和非静态的public变量，多使用private–>类的高内聚。

技巧：一个类暴露过多方法，而发现这堆方法有关系时，可以设计一个public方法，把那堆方法统率在新的public方法，并设置为private。

（三）是自己的就是自己的：

方法设计原则：如果一个方法放在本类中，即不增加类间的关系，也对本类不产生负面影响，就可以放置在本类中。

（四）谨慎使用Serializable（序列化机制，具体看我另一篇博客输入输出机制）。

例子：一个项目使用RMI（远程方法调用）方式传递VO值对象，其实就是个网络请求过程，那么这个对象就必须实现Serializable接口。（也就是把需要网络传输的对象进行序列化，否则会出现Not Serializable Exception）。

核心观念：类间解耦，实现弱耦合。

可能导致的后果：然而其结果会产生大量中转类或跳转类，导致系统的复杂性提高，为维护带来难度。所以使用LOD原则时要反复权衡。跳转不超过两次。

例子：

//场景是：老师叫班长清点女生人数，班长就去清点了。
//分析：所以这个场景，根据LOD原则，老师是不能调用女生的类的。然后我们知道只能够让班长去调用女生。而老师去调用班长。
public class Teacher{public void commond(GroupLeader groupleader){groupleader.countGirls();}
}
public class Girl{}
public class GroupLeader{private List<Girl> listGirls;//传递全班的女生进来public GroupLeader(List<Girl> _listGirls){this.listGirls = _listGirls;}//清查女生数量public void countGirls(){System.out.println("女生数量是："+this.listGirls.size());}
}

六、开闭原则：

定义：

一个软件实体应通过扩展来实现变化，而不是通过修改已有的代码来实现变化。

设计原因：

在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

业务变化：（三种类型）

（1）逻辑变化。

只变化一个逻辑而不涉及其他模块，可通过修改原有类中的方法的方式来完成。但是有个前提条件：所有依赖或关联类都按照相同逻辑处理。

（2）子模块变化：

一个模块变化，必会对其他模块产生影响，特别是一个低层次的模块变化必然引起高层模块的变化。

（3）可见视图变化：

可见视图是提供给客户使用的界面，该部分的变化一般会引起连锁反应。因为多了一项显示数据，意味着你的其他部分代码也要增多一项这样的数据。

针对软件产品的需求业务变化：有三大扩展方案

（一）修改接口，增加方法：（否定）

后果：所有拥有该接口的实现类必须作修改，场景类也要修改。
否定这个方案的原因：接口应该是稳定且可靠的，不应经常发生变化，否则接口作为契约的作用就失去了。

（二）修改实现类：（不推荐）

做法：通过class文件替换的方式完成业务变化。
后果：修改了的信息可能会导致其他类获得的信息不对称。

（三）通过扩展实现变化：（推荐）

做法：增加子类，覆写方法，高层次的模块（static静态模块区）通过新增子类产生新的对象。
代码例子：

public interface Book{//书籍有名称public String getName();//书籍有售价public int getPrice();//书籍有作者public String getAuthor();
}
public class NovelBook implements Book{//书籍名称private String name;//书籍的价格private int price;//书籍的作者private String author;//通过构造函数传递书籍数据public NovelBook(String _name,int _price,String _author){this.name = _name;this.price = _price;this.author = author;}public String getAuthor(){return this.author;}public String getName(){return this.name;}public int getPrice(){return this.price;}
}
//然后到了阅读月啦，我们书店就要打折啦！！怎么办？？正如我们刚刚提到的三种方案。
//分析：如果选择第一种方案，在接口里面新增方法，那么我们的小说类NovelBook也要修改，而且违背接口的稳定性原则。如果选择第二种方案，直接修改实现类，也就是修改NovelBook的类啦，是的，我们可以做一个打折的方法，然后完成打折的业务扩展，但是！！其他业务就有可能有影响，比如设计模式里面说的采购人员也看价格，而当这个方法实现了，采购人员只会看到打折后的价格。
//所以我们采用第三种方案。来完成业务扩展。
public class OffNovelBook extends NovelBook{public offNovelBook(String _name,int _price,String _author){super(_name,_price,_author);}@Overridepublic int getPrice(){//原价int selfPrice = super.getPrice();int offPrice = 0;if(selfPrice>4000){offPrice = selfPrice * 9/10;}else{offPrice = self * 8/10;}return offPrice;}
}

开闭原则是最基础的一个原则，也就是说前五个原则是指导设计的工具和方法，而开闭原则才是精神领袖。可以说，只要遵守前五大原则，设计出来的软件就会符合开闭原则。

思想核心：用抽象构建框架，用实现扩展细节。

联系其他原则：单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。

七、计算器（结合了六大设计原则与工厂模式）

//这个就是运算类的工厂模式。因为运算太多了，如果每个都在运算类里面再写个几行，那样会导致运算类的繁重累赘而且不清晰。以多态特性来设计。
public class OperationFactory{public static Operation createOperate(String operate){Operation oper = null;swich(operate){case "+":oper = new OperationAdd();break;case "-":oper = new OperationSub();break;case "*":oper = new OperationMul();break;case "/":oper = new OperationDiv();break;}return oper;}
}
//而这个运算类，把他给抽象处理就体现出 用抽象构建架构，用实现扩展细节了。
//分析：我们把运算类的核心抽取出来：两个数，一个结果，还需一个运算规则。这几个就是本质！而运算规则有很多种，我们需要交给子类去实现
//根据 单一职责原则--我们把每个运算规则的类分开成了单独的类。加减乘除均为一个类。
//根据 里氏替换原则--加减乘除的四个类均继承一个抽象出来的运算父类，获得一样的特性。两个数，一个结果。
//根据 依赖导致原则--面向接口编程，也就是面对抽象的结果编程。而我们抽象出的运算父类，拥有各个运算规则子类的共同特征。
//根据 接口隔离原则--呃，，这里只作出了一步抽象，没有多余的接口。
//根据 迪米特原则--松耦合。当然啦，都把加减乘除分离开来成一个类了，以后你想要修改加法，比如根据职位不同去加不同的薪水，这样更改，你只需改加法这个类。
//根据 开闭原则。核心--用抽象构建框架，用实现扩展细节。以上原则都实现了，这不就好了咩。
public abstract class Operation{private double numberA = 0;private double numberB = 0;private double result = 0;public void setNumberA(Double _numberA){this.numberA = _numberA;}public double getNumberA(){return numberA;}public void setNumberB(Double _numberB){this.numberB = _numberB;}public double getNumberB(){return numberB;}public abstract double getResult();
}
//加法类
class OperationAdd extends Operation {public double getResult(){result = numberA + numberB;return result;}
}
//减法类
class OperationSub extends Operation {public double getResult(){result = numberA - numberB;return result;}
}
//乘法类
class OperationMul extends Operation {public double getResult(){result = numberA - numberB;return result;}
}
//除法类
class OperationDiv extends Operation {public double getResult(){try{result = numberA / numberB;}catch(Exception e){System.out.println("除数不能为0");e.printStackTrace();}return result;}
}
//场景类代码：
Operation oper;oper = OperationFactory.createOperate(“+”);oper.setNumberA(1.0);oper.SetNumberB(2.0);double result = oper.GetResult();

好了，设计模式-六大设计原则（附加实际开发建议以及计算器例子）讲完了。本博客借鉴了一部分设计模式之禅，这是一本很好的书，只是我在这里总结以及写出自己的理解。欢迎在下面指出错误，共同学习！

转载请注明：【JackFrost的博客】
更多内容，可以访问JackFrost的博客