GOF几种设计模式举例及其应用

合集下载

UML-GoF设计模式

UML-GoF设计模式我认为，本章是重点中的重点。

并⾮23个模式都被⼴泛应⽤，其中常⽤和最为有效的⼤概有15个模式。

1、适配器（Adapter）1）、使⽤场景使⽤⼀个已经存在的类，但如果他的接⼝，也就是他的⽅法和你的要求不相同时，考虑使⽤是适配器模式。

就是说，双⽅都不修改⾃⼰的代码的时候，可以采⽤适配器模式。

2）、结构图3）、相关模式外观对象：隐藏外部系统的资源适配器也被视为外观对象，因为资源适配器使⽤单⼀对象封装了对⼦系统或系统的访问。

资源适配器：当包装对象时为不同外部接⼝提供适配时，该对象叫资源适配器4）、准则类名后缀为“Adapter”。

5）、⽤到的GRASP原则2、⼯⼚模式1）、使⽤场景该模式也常称为“简单⼯⼚”或“具体⼯⼚”。

如：1）、存在复杂创建逻辑2）、为提⾼内聚⽽分离创建者职责（关注点分离）因此，创建称为⼯⼚的纯虚构对象来处理这些创建职责。

2）、结构⼀般xxxFactory应该是单实例类。

3）、相关模式通常使⽤单例模式来访问⼯⼚模式。

由谁创建⼯⼚呢？⼀般采⽤单例模式。

3、单例模式1）、使⽤场景只有唯⼀实例的类即为“单实例类”。

对象需要全局可见性和单点访问。

因此，建议对类定义静态⽅法⽤以返回单实例。

2）、相关模式单例模式：通常⽤于创建⼯⼚对象和外观对象以上整合例⼦：4、策略模式1）、使⽤场景销售的定价策略（也可叫做规则、政策或算法）具有多样性。

在⼀段时间内，对于所有的销售可能会有10%的折扣，后期可能会对超出200元的销售给予10%的折扣，并且还会存在其他⼤量的变化。

因此，在单独的类中分别定义每种策略/规则/政策/算法，并且使其具有共同接⼝。

2 ）、结构策略模式，共同的⽅法内传⼊的参数，通常是上下⽂对象，上图就是sale。

3）、结合⼯⼚模式1）、使⽤⼯⼚模式创建这些策略类2）、使⽤单例模式创建⼯⼚类。

5、组合模式1）、使⽤场景如果有重叠怎么办？⽐如：1）⽼年⼈折扣20%2）购物⾦额满200元享受15%折扣因此，如何能够处理像原⼦对象⼀样，（多态的）处理⼀组对象或具有组合结构的对象呢？答：定义组合和原⼦对象的类，使他们具有相同的接⼝。

GOF_23种设计模式

创建型模式1、FACTORY2、BUILDER3、FACTORY METHOD4、PROTOTYPE5、SINGLETON结构型模式6、ADAPTER7、BRIDGE8、COMPOSITE9、DECORATOR10、FAÇADE11、FLYWEIGHT12、PROXY行为模式13、CHAIN OF RESPONSIBLEITY14、COMMAND15、INTERPRETER16、ITERATOR17、MEDIATOR18、MEMENTO19、OBSERVER20、STATE21、STRATEGY22、TEMPLATE METHOD23、VISITOR创建型模式1、FACTORY追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。

麦当劳和肯德基就是生产鸡翅的Factory工厂模式：客户类和工厂类分开。

消费者任何时候需要某种产品，只需向工厂请求即可。

消费者无须修改就可以接纳新产品。

缺点是当产品修改时，工厂类也要做相应的修改。

如：如何创建及如何向客户端提供。

2、BUILDERMM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。

（这一定比美军在伊拉克用的翻译机好卖）建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。

建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。

建造模式可以强制实行一种分步骤进行的建造过程。

3、FACTORY METHOD请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。

GOF模式说明

1.抽象工厂（Abstract Factory ）：Provide an interface for creating families of related or dependent objects, without specifying their concrete classes 在未指定具体类时，为建立相关的或依赖对象的族提供一个接口。

2．适配器(Adapter)：Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.将一个类的接口转换为另一个客户期待的接口。

以避免接口的不兼容。

3．桥(Bridge)：Decouple an abstraction from its implementation so that the two can vary independently把实现和抽象分离，于是两者可以独立变化。

4．责任链(Chain of Responsibility)：Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.通过给多个对象处理请求的机会，避免请求的发送者耦合其接受者。

链接接受对象沿着链传递请求，直到一对象去处理它。

