设计原则与设计模式

设计模式的六大原则

总原则：开闭原则（Open Close Principle）

开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类等，后面的具体设计中我们会提到这点。

单一职责原则

不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。

里氏替换原则（Liskov Substitution Principle）

里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科

历史替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它。

依赖倒转原则（Dependence Inversion Principle）

这个是开闭原则的基础，具体内容：面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。

接口隔离原则（Interface Segregation Principle）

这个原则的意思是：每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。

迪米特法则（最少知道原则）（Demeter Principle）

就是说：一个类对自己依赖的类知道的越少越好。也就是说无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。

最少知道原则的另一个表达方式是：只与直接的朋友通信。类之间只要有耦合关系，就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。

合成复用原则（Composite Reuse Principle）

原则是尽量首先使用合成/聚合的方式，而不是使用继承。

设计原则	设计原则定义	设计原则详解
开闭原则	开闭原则是指一个软件实体，如类、模块和函数应该对扩展开放,对修改关闭，也就是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。	https://geek-docs.com/design-pattern/design-principle/open-close-principle.html
里氏替换原则	里氏替换原则是关于继承的一个原则，遵循里氏替换原则能够更好地发挥继承的作用，里氏替换原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。	https://geek-docs.com/design-pattern/design-principle/liskov-substitution-principle.html
迪米特原则	迪米特原则它要求一个对象应该对其他对象有最少的了解，所以迪米特法则又叫做最少知识原则。	https://geek-docs.com/design-pattern/design-principle/law-of-demeter.html
单一职责原则	单一职责原则(Single Responsibility Principle)是面向对象设计原则的一种。单一职责原则是指不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。	https://geek-docs.com/design-pattern/design-principle/single-responsibility-principle.html
接口分离原则	接口分离原则指在设计时采用多个与特定客户类有关的接口比采用一个通用的接口要好。	https://geek-docs.com/design-pattern/design-principle/interface-segregation-principle.html
依赖倒置原则	依赖倒置原则指的是高层模块(稳定)不应该依赖于低层模块(变化)，二者都应该依赖于抽象(稳定)。抽象(稳定)不应该依赖于实现细节(变化)，实现细节应该依赖于抽象(稳定)。	https://geek-docs.com/design-pattern/design-principle/dependence-inversion-principle.html
组合/聚合复用原则	组合/聚合复用原则是指尽量使用组合/聚合，不要使用类继承。	https://geek-docs.com/design-pattern/design-principle/composite-aggregate-reuse-principle.html

23种设计模式

总体来说设计模式分为三大类：

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

设计模式	定义	设计模式详解
抽象工厂模式	抽象工厂模式(Abstract Factory Pattern)提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，属于对象创建型模式。	https://geek-docs.com/design-pattern/abstract-factory
工厂方法模式	工厂方法模式是简单工厂模式的进一步抽象和推广，是GoF设计模式的一种。由于使用了面向对象的多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。	https://geek-docs.com/design-pattern/factory-method
建造者模式	建造者模式(Builder Pattern)：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。	https://geek-docs.com/design-pattern/builder-pattern
原型模式	原型模式（Prototype Pattern）是一种创建型设计模式，使你能够复制已有对象，而又无需使代码依赖它们所属的类。	https://geek-docs.com/design-pattern/prototype-pattern
单例模式	单例模式(Singleton Pattern)是一种创建型设计模式， 让你能够保证一个类只有一个实例， 并提供一个访问该实例的全局节点。	https://geek-docs.com/design-pattern/singleton-pattern
适配器模式	适配器模式(Adapter Pattern) 是一种结构型设计模式， 它能使接口不兼容的对象能够相互合作。	https://geek-docs.com/design-pattern/adapter-pattern
桥接模式	桥接模式(Bridge Pattern)是一种结构型设计模式， 可将一个大类或一系列紧密相关的类拆分为抽象和实现两个独立的层次结构， 从而能在开发时分别使用。	https://geek-docs.com/design-pattern/bridge-pattern
组合模式	组合模式(Composite Pattern)是一种结构型设计模式， 你可以使用它将对象组合成树状结构，并且能像使用独立对象一样使用它们。	https://geek-docs.com/design-pattern/composite-pattern
装饰者模式	装饰者模式(Decorator Pattern) 是一种结构型设计模式， 允许你通过将对象放入包含行为的特殊封装对象中来为原对象绑定新的行为。	https://geek-docs.com/design-pattern/decorator-pattern
外观模式	外观模式(Facade Pattern)是一种结构型设计模式， 能为程序库、 框架或其他复杂类提供一个简单的接口。	https://geek-docs.com/design-pattern/facade-pattern
享元模式	是一种结构型设计模式， 它摒弃了在每个对象中保存所有数据的方式， 通过共享多个对象所共有的相同状态， 让你能在有限的内存容量中载入更多对象。	https://geek-docs.com/design-pattern/flyweight-pattern
代理模式	是一种结构型设计模式， 让你能够提供对象的替代品或其占位符。 代理控制着对于原对象的访问， 并允许在将请求提交给对象前后进行一些处理。	https://geek-docs.com/design-pattern/proxy-pattern
责任链模式	是一种行为型设计模式。允许你将请求沿着处理者链进行发送。 收到请求后， 每个处理者均可对请求进行处理， 或将其传递给链上的下个处理者。	https://geek-docs.com/design-pattern/chain-of-responsibility
命令模式	是一种行为设计模式， 它可将请求转换为一个包含与请求相关的所有信息的独立对象。	https://geek-docs.com/design-pattern/command-pattern
迭代器模式	是一种行为设计模式， 让你能在不暴露集合底层表现形式 （列表、 栈和树等） 的情况下遍历集合中所有的元素。	https://geek-docs.com/design-pattern/iterator-pattern
中介者模式	是一种行为设计模式， 能让你减少对象之间混乱无序的依赖关系。 该模式会限制对象之间的直接交互， 迫使它们通过一个中介者对象进行合作。	https://geek-docs.com/design-pattern/mediator-pattern
备忘录模式	是一种行为设计模式， 允许在不暴露对象实现细节的情况下保存和恢复对象之前的状态。	https://geek-docs.com/design-pattern/memento-pattern
观察者模式	是一种行为设计模式， 允许你定义一种订阅机制， 可在对象事件发生时通知多个 “观察” 该对象的其他对象。	https://geek-docs.com/design-pattern/observer-pattern
状态模式	是一种行为设计模式， 让你能在一个对象的内部状态变化时改变其行为， 使其看上去就像改变了自身所属的类一样。	https://geek-docs.com/design-pattern/state-pattern
策略模式	是一种行为设计模式， 它能让你定义一系列算法， 并将每种算法分别放入独立的类中， 以使算法的对象能够相互替换。	https://geek-docs.com/design-pattern/strategy-pattern
模板方法模式	是一种行为设计模式， 它在超类中定义了一个算法的框架， 允许子类在不修改结构的情况下重写算法的特定步骤。	https://geek-docs.com/design-pattern/template-method-pattern
访问者模式	是一种行为型设计模式， 访问者模式能将算法与其所作用的对象隔离开来。	https://geek-docs.com/design-pattern/visitor-pattern

并发型模式和线程池模式