23种设计模式（前言）
23种设计模式（前言）
（愿岁月清净）
1.了解设计模式
设计模式（Design Pattern）是前辈们对代码开发经验的总结，是解决特定问题的一系列套路。是一套用来提高代码可复用性、可维护性、可读性、稳健性以及安全性的解决方案。
1995 年，GoF（Gang of Four，四人组/四人帮）合作出版了《设计模式：可复用面向对象软件的基础》一书，共收录了 23 种设计模式，从此树立了软件设计模式领域的里程碑，人称「GoF设计模式」。（据说挺帅的）- -！
2.学习设计模式的意义
这 23 种设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性，以及类的关联关系和组合关系的充分理解。
(本教程虽然命名为“Java设计模式”，但是设计模式并不是 Java 的专利，它同样适用于 C++、C#、JavaScript 等其它面向对象的编程语言。)
3.23种模式
（一）创建型模式
- 单例模式（单例设计模式）
- 工厂模式
- 抽象工厂模式
- 建造者模式（Bulider模式）
- 原型模式
（二）结构型模式
- 代理模式（代理设计模式）
- 适配器模式（Adapter模式）
- 桥接模式（Bridge模式）
- 装饰模式（装饰设计模式）
- 外观模式（Facade模式）
- 享元模式（详解版）
- 组合模式（详解版）
（三）行为型模式
- 模板方法模式（模板方法设计模式）
- 策略模式（策略设计模式）
- 命令模式
- 责任链模式（职责链模式）
- 状态模式
- 观察者模式（Observer模式）
- 中介者模式
- 迭代器模式
- 访问者模式（Visitor模式）
- 备忘录模式
- 解释器模式
4.OOP七大原则
1.开闭原则
对扩展开放，对修改关闭。
当需求发生变化时，在不修改软件实体源代码的情况下，可以进行功能扩展，使其满足新需求。
2.里氏替换原则
继承必须确保超类所拥有的性质在子类中仍然成立。
通俗来讲就是，子类可以扩展父类的功能，但不能改变父类原有的功能，即不可以重写父类的方法。
如果通过重写父类方法扩展新功能，写起来可能会很简单，但这会使整个继承体系的可复用性变得很差，特别是运用多态比较频繁时，程序很有可能会运行错误。
典型案例，“正方形不是长方形”，“鸵鸟不是鸟”。
3.依赖倒置原则
要面向接口编程，不要面向实现编程。
原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。
依赖倒置原则是实现开闭原则重要途径之一。
4.单一职责原则
控制类的粒度大小，将对象解耦，提高其内聚性。
职责指类变化的原因，一个类应当有且只有一个引起它变化的原因，若有多个则该类需要拆分。如果一个对象承担了太多职责，至少会存在以下两个缺点：
一、当一个职责变化时，可能会削弱或抑制该类实现其他职责的能力。
二、当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。
单一职责同样也适用于方法。一个方法应该尽可能做好一件事情，如果一个方法处理的事情太多，其颗粒度会变得很粗，不利于重用。
5.接口隔离原则
要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：
单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。
6.迪米特法则
只与你的直接朋友交谈，不跟“陌生人”说话。
简单来说就是，如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
但过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。
7.合成复用原则
软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。组合是“has a”关系，继承是“is a”关系。
组合就是A类的对象是B类的成员变量，相当于 A类是B类对象的一个属性。
例如，Dog类和Animal类应该使用继承关系，因为狗是动物；Person类和Head类应该使用组合关系，因为头是组成人体的一部分，即人有头。