5．命令(Command)：Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.作为一个对象来封装一个请求，因而可用不同的请求（队列或联机请求）来参数化客户并支持可撤销操作。

常用GoF设计模式--1

常⽤GoF设计模式--1常⽤GoF设计模式--1为了实现分离，⼀般需要从“纵向”、“横向”、“核⼼和外围”三个不同的⽅⾯进⾏仔细地地分析和考虑。

对于纵向进⾏分离，常⽤的处理⽅法是“分层策略”，或者某些框架技术。

对于同⼀层中各个组件类之间的横向关联关系的分离，常⽤的处理⽅法是使⽤“桥模式”。

对于核⼼功能模块和将要扩展的外围模块之间的分离，常⽤的处理⽅法是使⽤“装饰器模式”。

1. 基本概念1.1 GoF设计模式展⽰的设计原则GoF设计模式展⽰了如何处理各种变化，使代码获得最⼤的可重⽤性。

主要体现以下3种设计策略。

针对接⼝编程，⽽不是针对具体的实现类编程。

优先使⽤对象组合，⽽不是类的继承技术。

将系统中的“可变部分”和“不可变部分”分离，封装变化点。

1.2 GoF设计模式分为⼏⼤泛型1.2.1 创建型模式创建型模式涉及对象实例化时使⽤的各种模式，有以下⼏种：（1）⼯⼚⽅法（Factory Method）（2）抽象⼯⼚（Abstract Factory）（3）原型（Prototyoe）（4）⽣成器（Builder）（5）单例（Singleton）1.2.2 结构型模式结构型模型主要描述系统中的类和对象应该怎样结合以构成更⼤的结构，有以下⼏种：（1）门⾯（Facade）（2）代理（Proxy）（3）适配器（Adapter）（4）组合（Composite）（5）装饰（Decorator）（6）桥（Bridge）（7）享元（Flyweight）1.2.3 ⾏为型模式⾏为型模式主要⽤来封装变化，有以下⼏种：（1）模版（Template）（2）备忘录（Memento）（3）观察者（Observer）（6）命令（Command）（7）迭代器（Iterator）（8）中介（Mediator）（9）访问者（Visitor）（10）状态（State）（11）策略（Strategy）2. ⼏个常⽤模式2.1 单例模式Singleton类定义了⼀个getInstance()操作，允许客户端访问它的唯⼀实例。

跟我学GOF设计模式——访问控制与代理模式

（4）采用静态代理技术
（5）对上面的静态代理技术实现的说明达到了核心关注点和横切关注点相互分离的目的静态代理在程序規模稍大时就必定无法胜任 ---必要为每个类提供代理类的定义，静态代理在程序規模稍大（有多种不同形式的业务功能类）时就必定无“学而不思则罔，思而不学则殆。” “学而时习之”
5、虚拟（Virtual）代理（1）问题假设一个程序要使用Email服务，但是并不是什么时候都要连接 Email服务器或接入Email服务器，因为频繁地接入 Email服务器是非常耗时和耗资源。
6、在Struts2框架中应用代理模式（1）核心控制器 FilterDispatcher和用户的Action类之间通过 ActionProxy组件相互隔离。（2）工作原理图
（3）如何实现访问代理模式建议不要使有特殊需求的客户对象直接访问目标对象，而是使用一个单独的对象（代理对象）为不同的客户提供通常的、直接的访问目标对象的方式。
2、代理模式的主要类型——不同的应用场景有不同类型（1）远程（Remote）代理远程代理又叫做大使（Ambassador），提高网络调用或大数据读写时的效率，也能够隐藏网络通讯的细节。（2）虚拟（Virtual）代理它作为创建开销大的对象的代表，当真正需要创建一个对象时才创建它当对象在创建前和创建中时，虚拟代理来扮演对象的替身，对象创建后，代理会将请求直接委托给对象。比如媒体播放、Email一起发送等应用中。
（1）UML中的类图（2）代理模式中的三个主要的角色抽象主题角色代理主题角色真实主题角色
（3）与适配器模式不同点适配器模式是要改变所“代理”的对象接口；而代理模式并不改变所代理的对象的接口。（4）代理对象提供和目标对象一样的接口代理对象负责与目标对象交互的细节，代表客户对象与目标对象交互。客户对象不需处理访问目标对象服务时的特殊需求。

跟我学GOF设计模式——门面模式及应用

