六大设计原则基本概念

面向对象设计原则：它是设计和编码的指导思想，通过设计原则可以提升代码的扩展性和灵活性。

1、单一职责原则(SRP)：

• 一个类只负责一个功能领域中的相应职责，或者可以定义为，就一个类而言，应该只有一个引起它变化的原因。

• 单一职责原则是实现高内聚，低耦合的指导方针，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关的相互实践经验。

• 单一职责原则告诉我们，一个类不能太”大类”，职责太多。在软件系统中，一个类(大到模块，小到方法)承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，将相当于这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，因此要将这些职责进行分离，将不同的职责封装到不同的类中，如果多个职责总是同时发生改变则可将他们封装成同一个类中。

2、开闭原则(OCP):

• 一个软件实体(可以是一个模块或一个独立的类)应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

• 任何软件都需要面临一个很重要的问题，即它们的需求会随时改变的。当软件系统需要面临新的需求时，我们应该尽量保证系统的设计框架是稳定的。如果一个软件设计符合开闭原则，那么可以非常方便地对系统进行扩展，而且在扩展时无须修改现有代码，使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延续性。随着软件规模越来越大，软件寿命越来越长，软件维护成本越来越高，设计满足开闭原则的软件系统也变得越来越重要。

• 为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。我们通过接口、抽象类，可以定义系统的抽象层，再通过具体类来进行扩展。如果需要修改系统的行为，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，实现在不修改已有代码的基础上扩展系统的功能，达到开闭原则的要求。

  3、里氏替换原则(LSP):

• 所以引用基类(父类)的地方必须能透明地使用其子类的对象。
  1）子类可以实现父类的抽象父类的抽象方法，但不能覆盖父类的非抽象方法。
  2）子类中可以增加自己特有的扩展方法
  3）当子类的方法重载父类的方法时，方法的前置条件(即方法的参数要比父类方法的参数更宽泛)。
  4）当子类的方法实现父类的抽象方法时，方法的后置条件(即方法的返回值要比父类更严格)。

• 里氏替换原则告诉我们，尽量不要重写父类已经实现的方法，可以通过增加新的方法或实现接口扩展子类的功能。

  4、依赖倒置原则(DIP)：

• 抽象不应该依赖于细节，细节应该依赖于抽象。换言之，要针对接口编程，而不是针对具体实现编程。

• 依赖倒置原则要求我们在程序代码中传递参数或关联关系时，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到子类中增加的方法。

• 在实现依赖倒置原则时，需要针对抽象层编程，而将具体类的对象通过依赖注入(DI)的方式注入到其他对象中。

  5、接口隔离原则(ISP)：

• 使用多个专门的接口，而不适用单一的总接口，即客户端不应该依赖那些它不需要的接口。

• 根据接口隔离原则，当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需要知道与之相关的方法即可。每一个接口应该承担一种相对独立的职责。在使用接口隔离原则时，我们需要注意控制接口的粒度，接口不能太小，如果太小，会导致系统中的接口泛滥，不利于维护；接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。一般而言，接口中仅包含为某一功能的定制即可，不应该强迫客户端依赖于那些它们的方法。

  6、迪米特法则(LOD)：

• 一个软件实体应该尽可能少地与其他软件实体发生相互作用。

• 如果一个系统符合迪米特法则，那么当其中某一个模块发生修改时，就会尽量少地影响其他模块，扩展会相对容易，这是对软件实体之间通信的限制。迪米特法则要求限制软件实体之间的通知的宽度和深度。迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。

  六个原则之间不是单独存在的，它们之间存在着关系，在软件开发时，需要综合考虑设计原则。