java设计模式

前言：

花了五天的时间在课外把设计模式大概看了一遍，做了点笔记。不能说掌握了多少，但确实有一些体会：
1.设计模式是一种思想，很抽象，光看概念很难理解，需要放到实际案例中去思考才能更好的理解 。
2. 要理解设计模式得学会看UML类图，因为你在通过看实际案例的过程中，光看代码去理解这个这整个的结构框架是很难的，此时UML类图就起到很好的帮助作用。
3. 设计模式的宗旨就是为了提高代码的重用性、可靠性、可扩展性、并且更易理解。

一. 设计模式思维导图

java中设计模式，常用的有23种，分三大类型。
以下是整理后的思维导图：

二. 七大设计原则：

1.单一职责原则

单一职责原则（Single Responsibility Principle，简称SRP）

职责：就是对象能够承担的责任，并以某种行为方式来执行。

定义：一个类只有一个引起它变化的原因。 单一职责原则保证了对象的高内聚和细粒度。
注：单一职责并不是极端地要求我们只能为类定义一个职责，只是利用极端的表述方式重点强调，在定义对象时，必须考虑职责和对象之间的所属关系。“单一职责”指的是公开在外的与该对象紧密相关的一组职责。
优点：
1.降低类的复杂性，
2.提高类的可读性
3.提高类代码的可维护性和复用性
4.降低因变更引起的风险

2.里氏替换原则

里氏替换原则（Liskov Substitution Principle，简称LSP）
定义：如果一个类型为S的对象o1，都有类型为T的对象o2，使得以S定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T是类型S的子类型。
通俗讲：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。
里氏替换要求凡是使用基类的地方，子类一定使用，这就要求子类必须具备基类的所有接口。
体现在：策略模式、组合模式、代理模式

3.依赖倒置原则

依赖倒置原则（DePendence Inversion Principle ，简称DIP）
定义：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象
在项目中，只要抓住“面向接口编程”就基本抓住了依赖倒置原则。
作用：减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。
依赖倒置原则是最难实现的原则，它是实现开闭原则的重要途经，依赖倒置原则没有实现，就不能实现对扩展的开放，对修改的关闭。

4.接口隔离原则

接口隔离原则（Interface Segregation Principle , 简称ISP）
定义：客户端不应该依赖它不需要的接口。
核心： 1.一个类对另外一个类的依赖性应当是建立在最小的接口上的。
2. 使用对各专门的接口比使用单一的总接口要好。
3. 不应该强迫客户使用依赖于它们不用的方法。

5.迪米特法则

迪米特法则（Law of Demeter,简称LoD）

定义：一个对象应当对其他对象尽可能少的了解。只与你直接的朋友通信，假设你要调用另一个类的方法，可以通过第三方类转发这个调用。
核心就是类之间的解耦、弱耦合，只有弱耦合了以后，类的复用率才可以提高。

6.开闭原则

开闭原则（Open-Closed Princle，简称OCP)
定义：一个软件实体应当对扩展开放，对修改关闭。
作用：提高复用性、可维护性、灵活性，易于测试
。

7.合成复用原则

合成复用原则（Composite Reuse Principle）
定义：原则是尽量使用合成/聚合的方式，而不是使用继承
核心思想：

1. 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代 码混在一起。
2. 针对接口编程，而不是针对实现编程。
3. 为了交互对象之间的松耦合设计而努力

创建型：

1.单例模式2.工厂方法模式3.象工厂模式4.建造者模式5.原型模式

单例模式（Singleton Pattern）：一个类只有一个实例，而且自行实例化并向整个系统提供这这个实例。

工厂方法模式(Factory Pattern)：工厂类成为抽象类，实际的创建工作由子类来完成。定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中去，强调的是“单个对象”的变化。

抽象工厂模式(Abstrat Factory)：抽象工厂是所有工厂模式中最抽象和最具有一般性的一种状态。抽象工厂可以向用户提供一个接口，使得用户可以在不必指定产品具体类型的情况下，创建多个产品族中的产品对象，强调的是“系列对象”的变化。

建造者模式(Builder Pattern)：把对象实例的逻辑移到了类的外部，在类的外部定义了该类的够着逻辑。它把一个复杂对象的够着过程从对象的表示中分离出来，其直接效果是将一个复杂的对象简化为一个比较简单的目标对象，强调的是产品的构造过程。

原型模式(Prototype Pattern)：同工厂模式一样，对客户隐藏了对象创建工作，不同的是，原型模式是通过复制一个现有的对象生成新的对象。

结构型

讨论的是类和对象的结构。采用继承机制来组合接口和实现（类结构型模式），或者通过组合一些对象实现新的功能（对象结构模式）。

代理模式(Proxy)：为其他对象创建一个代理以控制对该对象的访问。

装饰模式(Decorator)：动态的给一个对象添加额外的职责，就增加功能来说，装饰模式比生成字类更为灵活。

适配器模式(Adapter)：将一个类的接口变换成客户端所期待的另一个接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。

组合模式(Composite)：也叫合成模式，将对象组合成树形结构以表示”部分——整体“的层次结构，是的用户对单个对象和组合对象的使用具有一致性。

桥梁模式(Bridge)：也叫桥接模式。将抽象和实现解耦，使得两者可以独立变化。

外观模式(Facade)：也叫门面模式，要求一个子系统的外部与内部的通信必须通过一个统一的对象进行，外观模式提供一个高层次的接口，是的子系统更易于使用。

享元模式Flyweight：使池技术的重要实现方式，使用共享对象可有效的支持大量的细粒度的对象。

行为型

模板方法模式(Template Method)：定义一个操作中的算法的框架，而将一些步骤延迟到字类中，使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

命令模式(Command)：是一种该内聚的模式，将一个请求封装成一个对象，从而使用不同的请求把客户端参数化，对请求排队或者
记录请求日志，可以提供命令的撤销和恢复功能。

责任链模式(Chain of Responsibility)：使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。

策略模式(Strategy)：也叫政策模式。定义一组算法，将每个算法封装起来，使它们之间可以互换。

迭代器模式(Iterator)：提供一种方法访问一个容器对象中的各个元素，而又不需要暴露该对象的内部细节。

中介者模式(Mediator)：用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示的相互作用，从而使其耦合松散，而且可以独立地改变她们之间的交互。

观察者模式(Observer)：也叫发布订阅模式，定义对象间的一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖与它的对象都会得到通知并被自动更新。

备忘录模式(Memento)；在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。

访问者模式(Visitor)：封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。

状态模式(State)：当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类型，状态模式的核心时封装。状态的变更引起行为的变更。

解释器模式(Interpreter)：给定一门语言，定义它的文法的一种表示，并定义也给解释器，该解释器使用该文法表示来解释语言中的句子。

光看这些，对自己后续理解查阅还是不够的
接下来目标：细化一下，添加一些案例和UML类图

后续详情还在整理中。