2、子曰：“知之者不如好之者,好之者不如乐之者”
3、子曰：“三人行,必有我师焉”
4、子曰：“我非生而知之者,好古,敏以求之者也”
5、师者：“传道、授业和解惑”
这样便产生出一种不便，它使得系统的逻辑变得不必要的复杂，维护成本提高，复用率降低。
2、用一个范例来说明门面设计模式 ----医院中的正常的业务流程 3、如何解决这种不便----引进 Facade模式
接待员（导医小姐）就是Facade模式的体现--Faç ade组件的应用
4、Facade模式的设计要求要求一个子系统的外部与其内部的通讯必须通过一个统一的门面（Facade）对象进行
8、Facade模式的实现代码示例外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。
本讲的简要回顾
1、子曰：“学而不思则罔，思而不学则殆。” “学而时习之”
（3）出现的背景---基于非EJB组件的系统（门面）在应用系统中客户需要与子系统内部的许多对象打交道设计师处理复杂系统的一个常见方法便是将其“分而治之”，把一个系统划分为几个较小的子系统。而一般一个子系统的使用端往往只关注一些特定的功能，但却要同时与子系统内部的许多对象打交道后才能达到目的
Facade模式和适配器模式也都是用来变换接口，但它们在应用的目的和场合不同----“简化”和“适应”，“开发”和“维
7、利用Facade模式为Web应用系统提供DAO服务层组件
由于希望能够达到彻底地隔离业务处理层和系统的持久层之间的关系，从而使得业务逻辑组件有更好地重用性。在业务处理层和系统的持久层之间添加了一个数据访问服务层，并提供数据访问服务（DAO服务）组件。

gof 23 种设计模式解析附 c语言

gof 23 种设计模式解析附 c语言在计算机科学中，设计模式（Design Patterns）是一套被反复使用的，多数人知道的，经过分类编目的，代码设计经验的总结。

使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

GoF 23种设计模式是设计模式中最经典和最常用的部分，这些模式主要用于解决特定类型的问题。

下面是这些设计模式的C语言解析：1. 工厂方法模式（Factory Method Pattern）```c#include <stdio.h>// 抽象产品类struct AbstractProduct {void use() {printf("AbstractProduct\n");}};// 具体产品类1struct ConcreteProduct1 : public AbstractProduct { void use() {printf("ConcreteProduct1\n");}};// 具体产品类2struct ConcreteProduct2 : public AbstractProduct { void use() {printf("ConcreteProduct2\n");}};// 抽象工厂类struct AbstractFactory {virtual AbstractProduct* createProduct() = 0; };// 具体工厂类1struct ConcreteFactory1 : public AbstractFactory {AbstractProduct* createProduct() {return new ConcreteProduct1;}};// 具体工厂类2struct ConcreteFactory2 : public AbstractFactory {AbstractProduct* createProduct() {return new ConcreteProduct2;}};int main() {ConcreteFactory1 factory1;ConcreteProduct1* product1 = factory1.createProduct(); product1->use(); // 输出 "ConcreteProduct1"delete product1; // 释放内存factory1.createProduct(); // 空指针异常，因为工厂已不再生产任何产品return 0;}```。

跟我学GOF程序代码编程中的各种设计模式——状态设计模式

