概述
设计原则就一本菜谱，告诉我们一道美味的菜应该是什么样的，或者说需要具备什么。但是又没有一个固化或可测量的标准。写代码就和烹饪一样，只有当自己品尝以后才知其味。
1 开闭原则
定义：
开闭原则(Open-Closed Principle, OCP)：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。
解读
开闭原则很简单，就是当需求变更的时候，尽量不要修改已有代码。开闭原则是整个设计原则的核心思想。如果当你发现某个需求的改动需要涉及许多地方的代码改动，那么你的代码很有可能是不满足开闭原则的。
小结
单独说开闭原则是没有什么内容可讲的，就像和你说“坚强的人可以克服任何困难”。那么其实我们关心的是怎么才能变得“坚强”。其他的设计原则其实都是围绕着怎么实现开闭原则而进行的。
2 单一职责原则
定义：
单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
解读
通俗一点说，就是一个类不能承担太多的功能。只专心一件事，并且把这件事做好。举一个例子，假如要写一个食堂类。对于客户端来说，食堂核心功能是要能打饭和回收餐具。如果要打饭那么肯定需要有先把菜做好，如果要做菜还要有人去买菜。那么如果这些功能都放在一个类里面就会如下图：
很明显违反了单一职责原则。为什么？明明就是只负责吃相关职能啊。你都说了是吃相关，那么肯定就不只是一个简单功能。吃前要准备，吃后要收拾。其实作为一个服务，就和我们去食堂吃饭，我只关心怎么打饭，我吃完以后把餐具放哪里。其他的至于菜市从哪里买的，谁炒的都不关心。因此，改良一下
作为食堂，提供多种多样的菜品（如川菜、粤菜）。如果让一个厨师即炒粤菜又炒川菜又违背了单一职责原则。因此再改一下：
单一职责好处就是: 可以降低类的复杂度，提高类的可读性，降低变更引起的风险降低。变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
小结
其实单一职责不仅仅是针对一个类的设计，往小的说一个方法、往大的说一个模块都应该满足单一职责原则。只是怎么去确定职责及其范围是需要根据具体的场景来确定。
3 里氏代换原则
定义：
里氏代换原则(Liskov Substitution Principle, LSP)：所有引用基类（父类）的地方必须能透明地使用其子类的对象。
解读
里氏代换原则核心就是要满足继承体系，能用父类的地方，那么其任何子类也可以正确调用。否则，就不应该做为其子类（或者父类的定义就不正确）。例如鸟是一个父类，那么所有的鸟都应该是卵生。但是如果父类定义了方法fly()就不一定了，因为有的鸟不会飞的。这个就不满足里氏替换原则。从代码层面上来说：如果一个类实现一个接口，那么就应该实现该接口的所有方法。比较经典的案例就是Spring的CacheManager的接口。
小结
如果你理解（或者使用过）面向对象语言，那么里氏替换原则理解起来就十分简单。例如java在编译的时候就会检查一个程序是否符合里氏替换原则。虽然很简单，但是这也是实现开闭原则的基本条件。试想，当扩展一个接口的时候，发现扩展类在实现该接口的方法不能正确调用，那么这个该扩展也是没有任何意义的。
4 依赖倒转原则
定义:
依赖倒转原则(Dependency Inversion Principle, DIP)：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。
解读
上面定义中的抽象可以简单的理解为接口，细节就是接口的实现类。也就是说，无论是定义变量、方法参数类型还是方法返回都尽量使用抽象接口，而不是返回具体的实现类。这样做的目的就是方便以后扩展（也就是实现开闭原则的手段）。还是前面的食堂为例，假如一开始的时候只有MarketA卖菜，采购员就只有去哪里卖菜。也许一开始的代码就会这样写：
class MarketA {
public String name() {
return ("MarketA");
}
}
class Buyer {
public void buy(MarketA marketA) {
System.out.println("采购员在" + marketA.name() + "买菜");
}
}
public void CanteenBuyFood() {
Buyer buyer = new Buyer();
buyer.buy(new MarketA());
}
突然有一天，MarketB开业，并且每周一的价格比MarketA便宜，因此，选择周一在MarketB买菜。
class MarketA {
public String name() {
return ("MarketA");
}
}
class MarketB {
public String name() {
return ("MarketB");
}
}
class Buyer {
public void buyA(MarketA marketA) {
System.out.println("采购员在" + marketA.name() + "买菜");
}
public void buyB(MarketB marketB) {
System.out.println("采购员在" + marketB.name() + "买菜");
}
}
public void CanteenBuyFood() {
Buyer buyer = new Buyer();
// 其实这也也不满足单一职责原则，即要选择菜市场，又要派采购员买菜。
if(to is monday){
buyer.buyA(new MarketA());
}else{
buyer.buyB(new MarketB());
}
}
突然又有一天，MarketC,MarketD...MarketCX 开业了，并且....好吧，是不是发现这样写下去什么时候是个头啊。因此我们需要进行代码重构，使其满足开闭原则。
interface Market {
String name();
}
class MarketA implements Market {
public String name() {
return ("MarketA");
}
}
class MarketB implements Market {
public String name() {
return ("MarketB");
}
}
interface Buyer {
public void buy(Market market);
}
//省略Buyer的子类
public void CanteenBuyFood() {
Market market = selectMarket();
Buyer buyer = selectBuyer();
buyer.buy(market);
}
private Buyer selectBuyer() {
//根据实际情况选择采购员
}
private Market selectMarket() {
// 根据情况选择市场
}
重构后代码是不是无论加多少market，只要修改selectMarket()的方法。无论加多少采购员，只要修改Buyer.getBuyer()中的代码。
小结
可以看出，在代码重构过程中，在大多数情况下开闭原则、里氏代换原则和依赖倒转原则这三个设计原则会同时出现。开闭原则是目标，里氏代换原则是基础，依赖倒转原则是手段，他们目的都是为了代码的扩展性，只是分析问题时所站角度不同而已。
5 接口隔离原则
定义：
接口隔离原则(Interface Segregation Principle, ISP)：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
解读
接口隔离就是定义一个接口的时候不要定义得太而广，而是把他们分割成一些更细小的接口。一般不满足单一职责原则都不满足接口隔离原则，这样的例子很多，就不多说明了。但反过来却不一定，举一个例子（往往原则的例子举反例是最清晰的）。还是买菜的问题，如果我们定义一个市场，在市场里面买肉、买蔬菜、买水果....)，往往一开始我们定义接口的时候是按照一个样例来定义接口，比如上面就是按照一个超级市场来定义的接口，其实这样做是很正常的情况。
interface Market {
void buyMeat();
void buyVegetables();
}
class SuperMarket implements Market {
public void buyMeat() {
System.out.println("买肉");
}
public void buyVegetables() {
System.out.println("买菜");
}
}
这样定义接口在一开始是没问题，但是随着业务扩展，如果现在存在另外一个市场，他只卖菜，不卖肉。。那么该类在 buyMeat()下面怎么办？当你发现你实现一个接口的时候，某个需要实现的方法你没办法去实现，这种情况也算不满足接口隔离的原则了。这时候就需要进行重构，把接口进一步细化，例如，把Martet细化为MeatMarket和VegetableMarket。
interface Market {
//其他共有方法
}
interface MeatMarket extends Market{
void buyMeat();
}
interface VegetableMarket extends Market{
void buyVegetables();
}
class SuperMarket implements MeatMarket,VegetableMarket {
public void buyMeat() {
System.out.println("买肉");
}
public void buyVegetables() {
System.out.println("买菜");
}
}
class SmallMarket implements VegetableMarket {
public void buyVegetables() {
System.out.println("买菜");
}
}
上面的实例代码仅仅是为了说明接口隔离原则，
小节
接口隔离原则核心思想就是细化接口，提高程序的灵活性。但细化到什么程度却没有具体的度量，接口不能太小，如果太小会导致系统中接口泛滥，反而不利于维护。因此如何把握这个读就是经验了。
迪米特法则
定义
迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用。
解读
迪米特法则还有几种定义形式，包括：不要和“陌生人”说话、只与你的直接朋友通信等
一个类只与他的朋友类进行交互
所谓一个类的朋友，就是该类
- 当前对象本身(this)；
- 以参数形式传入到当前对象方法中的对象，或者返回的方法返回的对象
- 当前对象的成员对象；
从代码层面上讲，当该类的所有方法体为空的时候，该类所依赖的类就是朋友类 所谓只与他朋友类进行交互意思就比较好理解了，就是不能直接调用他朋友的朋友方法。也就是在
中，食堂服务\=\=朋友==>食堂后勤\=\=朋友==>厨师，我们不能直接在食堂服务中直接调用让厨师去炒菜。食堂服务类要与厨师类通信，也是必须要有食堂后勤类作为中介。从代码层面上来说，一般 A.getB().getC().xxxMethod() 往往都是破坏迪米特法则。
即使是朋友也要保持距离
一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大。例如，
class A {
public void step1(){
//do something
}
public void step2(){
//do something}
}
public void step3(){
//do something}
}
}
class M {
public void someCall(A a) {
a.step1();
a.step2();
a.step3();
}
}
从代码里面看，A确实是M的朋友，但是，M和A太"亲密"了，如果以后需要在调用step2的之前调用一个check2()的方法，就必须要修改M中的方法，如果这个调用方式大量出现在工程中，就会引起扩散。如果我之前是这么设计的交互的方式就不会存在这个问题。也就是说，朋友之间的交互不要太"亲密"。同时作为别人朋友，最好能提供“一站式服务”。
class A {
private void step1(){
//do something
}
private void step2(){
//do something}
}
private void step3(){
//do something}
}
public void exe(){
step1();
step2();
step3();
}
}
class M {
public void someCall(A a) {
a.exe();
}
}
小节
迪米特发展的目的就是降低系统的耦合度，使类与类之间保持松散的耦合关系。和接口隔离原则一样，迪米特法则也是一个无法进行度量。过度使用迪米特法则，也会造成系统的不同模块之间的通信效率降低，这就直接导致了系统中存在大量的中介类。因此，如何使用迪米特法则还是那句话，根据经验。
总结
单一职责原则告诉我们实现类的功能不要太多。里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则总的大纲，要对扩展开放，对修改关闭。
设计原则只是给我们一些指导性的意见，在实际工作中往往要根据实际情况来判断。就如开篇所说的那样，往往菜谱往往给我们的意见都是“少许”，“适量”，而真正要烹饪出一道美味还需要我们自己不断去积累和调整。