设计模式(Java版)总结

设计模式(Java版)总结
1 设计模式分类
1.1 创建型
创建型模式是用来创建对象的模式，抽象了实例化的过程，帮助一个系统独立于其关联对象的创建、组合和表示方式。所有的创建型模式都有两个主要功能：
n 将系统所使用的具体类的信息封存起来；
n 隐藏类的实例是如何被创建和组织的。外界对于这些对象只知道他们共同的接口，而不清楚其具体的实现细节。
1.2 结构型
结构型模式讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象实现新的功能（对象结构型模式）。这些结构型模式在某些方面具有很大的相似性，单侧重点却各有不同。
1.3 行为性
行为型设计模式关注的是对象的行为，用来解决对象之间的联系问题。
2 设计原则
2.1 单一职责原则
定义：There should never be more than one reason for a class to change.
一个类应当只有一个引起它变化的原因：即一个类应该只有一个职责。
2.2 里氏替换原则Liskov Substitution Principle.
定义：If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of S, the behavior of P is unchanged when o1 is substituted for o2 then T is a subtype of S.
如果对一个类型为S的对象o1，都有类型为T的对象o2，使得以S定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T是类型S的子类型。
2.3 依赖倒置原则
定义:High level modules should not depend upon low modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
n 高层模块不应该一类底层模块，两者都依赖其抽象；
n 抽象不依赖细节；
n 细节应该依赖于抽象。
2.4 接口隔离原则
定义：Client should not be forced to depend upon interfaces that they don’t use.
客户端不应该依赖它不需要的接口。
2.5 迪米特法则
n 只与你直接的朋友们通信
n 不要跟“陌生人”说话
n 每一个软件单位对其他的单位都只有最少的了解，这些了解仅局限于那些与本单位密切相关的软件单位。
2.6 开闭原则
定义：Software entities should be open for extension, but closed for modification.
一个软件实体应当对扩展开放，对修改关闭。
3 创建型模式
3.1 单例模式
3.1.1 定义
Ensure a class has only one instance, and provide a global point of access to it.
确保一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。
3.1.2 优点
n 由于单例模式在内存中只有一个实例，减少了内存的开支。
n 避免对资源的多重利用。
n 可以在系统设置全局的访问点。
3.1.3 缺点
n 无法创建子类，扩展困难。
n 对测试不理。
n 单例模式与单一职责原则有冲突。
3.2 工厂方法模式
3.2.1 定义
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
定义一个用于创建对象的接口，让子类决定实例化哪个类。工厂方法使一个类的实例化延迟到子类。
3.2.2 优点
良好的封装性，代码结构清晰。
优秀的可拓展性。
屏蔽产品类。
是典型的解耦框架。
3.3 抽象工厂模式
3.3.1 定义
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
创建一组相关或相互依赖的对象提供一个接口，而且无须制定它们的具体类。
3.4 建造者模式
3.4.1 定义
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
将一个复杂对象的构建于它的表示分离，使得同样的建构过程可以创建不同的表示。
3.4.2 应用场景
n 相同的方法，不同的执行顺序，产生不同的结果是，可以采用建造者模式。
n 多个部件或零件，都可以装配到一个对象中，但是产生的运行结构又不相同时，则可以使用该模式。
n 产品类非常复杂，或者产品类中的方法调用顺序不同产生了不同的效能，这个时候使用建造者模式。
n 在对象创建过程中会使用到系统的一些其他对象，这些对象在产品对象的创建过程中不易得到。
3.5 原型模式
3.5.1 定义
Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。
3.5.2 应用场景
n 资源优化场景，类初始化需要消耗非常多的资源，这个资源包括数据、硬件资源等。
n 性能和安全要求的场景，通过new产生一个对象需要非常繁琐的数据准备或访问权限，可以使用原型模式。
n 一个对象多个修改者的场景，一个对象需要提供为其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式复制多个对象供调用者使用。
4 结构型模式
4.1 代理模式
4.1.1 定义
Provide a surrogate or placeholder for another object to control access to it.
为其他对象提供一种代理以控制对这个对象的访问。
4.2 装饰模式
4.2.1 定义
Attach additional responsibilities to an object dynamically keeping the same interface. Decorators provide a flexible alternative to subclassing for extending functionality.
动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式比生成子类更为灵活。
4.2.2 应用场景
n 需要扩展一个类的功能，或给一个类增加附加功能。
n 需要动态的给一个对象增加功能，这些功能可以再动态地撤销。
n 需要为一批类进行改装或加装功能。
4.3 适配器模式
4.3.1 定义
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.
将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。
4.4 组合模式
4.4.1 定义
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
将对象组合成树形结构以表示“部分——整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。
4.4.2 应用场景
n 需要描述对象的部分和整体的等级结构，如树形菜单、文件和文件夹管理。
n 需要客户端忽略个体构件和组合构件的区别，平等对待所有的构件。
4.5 桥梁模式
4.5.1 定义
Decouple an abstraction from its implementation so that the two can vary independently.
将抽象和实现解耦，使得两者可以独立地变化。
4.5.2 应用场景
n 如果一个系统需要在构建的抽象化角色和具体角色之间增加更多的灵活性，避免在两层次之间建立静态的联系。
n 涉及要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
n 一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
n 不希望或不适合使用继承的场合。
4.6 外观模式
4.6.1 定义
Provide a unified interface to a set of interfaces in a subsystem. Façade define a higher-level interface that makes the subsystem easier to use.
要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。外观模式提供一个高层次的接口，使得子系统更易使用。
4.6.2 应用场景
n 为一个复杂的模块或子系统提供一个供外界访问的接口。
n 子系统相对独立，外界对子系统的访问只要黑箱操作即可。
n 预防风险扩散，使用Façade进行访问操作控制。
4.7 享元模式
4.7.1 定义
Use sharing to support large numbers of fine-grained objects efficiently.
使用共享对象可有效地支持大量的细颗粒度的对象。
4.7.2 应用场景
n 系统中有大量的相似对象，这些对象耗费大量的内存。
n 细颗粒度的对象都具备较接近的外部状态，而且内部状态与环境无关，即对象没有特定身份。
n 需要缓冲池的场景。
5 行为型模式
5.1 模板方法模式
5.2 命令模式
5.3 责任链模式
5.4 策略模式
5.5 迭代器模式
5.6 中介者模式
5.7 观察者模式
5.8 备忘率模式
5.9 访问者模式
5.10 状态模式
5.11 解释器模式本文出自 “夢工厂” 博客，请务必保留此出处http://limlee.blog.51cto.com/6717616/1193524