Java设计模式（一）
设计模式（Design Pattern）是一套被反复使用、多数人知晓、经过分类编目的优秀代码设计经验的总结。
Java设计模式贯彻的原理是：面向接口编程，而不是面向实现。其目标原则是：降低耦合，增强灵活性。
常用的设计模式可以概括为23种，按照特点可以将其分为三大类型：
创建型
创建型模式主要用来创建对象的模式，抽象了实例化的过程，有两个主要功能：
将系统所使用的具体类的信息封装起来；
隐藏类的实例是如何被创建和组织的。外界对于这些对象只知道它们共同的接口，而不清楚其具体的实现细节。
常见的创建型设计模式有下列几种：
单例模式：保证一个类中只有一个实例，自行实例化并向系统提供该实例。
工厂方法模式：工厂类成为抽象类，实际的创建工作由具体子类来完成。
抽象工厂模式：抽象工厂可以向客户提供一个接口，使得客户可以在不必指定产品具体类型的情况下，创建多个产品族中的产品对象，强调的是“系列对象”的变化。
建造者模式：把构造对象实例的逻辑移到了类的外部，在类的外部定义了该类的构造逻辑。
原型模式等：和工厂模式一样，不同点在于复制一个现有对象来生成新对象。
结构型
结构型模式讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象实现新的功能（对象结构型模式）。
常见的结构型设计模式有以下几种。
代理模式（Proxy）：为其他对象提供一种代理以控制对该对象的访问。
装饰模式（Decorator）：动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。
适配器模式（Adapter）：将一个类的接口变换成客户端所期待的另一接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作
组合模式（Composite）：也叫合成模式，将对象组合成树形结构以表示“部分—整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。
桥梁模式（Bridge）：也叫桥接模式，将抽象和实现解耦，使得两者可以独立变化。
外观模式（Facade）：也叫门面模式，要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行，外观模式提供一个高层次的接口，使得子系统更易于使用。
享元模式（Flyweight）：是池技术的重要实现方式，使用共享对象可有效地支持大量的细粒度的对象。
行为型
行为型设计模式关注的是对象的行为，用来解决对象之间的联系问题，常见的行为型设计模式有以下几种。
模板方法模式（Template Method）：定义一个操作中的算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
命令模式（Command）：是一种高内聚的模式，将一个请求封装成一个对象，从而使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。
责任链模式（Chain of Responsibility）：使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。
策略模式（Strategy）：也叫政策模式，定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。
迭代器模式（Iterator）：提供一种方法访问一个容器对象中的各个元素，而又不需要暴露该对象的内部细节。
中介者模式（Mediator）：用一个中介对象封装一系列的对象交互，中介者使各对象不需要显式地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
观察者模式（Observer）：也叫发布订阅模式，定义对象间的一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。
备忘录模式（Memento）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
访问者模式（Visitor）：封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
状态模式（State）：当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类型，状态模式的核心是封装，状态的变更引起行为的变更。
解释器模式（Interpreter）：给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该文法表示来解释语言中的句子。
七大原则
架构的设计思想包含七大原则：
开闭原则（Open-Closed Principle）
单一职责原则（Simple Responsibility Pinciple）
里氏替换原则（Liskov Substitution Principle）
依赖倒转原则（Dependence Inversion Principle）
接口隔离原则（Interface Segregation Principle）
迪米特法则（最少知道原则）（Demeter Principle）
合成复用原则（Composite Reuse Principle）
开闭原则
开闭原则（Open-Closed Principle, OCP）是指一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
所谓的开闭，也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架，用实现扩展细节。
单一职责原则(SRP)
单一职责原则的英文名称是Single Responsibility Principle，简称SRP。
每个类都应该实现其单一的职责，如果无法满足的话，则应该将类拆分来承担单一的职责。
里式替换原则(LSP)
里氏替换原则的英文名称是：Liskov Substitution Principle，简称LSP。里氏替换原则是面向对象程序设计的基本原则之一。
它的意思是说，任何基类可以出现的地方，子类一定可以出现。
子类对父类的方法尽量不要重写和重载。因为父类代表已经定义好的结构，通过这个规范的接口与外界交互，子类不应该破坏。（基类不变，子类扩展）
依赖倒转原则(DIP)
依赖倒置原则英文名称是：Dependence Inversion Principle，简称DIP。
在Android开发中的MVP架构就是典型的依赖倒转原则，依赖倒转是开闭原则的基础，是面向接口编程的方式。
当面向接口编程时，依赖于抽象而不依赖于具体，也就是说不直接和具体的类进行交互，而是和具体类的上层接口交互。
接口隔离原则(ISP)
每个接口中尽量保证不存在子类用不到却必须实现的方法，如果存在则需要将接口进行拆分。使用多个接口进行隔离，这样就比单个接口中实现多个方法要好。
一个类对另外一个类的依赖性应当是建立在最小的接口上的。
两种定义解释如下：
客户端不应该依赖它不需要的接口。
类间的依赖关系应该建立在最小的接口上。
迪米特法则(LOD)
一个类对自己所依赖的类知道的越少越好。无论被依赖的类多么复杂，都应该将逻辑封装在方法内部，通过public方法提供给外部调用。这样即使被依赖的类变化时，也能做到最小的影响该类。
迪米特法则不同于其他的OO设计原则，它具有很多种表述方式，其中具有代表性的是以下几种表述：
只与你直接的朋友们通信（Only talk to your immediate friends）；
不要跟“陌生人”说话（Don't talk to strangers）；
每一个软件单位对其他的单位都只有最少的了解，这些了解仅局限于那些与本单位密切相关的软件单位。
如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用；如果一个类需要调用另一个类的某一个方法，可以通过第三者转发这个调用。
合成复用原则（CRP）
合成复用原则（Composite Reuse Principle，CRP）又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
七大原则总结
各种原则要求的侧重点不同，下面我们分别用一句话归纳总结软件设计模式的七大原则，如下表所示。
| 设计原则 | 一句话归纳 | 目的 |
|---|---|---|
| 开闭原则 | 对扩展开放，对修改关闭 | 降低维护带来的新风险 |
| 依赖倒置原则 | 高层不应该依赖低层，要面向接口编程 | 更利于代码结构的升级扩展 |
| 单一职责原则 | 一个类只干一件事，实现类要单一 | 便于理解，提高代码的可读性 |
| 接口隔离原则 | 一个接口只干一件事，接口要精简单一 | 功能解耦，高聚合、低耦合 |
| 迪米特法则 | 不该知道的不要知道，一个类应该保持对其它对象最少的了解，降低耦合度 | 只和朋友交流，不和陌生人说话，减少代码臃肿 |
| 里氏替换原则 | 不要破坏继承体系，子类重写方法功能发生改变，不应该影响父类方法的含义 | 防止继承泛滥 |
| 合成复用原则 | 尽量使用组合或者聚合关系实现代码复用，少使用继承 | 降低代码耦合 |