设计模式六大原则

设计模式原则

六大原则：

1.开放封闭原则
Open-Close Principle（OCP）：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。目的就是保证程序的扩展性好，易于维护和升级。
开闭原则被称为面向对象设计的基石，实际上，其他原则都可以看作是实现开闭原则的工具和手段。意思就是：软件对扩展应该是开放的，对修改是封闭的，通俗来说就是，开发一个软件时，应该对其进行功能扩展，而在进行这些扩展时，不需要对原来的程序进行修改。
好处是：软件可用性非常灵活，扩展性强。需要新的功能时，可以增加新的模块来满足新需求。另外由于原来的模块没有修改，所以不用担心稳定性的问题。
笔记：开放封闭原则的一个重要的运用是在方法的参数上应该尽量减少采用基本类型，而是采用自己封装的数据类型或者接口作为形参。这样可以保证程序的拓展性，避免在业务发生变化时去修改原有的代码，直接通过OOP进行拓展。

2.单一职责原则
Single-Responsibilitiy Principle（SRP）：对一个类而言，应该仅有一个引起它变化的原因。如果存在多于一个动机去改变一个类，那么这个类就具有多于一个的职责，就应该把多余的职责分离出去，再去创建一些类来完成每一个职责。
举个例子：一个人身兼数职，而这些事情相关性不大，甚至有冲突，那他就无法很好的解决这些问题职责，应该分到不同的人身上去做。
单一职责原则是实现高内聚低耦合的最好方法，没有之一。
笔记：单一职责原则强调类的功能单一，降低保证每个类功能的独立性，降低耦合。

3.里士替换原则
Liskov Substitution Principle：子类可以扩展父类的功能，但是不能改变父类原有的功能。
在第一条原则开放封闭原则中，主张“抽象”和“多态”。维持设计的封装性“抽象”是语言提供的功能，“多态”由继承语意实现。因此如何去度量继承关系中的质量？
答案是：继承必须明确确保超类（父类）所拥有的性质在子类中仍然成立。
在面向对象的思想中，一个对象就是一组状态和一系列行为的组合体。状态是对象的内在特性，行为是对象的外在特性。LSP表述的就是在同一继承体系中的队形应该具有共同的行为特征。
笔记：继承的子类可以覆盖父类的方法，修改父类的属性，这样做语法上是允许的，但是应该尽量避免这样，特别是当子类与父类的方法在功能上是对立的时候。

4.依赖倒置原则
Dependence Inversion Principle（DIP）：是一个类与类之间的调用规则。这里的依赖就是代码中的耦合。高层模块不应该依赖底层模块，二者都应该依赖其抽象了；抽象不依赖细节；细节应该依赖抽象。接口编程。
主要思想就是：如果一个类中的一个成员或者参数成为一个具体的类型，那么这个类就依赖这个具体类型。如果在一个继承结构中，上层类中的一个成员或者参数为一个下层类型，那么就是这个继承结构高层依赖底层，就要尽量面向抽象或者接口编程。
笔记：在程序尽量减少上层应用或者服务直接调用下层的类以及属性方法，这样会造成程序耦合度增加。例如A类需要实现一个方法，需要调用B类中的一个方法，这时如果直接在A类引用B的方法，会造成耦合增加。这时应该将B类中的方法抽象为接口，A类中引用该接口。这样做一方面可以减低耦合，提高程序扩展性（如果此时A功能发生变化，只需要在接口的基础上写一个实现类C去实现该功能，无需对原有的代码进行修改，符合原则1），同时接口较之普通的类更加稳定标准，不易出错。

5.接口隔离原则
接口隔离原则（Interface Segregation Principle）：用于恰当的划分角色和接口，具有两种含义：1、用户不应该依赖它不需要的借口；2、类间的依赖关系应该建立在最小的的接口上。
将这两个定义概括为一句话：建立单一接口，代替庞大臃肿的接口。通俗来说就是：接口尽量细化，同时保证接口中的方法尽量的少。一个接口中包含太多的行为时，会导致它们与客户端的不正常依赖关系，要做的就是分离接口，从而实现解耦。

6.最小知识原则
Law of Demeter（最小知识原则）：一个对象应该对其他对象有最少的了解。通俗来说就是，一个类对自己需要耦合或者调用的类知道的最少，你类内部怎么复杂，我不管，那是你的事，我只知道你有那么多公用的方法，我能调用。
迪米特原则不希望类与类之间建立直接的接触。如果真的需要有联系，那么就通过它们的友元类来传达。举例来说：你需要买房子了，现在存在三座合适的楼盘A，B，C，但是你不必直接去楼盘买楼，而是在售楼处去了解情况。这样就减少了你（购房者）与楼盘两个类之间耦合。
但是应用迪米特原则很可能会造成一个后果：系统会存在大量的中介类，这些类（如上面的售楼处类）之所以存在是为了传递类之间的相互调用关系，这就一定会程度上增加了系统的复杂度。
迪米特原则核心观念就是：类间解耦，弱耦合。