设计模式
2014-01-15 10:12
176 查看
1.创建型
Abstract Factory（抽象工厂模式）
_________________________________________________________
Builder（生成器模式）
_________________________________________________________
Factory Method（工厂模式）
_________________________________________________________
Prototype（原型模式）
_________________________________________________________
Singleton（单例模式）
意图:保证一个类仅有一个实例，并提供一个访问它的全局访问点。
适用环境:
当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。
当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。
_________________________________________________________
2.结构型
Adapter（适配器模式）
_________________________________________________________
Composite（组合模式）
_________________________________________________________
Bridge（桥接模式）
_________________________________________________________
Decorator（装饰模式）
意图:动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。
适用环境:
在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
处理那些可以撤消的职责。
当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。
_________________________________________________________
Facade（外观模式，门面模式）
意图:为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
适用环境:
当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。
客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
当你需要构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过Facade进行通讯，从而简化了它们之间的依赖关系。
_________________________________________________________
Flyweight（享元模式）
_________________________________________________________
Proxy（代理模式）
_________________________________________________________
3.行为型
Chain of Responsibility（职责链模式）
意图:使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
适用环境:
有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
可处理一个请求的对象集合应被动态指定。
使用举例: SWING中的Action/Event/Listener、Tomcat中的Pipeline接口
_________________________________________________________
Interpreter（解释器模式）
_________________________________________________________
Command（命令模式）
_________________________________________________________
Iteartor（迭代器模式）
_________________________________________________________
Mediator（中介者模式）
_________________________________________________________
Memento（备忘录模式）
_________________________________________________________
State（状态模式）
_________________________________________________________
Observer（观察者模式）
_________________________________________________________
Strategy（策略模式）
_________________________________________________________
TemplateMethod（模板方法模式）
_________________________________________________________
Visitor（访问者模式）
Abstract Factory（抽象工厂模式）
_________________________________________________________
Builder（生成器模式）
_________________________________________________________
Factory Method（工厂模式）
_________________________________________________________
Prototype（原型模式）
_________________________________________________________
Singleton（单例模式）
意图:保证一个类仅有一个实例，并提供一个访问它的全局访问点。
适用环境:
当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。
当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。
_________________________________________________________
2.结构型
Adapter（适配器模式）
_________________________________________________________
Composite（组合模式）
_________________________________________________________
Bridge（桥接模式）
_________________________________________________________
Decorator（装饰模式）
意图:动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。
适用环境:
在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
处理那些可以撤消的职责。
当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。
_________________________________________________________
Facade（外观模式，门面模式）
意图:为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
适用环境:
当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。
客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
当你需要构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过Facade进行通讯，从而简化了它们之间的依赖关系。
_________________________________________________________
Flyweight（享元模式）
_________________________________________________________
Proxy（代理模式）
_________________________________________________________
3.行为型
Chain of Responsibility（职责链模式）
意图:使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
适用环境:
有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
可处理一个请求的对象集合应被动态指定。
使用举例: SWING中的Action/Event/Listener、Tomcat中的Pipeline接口
_________________________________________________________
Interpreter（解释器模式）
_________________________________________________________
Command（命令模式）
_________________________________________________________
Iteartor（迭代器模式）
_________________________________________________________
Mediator（中介者模式）
_________________________________________________________
Memento（备忘录模式）
_________________________________________________________
State（状态模式）
_________________________________________________________
Observer（观察者模式）
_________________________________________________________
Strategy（策略模式）
_________________________________________________________
TemplateMethod（模板方法模式）
_________________________________________________________
Visitor（访问者模式）
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- php设计模式 Singleton(单例模式)
- 设计模式-策略模式
- 设计模式 --> 命令模式(C++实现)
- 设计模式（十八）—备忘录模式（行为型）
- GoF设计模式学习-单例模式
- 设计模式——组合模式
- 研磨设计模式之工厂方法模式-2——跟着cc学设计系列
- 【Java设计模式】(3)责任链Chain of Responsibility
- 设计模式之反转控制（IOC）
- 设计模式(10)-适配器Adapter
- 设计模式之访问者模式
- Net设计模式实例系列文章总结
- 智取设计模式之简单工厂模式
- 【设计模式系列】单例模式
- 设计模式--单例设计模式
- Observer设计模式与C#委托、事件
- 研磨设计模式之 命令模式-2
- 【初学设计模式】Object Adapter (对象适配器)
- 设计模式学习笔记：组合模式
- 设计模式学习之路——Builder