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 结构。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
此，我们对 Sale 对象附加的策略既可以是组合的 CompositeBestForCoustomerstrategy 对象，又可以是原子的 PercentDiscountPricingStrategy 对象。Sale 不关心其定价策略 是组合的还是原子的。
策略（strategy） 销售的定价策略有多样性，一段时期内对于所有的销售可能会有 10%的折扣，后
单实例类（Singleton） 工厂设计模式也称为简单工厂，经常描述为抽象工厂的变种。工厂设计模式引发
出另一个新的问题，即谁来创建工厂自身和如何访问工厂。 代码在不同的位置都需要访问适配器以调用外部服务，所以就需要代码在不同的
位置调用工厂中的方法。在这里就存在可见性的问题，即如何获得单个工厂实例的 可见性以及单点访问。
add(ISalePricingStrategy) getTotal(sale) : Money
getTotal(sale) : Money
CompositeBestForCous tomerstrategy
getTotal(sale) : Money
CompositeBestForSt oreStrategy
PercentDiscountPrici ngStrategy
percentage : float
getTotal(sale) : Money
AbsluteDiscountOverThresho
ldPricingStrategy
CompositePricingStrategy
discount : Money threshold : Money
GoF 几种设计模式举例及其应用
1090379131 易余
GOF 即 Gang of Four，就 Java 语言体系来说，GOF 的设计模式是 Java 基础知识 和 J2EE 框架知识之间一座隐性的"桥"。实际上，GoF 的设计模式并不是一种具体" 技术",它讲述的是思想，它不仅仅展示了接口或抽象类在实际案例中的灵活应用和 智慧，让你能够真正掌握接口或抽象类的应用，从而在原来的 Java 语言基础上跃进 一步，更重要的是，GoF 的设计模式反复向你强调一个宗旨：要让你的程序尽可能的 可重用。本文介绍几种常用的设计模式的举例和应用。
//static method public static synchronized ServicesFactory getInstance() { if(instance==null) instance=new ServicesFactory() return instance }
观察者模式（Observer） 观察者模式支持低耦合，它允许现有视图或者表示层使用新的窗口来代替特定的
解决方案为：定义观察者接口，观察者实现此接口。对象可以动态关注某事件的 观察者，并在事件发生时通知他们。下图描述了此类解决方案。
{ for each PropertyListener pl in Propert (this,name,value) }
GreatNorthernAccountingAdapter
postReceivable(CreditPayment) postSale(Sale)
如上图所示，对于选定的外部服务，将选用一个特定的适配器实例来表示。例如 针对账务系统的 SAP，当向外部接口发出 postSale 请求时，首先通过适配器进行转 换，使其能够通过 HTTP 上的 SOAP XML 接口来访问在 SAP 在局域网上提供的 Web Service。
AbsoluteDiscountOverThresh oldPricingStrategy
discount : Money threshold : Money
getTotal(sale) : Money
策略对象依附于语境对象，本例中，语境对象是 Sale。当 getTotal 消息发送给 Sale 时，它会把工作委派给它的策略对象。类型为 Sale 的 S 被传递给了策略，因此 策略对象在将来的协作中对其具有参数可见性。
*
<<Interface>>
propertyListener
{ total=newTotal publishPropertyEvent ("sale.total",total) }
setTitle() setVisible()
onPropertyEvent(source,name,value)
SaleFrame1
事件的通知。也就是说总额变化时，该窗口会得到通知。 Sale 并不知道 SaleFrame1 对象，它只知道实现了 PropertyListener 对象。这
样就降低了 Sale 和窗口的耦合。 Sale 实例就成为了特性事件的发布者，当总额发生变化时，它会遍历所有订阅
了的 PropertyListener，并且通知每一个订阅者。 SaleFrame1 就是观察者
由于公共类的可见性是全局的，因此代码的任何一点，在类的任何方法中，都可 以写为：
SingletonClass.getInstance() 例如 SingletonClass.getInstance().doFoo()，这种写法就是为了获得对于单 实例类的实例可见性，并且对其发送消息。 单实例类还存在另一个问题，为什么不将所有服务的方法都定义成类自己的静态 方法，而是使用有实例方法的实例对象？原因如下： 实例方法允许定义单实例类的子类以对其进行精化。静态的方法不是多态的，而 且大多数语言中不允许在子类中对其覆写。 大多数面向对象的远程通信机制只支持实例方法的远程使用而不支持静态方法。 类并非在所有的场景中都是单实例类。在一个应用中是单实例的，而在另一个实 例中却可能是多实例的，并且在开始设计的时候考虑使用单实例的不多见。因此使 用实例方法的解决方案有更大的灵活性。
TaxMasterAdapter
getTaxes(Sale) : List of TaxLineItem
<<Interface>>
IAccountingAdapter
postReceivable(CreditPayment) postSale(Sale)
SAPAccountingAdapter
postReceivable(CreditPayment) postSale(Sale)
sale
data
getTotal()
pri ci ngStrategy
<<Interface>>
IsalePricingStrategy
1 getTotal(sale) : Money
PercentDiscountPrici ngStrategy
percentage : float
getTotal(sale) : Money
组合（Composite） 商场有不同的定价策略，一般商店在解决冲突策略时会应用“对顾客最有利”的
策略来解决冲突。但有时在财政困难时期，商店也会采用最高价格的策略来解决冲 突。
因此商场存在多个策略，同样定价策略可以与所购买的产品类型相关，那么如何 能够像处理非组合对象一样，多态地处理一组对象或者具有组合结构的对象？
getInstance() : ServicesFactory getAccountingAdapter() : IAccountingAdapter getInventoryAdapter() : IInventoryAdapter getCalculatorAdapter() : ICalculatorAdapter
解决方案：对类定义静态方法返回单实例。其中的关键思想是，对类定义静态方 法 getInstance，该方法提供了类的唯一实例。例如：
public class Register {
public void Initialize { … do some work … AccountingAdapter=ServicesFactory.getInstance().getAccountingAdapter(); … do somework … } }
窗口，同时不会对非 UI 对象产生影响。例如，如果模型对象不知道 Java Swing 对 象，那么久可以拔掉 Swing 接口或者特定的窗口，然后插入其他的东西。
不同类型的观察者关注观察对象的状态变化或事件，并且在观察对象产生事件时 以自己独特的方式的做出反应。观察对象与观察者保持低耦合，就使用观察者设计 模式。
ServicesFactory
instance : ServicesFactory accountingAdapter : IAccountingAdapter inventoryAdapter : IInventoryAdapter calculatorAdapter : ICalculatorAdapter
这里提出的解决方案是：采用组合模式，定义组合和原子对象的类，使他们实现 相同的接口。如下图所示。
sale
data
getTotal()
pri ci ngStrategy
<<Interface>>
IsalePricingStrategy
1 getTotal(sale) : Money
1..*
strategies
{ PropertyListener.add(lis) }
Sale
addPropertyListener(PropertyListener lis) publishPropertyEvent(name,value) setTotal(Money newTotal)
javax.swing.JFrame
onPropertyEvent(source,name,value) initialize(Sale sale)