软件设计七大原则。在面向对象软件开发过程中，我们适当的遵循一定的设计原则，对于开发来说，能够提高代码的健壮性，复用性，可维护性。同时利于团队协作交流。

本文中的部分原则给出一个特定场景和具体代码实现。其它的设计原则贴出他人写的博文地址。

1. 开闭原则（open close）

 定义： 软件实体（类，模块，函数）应该对扩展开放，对修改关闭。解释：用抽象构建框架，用实现扩展细节。优点：提高系统的可复用性，可维护性。

• Code实现

  以书店的书籍作为一个简单的例子

  书籍有3个简单属性：id，name，price。于是对于访问书籍的信息我们抽象 出一个接口类：

  public interface IBook {Integer getId();String  getName();double  getPrice();
  }
  

  现在有关IT类的书。我们自然就可以实现这个接口：

  public class ITBook implements IBook{private Integer Id;private String name;private double price;@Overridepublic Integer getId() {return this.Id;}@Overridepublic String getName() {return this.name;}@Overridepublic Double getPrice(){return this.price;}
  }
  

  测试类：

  public class Test {public static void main(String[] args) {IBook cpp = new ITBook( 11, "CPP", 32.0);//print : id，name，priceSystem.out.println( "Id: " + cpp.getId() + ", name: " + cpp.getName() + ", price:" + cpp.getPrice());}
  }
  

  现正逢双11，IT类的书打折(discount)。我们要对上面类的设计做出一些变化。
  为此我们可以尝试着对IBook类修改，增加一个抽象函数：

  public interface IBook {Integer getId();String  getName();double  getPrice();//添加的代码double  getDiscountPrice();
  }
  

  那么我们的ITBook类必须要override这个函数。对于一个书店来说，肯定不止IT类的书，还有文学，艺术，工程等等不同类的书。这些类按照我们的规则来设计的话，一定也会implements IBook。如此一来，我们在IBook这个底层接口内修改代码实在不是一个好的建议，因为一旦我们修改了底层IBook类的代码，所有实现IBook接口的类都必须进行相应的修改。

  按照开闭原则：用抽象构建框架，用实现扩展细节
  在我们的例子中，我们用抽象搭建的框架就是IBook这个类，打折这个功能相当于是扩展。我们不应该修改用抽象封装好的底层框架（对应于关闭）；而是应该在凌驾于底层框架之上，进行功能的扩展（对应于开放）

  说起来也挺容易理解：上层的应用都建立在底层之上，如果底层的接口修改了，那么所有依赖于这个这些接口的类都需要进行修改，否则会报错。

  回到例子中。根据分析，我们不修改IBook这个底层接口类，而是修改上层的实体类，实现打折功能的扩展。

  新定义一个类ITDiscountBook继承自ITBook：

  public class ITDiscountBook extends ITBook {private double discount;public ITDiscountBook(Integer id, String name, double price, double discount) {super(id, name, price);this.discount = discount;}public double getDiscountPrice(){return super.getPrice() * discount;}
  }
  

  测试类:

  public class Test {public static void main(String[] args) {//IBook cpp = new ITBook( 11, "CPP", 32.0);//System.out.println( "Id: " + cpp.getId() + ", name: " + cpp.getName() + ", price:" + cpp.getPrice() );IBook cppDiscountBook = new ITDiscountBook(11, "cpp", 32.0, 0.8);//注意 类的转换System.out.println( "id:" + cppDiscountBook.getId() + ", name:" +  cppDiscountBook.getName() +", Original price: " + cppDiscountBook.getPrice() +" Discount price: " + ((ITDiscountBook) cppDiscountBook).getDiscountPrice() );}
  }
  

• 类关系图（Diagram）
  

2. 依赖倒置（dependency inversion）

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象
解释：抽象不应该依赖细节，细节应该依赖抽象针对接口编程，不要针对实现编程
优点：减少类间的耦合性，提高系统稳定性，提高代码可读性，可维护性。降低修改程序所造成的风险。

• Code实现
  围绕书店这个例子，我们定义一个顾客类（Customer），它能实现买（buy）的功能。顾客买不同类型的书籍能够触发不同的模块调用。假设现在书店里面有三类书：IT，Art，Literature。Customer类和测试类Test实现如下：

  // 顾客类（低层模块）：对于不同的行为定义不同的模块
  public class Customer {public void buyITBook(){System.out.println("Buy a IT Book.");}public void buyArtBook(){System.out.println("Buy a Art Book.");}public void buyLiteratureBook(){System.out.println("Buy a Literature Book.");}
  }
  //测试类（高层模块）：测试类（高层）的功能依赖Customer（低层次）的具体实现
  public class Test {public static void main(String[] args) {Customer cus = new Customer();cus.buyITBook();cus.buyArtBook();cus.buyLiteratureBook();}
  }
  

  从上面的例子中可以看到，Customer类的设计使其扩展性很差，外部（Test）需要添加什么功能，都需要重新在Customer类内部添加或者修改相应的代码。也就是说高层模块依赖低层模块。

  现在我们尝试修改代码，使其符合我们所说的依赖倒置原则。

  我们把这几个Customer内部的功能模块抽离出来，使它们成为三个不同的类，然后Customer类只需要根据这三个类的统一接口触发模块调用即可。如下面类关系图所示：
  

  下面是抽离出来的代码：

  // 接口类，定义三个类的统一触发行为方法
  public interface IBook {void buyBook();
  }
  

  /**********************三个实体类*************************/

  // ITBook类
  public class ITBook implements IBook {@Overridepublic void buyBook() {System.out.println("Buy a IT Book.");}
  }
  

  // ArtBook 类
  public class ArtBook implements IBook {@Overridepublic void buyBook() {System.out.println("Buy a Art Book.");}
  }
  

  // LiteratureBook 类
  public class LiteratureBook implements IBook {@Overridepublic void buyBook() {System.out.println("Buy a Literature Book.");}
  }
  

  /*******************Customer类********************/

  public class Customer {public void buyABook(IBook iBook){iBook.buyBook();}
  }
  

  /****************测试Test类**************/

  public class Test {public static void main(String[] args) {Customer cus = new Customer();cus.buyABook( new ITBook() );cus.buyABook( new ArtBook() );cus.buyABook( new LiteratureBook() );}
  }
  

  可以看到代码的精彩之处在于，我们在外部（Test类）让Customer类执行相应行为时，只需要传入相应接口类就行，对Customer内部的实现丝毫没有影响。Customer跟另外三个类的唯一的通信渠道，就是通过一个接口类来作为函数参数，尽量降低耦合。

  同时该设计的扩展性是良好的，当我们需要添加新的行为时（在这里就是买新的种类的书），我们只需要再创建一个类，使这个类实现IBook接口就行。

  另外，Customer的几个实现版本总结如下：

  						/*1个原始版本不符合依赖倒置原则*/
  public class Customer {public void buyITBook(){System.out.println("Buy a IT Book.");}public void buyArtBook(){System.out.println("Buy a Art Book.");}public void buyLiteratureBook(){System.out.println("Buy a Literature Book.");}
  }/*3个符合依赖倒置原则的设计方式*/
  // 接口传参注入
  public class Customer {public void buyABook(IBook iBook){iBook.buyBook();}
  }
  // 构造器注入（单例）
  public class Customer {private IBook iBook;public void Customer (IBook iBook){this.iBook = iBook;}public void buyABook(){iBook.buyBook();}
  }
  // setter注入
  public class Customer {private IBook iBook;public void setIBook(IBook iBook){this.iBook = iBook;}
  }
  

3. 单一职责原则（single responsibility）

定义：不要存在多于一个导致类变更的原因
解释：一个类/接口/方法只负责一项职责
优点：降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险

点击借鉴

4. 接口隔离原则（Interface isolation）

定义：用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口
解释：一个类对一个类的以来应该建立在最小的接口上建立单一接口，不要建立庞大臃肿的接口尽量细化接口，接口中的方法尽量少
原则：注意适度原则，一定要适度
优点：符合高内聚，低耦合的设计思想，从而使得类具有很好的可读性，可扩展性，可维护型。

点击借鉴

5. 迪米特原则（demeter）

定义一个对象应该对其它对象保持最小的了解，又叫最小知道原则
解释尽量降低类之间的耦合
原则强调只和朋友交流，不和陌生人说话（朋友：出现在成员变量，方法的输入，输出参数中的类称为朋友类。而出现在方法体内部的类不属于朋友类。）
优点降低类间耦合

点击借鉴

6. 里氏替换原则（Liskov Substitution）

定义如果对每个类型为T1的对象O1，都有类型为T2的对象O2，使得以T1定义的所有程序P在所有的对象O1都替换成O2时，程序P的行为都没有发生变化，那么类型T2是类型T1的子类型
定义扩展一个软件实体如果使用一个父类的话，那一定适用于其子类，所有引用父类的地方必须能透明地使用其子类的对象，子类对象能够替换父类对象，而程序逻辑不变。
引申意义子类可以扩展父类的功能，但不能改变父类原有的功能含义子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。子类中可以增加自己特有的方法。当子类的方法重载父类的方法时，方法的前置条件（入参）要比父类方法的入参更宽松当子类的方法实现父类的方法时，方法的后置条件（返回值）要比父类更严格或相等。
优点约束继承泛滥，开闭原则的一种体现加强程序的健壮性，同时变更时也可以做到非常好的兼容性。提高程序的维护性，扩展性。降低需求变更时引入的风险[点击借鉴](https://blog.csdn.net/Bitou_Von/article/details/4210654)

7. 组合复用原则（composition aggregation）

定义尽量使用对象组合或聚合，而不是继承关系达到软件复用的目的
解释聚合has--A。电脑与U盘组合contains--A。国家：国与家继承is--A。人与员工
优点使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其它类造成的影响相对较小

点击借鉴