面向对象的设计原则与设计模式

目的

设计模式的目的是提高代码的重用性，可读性、可扩展性、可靠性，使程序呈现高内聚，低耦合的特性

原则

单一职责原则

假设有一个class负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能会导致另一个职责的功能发生故障。这样一来，这个class就存在两个导致类变更的原因。如何解决这个问题呢？我们就要分别用两个Class来实现两个职责，进行解耦。后期需求变更维护互不影响。这样的设计，可以降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险。

单一职责注意事项：

降低类的复杂度，一个类只负责一项职责；

提高类的可读性，可维护性；

降低变更引起的风险。

依赖倒置原则

依赖倒置原则（Dependency Inversion Principle, DIP） ：指设计代码结构时，高层模块不应该依赖底层模块，二者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。通过依赖倒置，可以降低类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并降低修改程序带来的风险。

依赖倒置原则注意事项：

变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化。

以抽象为基准比以细节为基准搭建起来的架构要稳定得多，因此大家再拿到需求后，要面向抽象编程，按照先顶层再细节的顺序设计代码结构。

开闭原则

开闭原则（Open-Closed Principle，OCP） ：指一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。强调的是用抽象构建框架，用实现扩展细节，当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化，可以提高软件系统的可复用性及可维护性。

本质：

其本质是指：当在一个设计中增加新的模块时，不需要修改现有的模块。

开闭原则是面向对象设计中最基础的设计原则，他的核心思想是面向抽象编程。

依赖倒置原则与开闭原则的关系：

依赖倒置原则是程序要依赖于抽象接口，不要依赖于具体实现。

当设计某些系统时，经常需要面向抽象来考虑系统的总体设计，不要考虑具体类，这样容易设计出满足“开-闭原则”的系统。

在程序设计好以后，首先要对抽象类（或接口）的修改关闭，否则，一旦修改抽象类（或接口），将可能导致它的所有子类（或实现类）都需要作出修改；应当对增加抽象类的子类（或接口的实现类）开放，即在增加新的子类（或实现类）时，不需要修改其他面向抽象类（或接口）而设计的重要类，例如案例中的Pillar类。

接口隔离原则

接口隔离原则（Interface Segregation Principle, ISP）：指用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口。

接口隔离原则注意：

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

建立单一接口，不要建立庞大臃肿的接口。

尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）。

里氏替换原则

里氏替换原则（Liskow Substitution Principle，LSP） ：如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P的所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。

可以理解为一个软件实体如果适用于一个父类，则一定适用于其子类，所有引用父类的地方必须能透明地使用其子类对象，子类对象能够替换父类对象，而程序逻辑不变。也可以理解为，子类可以扩展父类的功能，但不能改变父类原有的功能。

迪米特法则

迪米特法则（Law of Demeter，LoD） ：又叫最少知道原则，即一个类对自己依赖的类知道的越少越好，尽量降低类与类之间的耦合。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供public方法，不对外泄露任何信息。

迪米特法则还有个更简单的定义：只与朋友说话，不和陌生人说话。朋友：出现在成员变量、方法参数，方法返回值中的类为直接的朋友，出现在方法体内部的类不属于朋友类。

组合复用原则

组合复用原则（Composite Reuse Principle, CRP） ：尽量使用对象组合（has-a）或对象聚合（contains-a）的方法实现代码复用，而不是用继承关系达到代码复用的目的。合成复用原则可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较小

设计模式的分类

一般可以按照设计模式的目的（模式是用来做什么的）将其分为创建型(Creational)，结构型(Structural)和行为型(Behavioral)3种：

 创建型模式：主要用于创建对象。

 结构型模式：主要用于处理类或对象的组合。

 行为型模式：主要用于描述对类或对象怎样交互和怎样分配职责。

创建型模式：

涉及对象的实例化。这类模式的特点是，不让用户代码依赖于对象的创建或排列方式，避免用户直接使用new运算符创建对象。包括：

抽象工厂模式(Abstract Factory)

建造者模式(Builder)：又称生成器模式

工厂方法模式(Factory Method)

原型模式(Prototype)

单例模式(Singleton)  ：又称单件模式

结构型模式：

涉及如何组合类和对象以形成更大的结构，和类有关的结构型模式涉及如何合理地使用继承机制，和对象有关的结构型模式涉及如何合理地使用对象组合机制。包括：

抽象适配器模式(Adapter)

桥接模式(Bridge)

组合模式(Composite)

装饰模式(Decorator)

外观模式(Facade)

享元模式(Flyweight)

代理模式(Proxy)

行为型模式：

涉及怎样合理地设计对象之间的交互通信，以及怎样合理地为对象分配职责，让设计富有弹性、易维护、易复用。包括：

职责链模式(Chain of Responsibility)

命令模式(Command)

解释器模式(Interpreter)

迭代器模式(Iterator)

中介者模式(Mediator)

备忘录模式(Memento)

观察者模式(Observer)

策略模式(Strategy)

状态模式(State)

模板方法模式(Template Method)

访问者模式(Visitor)

简单工厂模式

模式定义

简单工厂模式(Simple Factory Pattern)：又称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

简单工厂模式的优点

工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅“消费”产品；简单工厂模式通过这种做法实现了对责任的分割，它提供了专门的工厂类用于创建对象。

客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，对于一些复杂的类名，通过简单工厂模式可以减少使用者的记忆量。

通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。

简单工厂模式的缺点

由于工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。

使用简单工厂模式将会增加系统中类的个数，在一定程序上增加了系统的复杂度和理解难度。

系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。

简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。