杨教授大学堂精心创作的优秀程序员职业提升必读系列资料
1.1 跟我学 GOF 程序代码编程中的各种设计模式——状态设计模式
1.1.1 状态（State）设计模式
1、State 设计模式不同的状态对应着不同的行为，或者说每个状态有着相应的行为。
2、何时使用 State 设计模式 State 模式在实际使用中比较多，适合“状态的切换”。因为我们经常会使用 If elseif else
return false; } @Override public boolean doTransferAccount(String sAccountID, String tAccountID, float money) {
return false; } @Override public boolean doWithdrawFromAccount(String accountID, float money) {
State 模式的目标就是简化这类应用的代码，把依赖于状态的逻辑集中到一组类，每一个类代表一种不同的状态，从而避免 if 语句嵌套过深或过于复杂，转而依赖于多态性来调用不同的方法。
因为，如果对象的状态信息很关键，对象会拥有一些变量来指示如何根据状态做出相应的动作。这些变量大量地散布于复杂的多层嵌套 if 语句中，来描述对象如何响应可能出现的事件。用这种方式建立对象模型的最大缺点在于 if 语句可能变得相当复杂一旦要修改对象的状态模型，往往有多个方法的许多 if 语句需要调整。 4、是否必须使用 State 模式的应用场合
在实际应用中，类似开关一样的状态切换是很多的，但有时并不是那么明显，取决于你的经验和对系统的理解深度。
这里要阐述的是“开关切换状态”和“一般的状态判断”是有一些区别的，“一般的状态判断”也是有 if---elseif 结构。

.netgof23种设计模式

.netgof23种设计模式⼀、设计模式的分类GOF⼀共总结了23套设计模式，⼤致可以分为以下三类：创造型模式这些设计模式提供了⼀种在创建对象的同时隐藏创建逻辑的⽅式，⽽不是使⽤ new 运算符直接实例化对象。

这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活，该类型包括：单件模式、抽象⼯⼚、建造者模式、⼯⼚⽅法模式和原型模式等5种。

结构型模式这些设计模式关注类和对象的组合。

继承的概念被⽤来组合接⼝和定义组合对象获得新功能的⽅式，该类型包括：适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式等7种。

⾏为型模式这些设计模式特别关注对象之间的通信。

分为职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板⽅法、访问者模式等11种。

⼆、设计模式解析常⽤设计模式浅析：1、单件模式结构图：意图：保证⼀个类仅有⼀个实例，并提供⼀个访问它的全局访问点。

适⽤性：当类只能有⼀个实例⽽且客户可以从⼀个众所周知的访问点访问它时。

当这个唯⼀实例应该是通过⼦类化可扩展的，并且客户应该⽆需更改代码就能使⽤⼀个扩展的实例时。

⽰意性代码：1//单件模式⽰意性代码2public class Singleton3 {4//创建私有对象，保证只有⼀个对象5private static Singleton _instance;67//保护类型的构造函数，⼦类化可扩展8protected Singleton() { }910//提供公共访问点11public static Singleton Instance()12 {1314// 使⽤ 'Lazy initialization'，为对象实例化15if (_instance == null)16 {17 _instance = new Singleton();18 }1920return _instance;21 }22 }Singleton特点总结：实例对外唯⼀、⼦类可以扩展并且提供⼀个公共的访问点访问。

设计模式系列之一：23种GoF设计模式概述

设计模式系列之一：23种GoF设计模式概述23种GoF设计模式概述在前面，我们对 GoF 的 23 种设计模式进行了分类，这里先对各个设计模式的功能进行简要介绍，以便有个大概了解。

后面的章节再进行详细介绍。

创建型模式关注于怎么创建对象的创建型模式，他们将对象的创建与使用相互分离，对象的使用者无需关心如何创建对象，只知道怎么使用就行，以降低耦合度。

犹如汽车使用人无需关注汽车是怎么造出来一样，只要知道怎么使用就行。

下面这5种模式就是属于这一类。

•单例（Singleton）模式：控制某个类只能自行生成一个可供外部全局访问的实例。

例如：Windows的窗口管理器或者任务管理器都是只有一个实例。

•原型（Prototype）模式：将一个创建成本高（如：装载大文件、初始化耗时长、CPU资源占用多等）的对象作为原型，通过对其进行复制或者克隆，来创建其他类似的新实例。

•抽象工厂（Abstract Factory）模式：由继承自抽象工厂类的具体工厂分别来创建有相同联系的多个不同产品。

例如不同的培训学校，可以创建课程和课程所用的教材。

•建造者（Builder）模式：针对一个复杂对象，它的构建需要很多步骤和部件，将这种对象拆解成多个相对简单的构成部件或者步骤，然后再根据需要分别构建他们，直到得到该复杂对象。

例如：快餐店的套餐，他的构造分别由汉堡、饮料、薯条构成，这就要求建造或制作者分别创建各种物品，然后返回一个完整的套餐给点餐人员。

•工厂方法（Factory Method）模式：由继承自抽象工厂类的具体工厂来决定生成什么具体产品。

例如都属于家具厂的沙发工厂、桌椅工厂和床厂分别生产沙发、桌椅和床这些家具。

结构型模式这种模式关注如何将对象和类按照某种方式一起来构成新的、更大、更有效果的低耦合结构，这种组成方式用于类结构的继承、和用于对象结构的组合或聚合。

具有组合或聚合关系的各对象之间要比继承关系的各对象之间的耦合度弱，这样对象结构要比类对象具有更低的耦合度。

跟我学GOF程序代码编程中的各种设计模式——构建者设计模式

杨教授大学堂，版权所有，盗版必究。
3/3 页
1/3 页
杨教授大学堂，版权所有，盗版必究。
杨教授大学堂精心创作的优秀程序员职业提升必读系列资料
//返回最后组装成品结果(返回最后装配好的汽车)，但成品的组装过程不在这里进行,而是转移到下面的 Director 类中进行。从而实现了解耦过程和部件 Product getResult(); } （2）其次，用 Director 构建最后的复杂对象,而在上面 Builder 接口中封装的是如何创建一个个部件(复杂对象是由这些部件组成的),也就是说 Director 的内容是如何将部件最后组装成成品。 public class Director{ private Builder builder; public Director( Builder builder ){ this.builder = builder; } // 将部件 partA、partB 和 partC 最后组成复杂对象。这里是将车轮方向盘和发动机组装成汽车的过程 public void construct(){ builder.buildPartA(); builder.buildPartB(); builder.buildPartC(); } } （3）设计 Builder 的具体实现 ConcreteBuilder: 通过具体完成接口 Builder 来构建或装配产品的部件;定义并明确它所要创建的是什么具体东西;提供一个可以重新获取产品的接口。 public class ConcreteBuilder implements Builder{ Part partA, partB, partC; public void buildPartA() { //这里是具体如何构建 partA 的代码 } public void buildPartB() { //这里是具体如何构建 partB 的代码

跟我学GOF程序代码编程中的各种设计模式——原型设计模式

杨教授大学堂，版权所有，盗版必究。 2/3 页
杨教授大学堂精心创作的优秀程序员职业提升必读系列资料
} public static void main(String[] args) { PrototypeTest prototypetest = new PrototypeTest(); } } （4）执行后的结果
杨教授大精心创作的优秀程序员职业提升必读系列资料
} return oneObject; } public void addOneMail(String oneMailAddress){ this.mailList.add(oneMailAddress); } public ArrayList<String> getAllMail(){ return this.mailList; } } （2）子类 package com.px1987.prototype; public class Chinese extends Person { public Chinese() { } public void doPrintInfo() { System.out.println(getAllMail()); } } （3）测试类 package com.px1987.prototype; public class PrototypeTest { public PrototypeTest() { Chinese zhang=new Chinese(); zhang.addOneMail("trainict@"); zhang.doPrintInfo(); Chinese wang=(Chinese)zhang.clonePerson(); wang.addOneMail("webmaster@"); wang.doPrintInfo(); zhang.doPrintInfo();

J2EE项目实训UML及设计模式——第10章典型GOF设计模式及应用(第6部分)

由于适配器模式中的适配器组件提供了一种隔离和转换的接口，使得软件开发人员可以重用一个接口不符合现在的需求的类；当然，利用适配器模式也还可以达到某个类（该类在适配器模式中被称为适配者 Adaptee）在发生不可预见的变化时，仅仅影响适配器组件而不影响到客户端的访问者类——此时的适配器类，其实是一种组合转换器的角色。
在进行系统集成的时候，软件系统的开发者遇到的最常见问题是接口不匹配。从而导致很多能满足功能的软件模块，但由于各自的接口不同，而导致无法集成在一起使用—— 这在对以前的遗留代码的重用、类库的迁移等形式的开发工作中经常会遇到！
而此时如果应用“适配”这样的一种转换功能，就可以实现在不想改变原有类的功能的具体实现细节，但又希望能够将该类应用在另外的新场合中——因为绝大多数的软件系统中的各个功能模块在设计时是针对某个特定使用场合和功能需要的，它向这个特定的应用场景公开一些服务的接口以便使其客户可以使用它。但一旦其使用的场合或者环境发生了变化，其对外公开的接口可能就不再符合新的客户的需求了！
1.1.1 GoF 设计模式中的适配器模式
1、什么是适配器模式
GOF 设计模式对适配器模式的基本定义为：将一个类的接口转换为客户希望的另一个接口。Adapter 使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
适配器模式又称为变压器模式，因为它的作用很象变压器（Adapter）——因为变压器可以把一种电压变换成另一种电压，从而满足目标设备的应用要求。而应用适配器模式，同样也能够实现将一种接口转换为另一种目标接口，而满足目标组件类的需要。
正是由于适配器模式中的适配器类的作用类似于变压器的作用，而将该模式命名为适配器模式。适配器模式在 GOF 设计模式的分类中属于结构型模式。

跟我学GOF程序代码编程中的各种设计模式——模板方法模式

如果仅仅因为细节上的不同而要重写整个 SQL 语句的构件过程显然是不划算的，那么采用什么方法可以复用构件过程呢？我们可以采用模板方法。 2、模板方法模式的基本思路定义一个操作中的算法骨架，而将一些步骤延伸到子类中去，使得子类可以不改变一个算法的结构，即可重新定义该算法的某些特定步骤。这里需要复用的使算法的结构，也就是步骤，而步骤的实现可以在子类中完成。使用 Java 的抽象类时，就经常会使用到 Template 模式。因此 Template 模式使用很普遍，而且很容易理解和使用。模板设计模式一般是一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑；不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。 3、模板方法模式是实现 OCP 的常用方法使用 Template Method 模式是满足 OCP （The Open-Closed Principle 开放－封闭原则）的最常用方法。OCP 原则的基本思想是软件实体（类，模块，函数等等）应该是可以扩展的，
杨教授大学堂，版权所有，盗版必究。 1/2 页
杨教授大学堂精心创作的优秀程序员职业提升必读系列资料
但是不可修改的。即对于扩展是开放的，模块的行为可以扩展，又要“对于更改是封闭的” ，不允许修改原有的代码。实现 OCP，就应该采用面向接口编程，而不是面向对象编程。 4、模板方法模式的实现实例在抽象类中定义模板方法的关键是：在一个非抽象方法中调用调用抽象方法，而这些抽象方法在子类中具体实现。 public abstract class Benchmark{ public abstract void benchmark(); //希望在子类中完成的功能 public final void repeat (int count) { //自己已经实现的功能 benchmark(); } } public class MethodBenchmark extends Benchmark { public void benchmark() { //实现真正的功能的子类 } } Benchmark baseClass=new MethodBenchmark(); baseClass .repeat(10); 至于这样做的好处，很显然啊，扩展性强。以后 Benchmark 内容变化。我们只要再做一个继承子类就可以，不必修改其他应用代码。 5、模板方法模式的使用场合（1）一次性实现一个算法的不变部分，并且将可变的行为留给子类来完成。（2）各子类公共的行为应该被提取出来并集中到一个公共父类中以避免代码的重复。首先识别现有代码的不同之处，并且把不同部分分离为新的操作，最后，用一个调用这些新的操作的模板方法来替换这些不同的代码。（3）控制子类的扩展。 //另一个子类 //使用其它由子类实现的功能 //该方法为 Template 方法

跟我学GOF程序代码编程中的各种设计模式——装饰(Decorator)模式

1.1跟我学GOF程序代码编程中的各种设计模式——装饰（Decorator）模式1.1.1装饰模式1、装饰模式概述（1）装饰模式是一种处理问题的方式需要说明的是，装饰模式是一种处理问题的方式，装饰模式不等于界面设计，这两个概念不要搞混了。

装饰这个概念好像一个油漆工，在原有的家具上刷上色（增加功能），而原有的家具可能是原来已经就有的旧家具，使用装饰模式就有可能增加它的生命周期。

（2）Decorator定义动态给一个对象添加一些额外的职责，就象在墙上刷油漆。

使用Decorator模式相比用生成子类方式达到功能的扩充显得更为灵活。

Decorator模式可以解决这个问题。

Decorator字面的意思是装饰的意思，在原有的基础上，每添加一个装饰，就可以增加一种功能。

2、意图----为什么使用Decorator模式?（1）常规的实现方式----使用继承来实现功能的拓展我们通常可以使用继承的方式来实现功能的拓展，如果这些需要拓展的功能的种类很繁多，那么势必会生成很多子类，从而增加系统的复杂性；同时使用继承实现功能的拓展，那我们必须可预见这些拓展功能------因此，这些功能是编译时就确定了，当然也就是静态的。

（2）使用Decorator模式使用Decorator的理由是这些功能需要由用户动态决定加入的方式和时机，因此Decorator模式提供了一种“即插即用”的方法，在运行期间决定何时增加何种功能。

事实上，上面所要解决的意图可以归结为“在不改变对象的前提下，动态增加它的功能”，也就是说，我们不希望改变原有的类，或者采用创建子类的方式来增加功能，在这种情况下，可以采用装饰模式。

3、Decorator模式的程序结构装饰器结构的一个重要的特点是，它继承于一个抽象类，但它又使用这个抽象类的聚合（即装饰类对象可以包含抽象类对象）。

Decorator确实能够很好的缓解当功能组合过多时子类继承所能够带来的问题。

但是在得到很大的灵活性的同时，Decorator在使用时也表现得较为复杂。

第26章-应用GoF设计模式

协作中的策略
语境对象策略对象
取得折扣前总金额
当消息getTotal发给发给Sale时,它就委派一些工作给它的策略对象, 当消息发给时它就委派一些工作给它的策略对象, 通常, 语境对象将自己传给策略对象, 通常, 语境对象将自己传给策略对象,以便策略对象对语境对象有一个可见性(可以协作完成委派的工作) 见性(可以协作完成委派的工作).
UML表示法:这里的"1"是可选的,用于表示只有一个实例能够被创建(单实例类)
1 ServicesFactory
UML表示法:在类框图中,带有下划线的属性或方法表示(类级别)静态成员而不是实例成员
instance : ServicesFactory accountingAdapter : IAccountingAdapter inventoryAdapter : IInventoryAdapter taxCalculatorAdapter : ITaxCalculatorAdapter getInstance() : ServicesFactory getAccountingAdapter() : IAccountingAdapter getInventoryAdapter() : IInventoryAdapter getTaxCalculatorAdapter() : ITaxCalculatorAdapter ...
工厂模式示例
图26-5 工厂模式
工厂模式(Factory)引发的新的设计问题
ServicesFactory 引起了一个新的设计问题: 谁来创建Factory本身呢?如何调用它呢?
应注意到在处理过程中只需要ServicesFactory的一个实例. 编码中,ServicesFactory的方法需要在许多地方被调用(由于ServicesFactory创建相应的Adapter, Adapter 调用外部服务系统)

盘点GoF的23种设计模式

盘点GoF的23种设计模式前⾔设计模式最初并⾮出于软件设计中，⽽是⽤于建筑领域的设计中。

1995年，四位作者将建筑设计的基本模式融合到软件开发中，合作出版了《设计模式：可复⽤的⾯向对象软件的基础》，⼀共收录了23个设计模式，这是设计模式领域⾥程碑的事件，导致了软件设计模式的突破。

所以这四位作者在软件开发领域耦以四⼈帮（Gang Of Four）匿名著称，简称GoF。

⼀、设计模式的分类设计模式按照⽬的来划分的话可以划分为三种类型，分别为创建型模式、结构型模式和⾏为型模式1.1、创建型模式⽤于描述“怎样创建对象”，主要特点是将对象的创建和使⽤进⾏分离。

对象使⽤者不需要关⼼对象的创建细节，可以降低创建对象和使⽤对象之间的耦合度。

主要有单例模式、原型模式、⼯⼚⽅法模式、抽象⼯⼚模式和建造者模式等五种设计模式1.2、结构型模式⽤于描述如何将类或对象按某种布局组成更⼤的结构主要有代理模式、适配器模式、桥接模式、装饰器模式、外观模式、享元模式和组合模式等七种设计模式1.3、⾏为型模式⽤于描述类或对象之间怎样协作共同完成单个对象都⽆法单独完成的任务以及如何分配各个对象的职责分配主要有模版⽅法模式、策略模式、命令模式、责任链模式、状态模式、观察者模式、中介者模式、迭代器模式、访问者模式、备忘录模式和解释器模式等⼗⼀中设计模式⼆、创建型设计模式2.1、单例模式（Singleton）定义：某个类只能⽣成⼀个实例，该类需要提供⼀个全局访问点供外部获取该类的全局唯⼀实例单例模式的类需要满⾜以下三个要求：1.单例类只有⼀个实例对象2.单例对象必须由单例类⾃⾏创建3.单例类需要对外提供⼀个获取单例对象的全局访问点优缺点：1、保证内存中仅有⼀个实例，减少内存开销2、不易扩展，需求发⽣改变需要修改单例类，会违背开闭原则应⽤场景：1、需要频繁创建和销毁某个类的实例时;2、某个类的实例具有唯⼀性时3、类的创建实例的过程⾮常消耗资源时4、对象需要被全局共享时可参考⽂章：2.2、原型模式（Prototype）定义：将⼀个对象作为原型，通过对其复制从⽽克隆出多个和原型类似的新的实例优缺点：1、采⽤clone的⽅式⽐new⼀个对象性能更好，因为是直接基于内存⼆进制流的复制2、深克隆时需要每⼀层的对象都需要实现cloneable接⼝原型模式在Java中的实现依赖于cloneable接⼝，原型实现cloneable接⼝，需要根据原型创建新对象时，直接调⽤原型对象的clone⽅法进⾏复制即可应⽤场景：1、对象之间相同或相似时，⽆需通过new创建2、创建对象成本⼤，⽐如⽐较消耗CPU或⽹络资源等3、系统中⼤量使⽤该类对象，且各个调⽤者都需要给它的属性重写赋值时，⽐如状态等属性案例如下：业务场景⽃地主游戏有3⼈⽃地主和4⼈⽃地主，每种模式还分为新⼿房和⾼⼿房，此时可以抽象出游戏房间的类，并初始化各种类型的房间原型，每当有玩家进⼊对应模式的房间时就通过原型直接复制出⼀个房间即可。

设计模式精解-GOF23种设计模式解析(VS2012重写实现包含Linux Makefile) 代码和原文档已插入本文档

设计模式笔记（C++）一、创建型Factory：工厂1、定义创建对象的接口，封装了对象的创建2、使得具体化类的工作延迟到了子类中3、Factory模式正如我在相应的文档中分析的是为一类对象提供创建接口或者延迟对象的创建到子类中实现。

AbstractFactory：抽象工厂1、创建一组相关或者相互依赖的对象2、AbstractFactory模式是为创建一组（有多类）相关或者依赖的对象提供创建接口3、AbstractFactory模式通常都是使用Factory模式实现（ConcreateFactroy）Singleton：单例1、Singleton模式保证一个类仅有一个对象，并提供一个访问它的全局访问点。

2、全局变量不能防止实例化多个对象。

3、全局变量将使得对象在无论是否用到都要被创建。

Builder：创建者1、Builder模式的意图是非常容易理解、间接的：将一个复杂对象的构建与它的表示分离，使用同样的构建过程可以创建不同的表示（在示例代码中可以通过传入不同的参数实现这一点）。

Builder模式和AbstractFactory模式在功能上很相似，因为都是创建大的复杂的对象，它们的区别是：Builder模式强调的是一步步创建对象，并通过相同的创建过程可以获得不同的结果对象，一般来说Builder模式中对象不是直接返回的。

而在AbstractFactory 模式中对象是直接返回的，AbstractFactory模式强调的是为创建多个相互依赖的对象提供一个同一的接口。

Prototype：原型1、Prototype模式通过复制原型（Prototype）而获得新对象创建的功能，这里Prototype本身就是“对象工厂”（因为能够生产对象），实际上Prototype 模式和Builder模式、AbstractFactory模式都是通过一个类（对象实例）来专门负责对象的创建工作（工厂对象），它们之间的区别是：Builder模式重在复杂对象的一步步创建（并不直接返回对象），AbstractFactory模式重在产生多个相互依赖的对象，而Prototype模式重在从自身复制自己创建新类。

GOF23种设计模式详解-tony

} public interface Driver{ Car driveCar();
第 5 / 89 页

1.1 设计模式之略见一斑(工厂模式Factory)
} public class QQDriver implements Driver{ public Car driveCar() { return new QQCar(); } } public class BaoMaDriver implements Driver{ public Car driveCar() { return new BaoMaCar(); } } public class BenChiDriver implements Driver{ public Car driveCar() { return new BenChiCar(); } }
- 做最棒的软件开发交流社区
21种设计模式详解
作者: 行者买刀
行者买刀的博客文章精选如有疑问或建议请站内短信联系
第 1 / 89 页
本书由JavaEye提供的电子书DIY功能自动生成于 2010-02-26
1.2 设计模式之略见一斑(单例模式singleton)
发表时间: 2010-02-01 单例模式是属于比较常用的一例，一个类（class）在内存中只有一个实例。常用方式如下: 第一种（饿汉式）：
public class Singleton {

1.1 设计模式之略见一斑(工厂模式Factory)
如此基础上对新式的各种各样的车进行区别，从而当新增一款车型时或者新增一类车型时就对应加入相应的类和方法
第(单例模式singleton)

目录
1. J2SE
1.1 设计模式之略见一斑(工厂模式Factory) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 设计模式之略见一斑(单例模式singleton) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3 设计模式之略见一斑(建造模式builder) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.4 设计模式之略见一斑(原型模式Prototype) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.5 设计模式之略见一斑(适配器模式Adapter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.6 设计模式之略见一斑(桥梁模式bridge) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.7 设计模式之略见一斑(外观模式Facade) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.8 设计模式之略见一斑(组合模式Composite) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.9 设计模式之略见一斑(装饰模式decorator) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.10 设计模式之略见一斑(代理模式Proxy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 1.11 设计模式之略见一斑(享元模式flyweight) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 1.12 设计模式之略见一斑(命令模式Command) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 1.13 设计模式之略见一斑(解释器模式Interpreter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 1.14 设计模式之略见一斑(状态模式State) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 1.15 设计模式之略见一斑(策略模式strategy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 1.16 设计模式之略见一斑(Template Method模板方法模式) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 1.17 设计模式之略见一斑(Memento备忘录模式) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 1.18 设计模式之略见一斑(Observer观察者模式) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 1.19 设计模式之略见一斑(Chain of Responsibility责任链模式) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77