面向对象的七大原则和设计模式

1. 面向对象七大原则

一、单一职责原则

定义：一个类应该只有一个变化的原因。

优点：

1. 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
2. 提高类的可读性。复杂性降低，自然其可读性提高。
3. 提高系统得可维护性。可读性提高，自然更容易维护了。
4. 变更引起得风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其它功能的影响。

缺点：

1. 会增加类的数量。以前一个类负责多项职责，现在只负责一项职责，自然类的数量会增加。
2. 如果职责颗粒度划分太细，会降低类的内聚性。  

二、里氏替换原则

定义：子类可以扩展父类的功能，但不能修改父类原有的功能。

优点：

1. 加强程序的健壮性，降低程序代码潜在的风险。

缺点：

1. 降低了子类的灵活性。

三、开放封闭原则

定义：软件实体应该是可拓展的，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。

优点：

1. 方便扩展，提高了软件的可维护性。
2. 不影响已有功能，提高了系统稳定性和减少了重复测试。
3. 扩展之前的逻辑，提高了代码复用性。

四、依赖倒置原则

定义：程序要依赖于抽象接口，不要依赖具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

优点：

1. 减少类之间的耦合。
2. 降低并行开发引起的风险。

缺点：

1. 抽象需要新增接口或者抽象类。
2. 代码的可读性会变差。

五、接口隔离原则

定义：客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上。

优点：

1.  将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
2. 提高系统内聚性，减少对外互动，降低系统的耦合性。
3. 如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整个项目带来无法预料的风险。
4. 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
5. 能减少项目工程中的代码冗余。过大的接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余代码。

六、最小知识原则

定义：一个类对于其他类知道的越少越好，就是说一个对象应当对其他对象尽可能少的了解，只和朋友通信，不和陌生人说话。

朋友包括：

• 当前对象本身(this)
• 以参数形式传入到当前对象方法中的对象
• 当前对象的成员对象
• 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友。
• 当前对象创建的对象

优点：

1. 降低模块间的耦合，提升了软件的可维护性和可重用性。

缺点:

1. 可能导致不得不在类中设计出很多用于中转的包装方法，这会提升类设计的复杂度。

七、合成复用原则

定义：尽量使用对象组合，而不是继承来达到复用的目的。

优点：

1. 维持了类的封装性。因为成员对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
2. 新旧类之间的耦合度低。这种复用所需的依赖少，新对象存取成员对象的唯一方法是通过成员变量的接口。
3. 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成员对象类型相同的对象。

2. 设计模式的分类

创建型设计模式 与对象创建有关包括单例模式，工厂方法模式，抽象工厂模式，建造者模式，原型模式

结构型设计模式 结构性设计模式是从程序的结构上解决模块之间的耦合问题，包括适配器模式， 代理模式，装饰模式，外观模式，桥接模式，组合模式和享元模式

行为型设计模式 主要处理类或对象如何交互及如何分配职责，包括策略模式，模板方法模式，观察者模式，迭代器模式，责任链模式，命令模式，备忘录模式，状态模式，访问 者模式，中介模式，解析器模式