设计模式六大原则

1.单一职责原则(SRP，Single Responsibility Principle)

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

简单的讲就是我们不要让一个类承担过多的职责，一个类从大到模块，小到方法承担的职责越多，它被复用的可能性就越小，就相当于把这些职责耦合在一起。当其中一个职责发生变化，可能会影响到其他职责的正常运行工作。所以要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。

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

2.开放封闭原则( OCP，Open-Closed Principle)

概念：软件实体应当对扩展开放对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展，也就是说类、模块、函数等应该是可以拓展的，但是原有代码不可修改。

软件实体可以是一个软件模块、一个由多个类组成的局部结构或一个独立的类。也就是说我们在开发一款新产品设计架构时，要注意在以后的更新迭代中可以非常方便地对系统进行扩展。而且在扩展时无须修改现有代码，使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延续性。因为一款软件，他的功能需求会随着时间的推移不断发生变化，也就是我们常说的产品迭代。随着时间的推移代码量越来越大，维护成本越来越高，所以利用开放封闭原则进行软件设计非常有必要。

3.里氏替换原则(LSP，Liskov Substitution Principle)

概念：里氏代换原则告诉我们，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。

里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。
在使用里氏代换原则时需要注意一些问题：
a.子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法。根据里氏代换原则，为了保证系统的扩展性，在程序中通常使用父类来进行定义，如果一个方法只存在子类中，在父类中不提供相应的声明，则无法在以父类定义的对象中使用该方法。
b.我们在运用里氏代换原则时，尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法，运行时，子类实例替换父类实例，我们可以很方便地扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。里氏代换原则是开闭原则的具体实现手段之一。
c.Java语言中，在编译阶段，Java编译器会检查一个程序是否符合里氏代换原则，这是一个与实现无关的、纯语法意义上的检查，但Java编译器的检查是有局限的。

4.依赖倒置原则(DIP，Dependency Inversion Principle)

概念：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。

依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。
在Java中，抽象就是指接口或者抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或者继承抽象类而产生的就是细节，也就是可以加上一个关键字new产生的对象。高层模块就是调用端，低层模块就是具体实现类。
依赖倒置原则在Java中的表现就是：模块间通过抽象发生，实现类之间不发生直接依赖关系，其依赖关系是通过接口或者抽象类产生的。如果类与类直接依赖细节，那么就会直接耦合，那么当修改时，就会同时修改依赖者代码，这样限制了可扩展性。

5.迪米特原则(LOD，Law of Demeter)

概念：一个软件实体应当尽可能少地与其他实体发生相互作用。

如果一个系统符合迪米特法则，那么当其中某一个模块发生修改时，就会尽量少地影响其他模块，扩展会相对容易，这是对软件实体之间通信的限制，迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。
迪米特法则要求我们在设计系统时，应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需要调用另一个对象的某一个方法的话，可以通过第三者转发这个调用。简言之，就是通过引入一个合理的第三者来降低现有对象之间的耦合度。
在将迪米特法则运用到系统设计中时，要注意下面的几点：在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波及；在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限；在类的设计上，只要有可能，一个类型应当设计成不变类；在对其他类的引用上，一个对象对其他对象的引用应当降到最低。

6.接口隔离原则(ISP，Interface Segregation Principle)

概念：：一个类对另一个类的依赖应该建立在最小的接口上。

使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
采用接口隔离原则对接口进行约束时，要注意以下几点：
a.接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
b.为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
c.提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

这六大原则，可以使我们的应用系统在更新迭代以及开发过程中代码逻辑更加清晰，让我们的软件在开发维护中更加灵活