![](https://img-blog.csdnimg.cn/20201014180756757.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
设计模式
文章平均质量分 69
zhao_hui_xi
这个作者很懒,什么都没留下…
展开
-
设计模式笔记(12 STRATEGY & TEMPLATE METHOD)
STRATEGY(策略)适用性:1.许多相关的类仅仅是行为有异。”策略“提供了一种用多个行为中的一个行为来配置一个类册方法。2.需要使用一个算法的不同变体。3.算法使用客户不应该知道的数据。可使用策略避免暴露复杂的、于算法有关的数据结构。4.一个类定义了多种行为,并且这些行为在这个类的操作中以多个条件语句的行署出现。将相关的条件分支移入他们各自的strategy类中以代替这些条件语句。思考:转载 2006-04-14 15:03:00 · 599 阅读 · 0 评论 -
设计模式笔记(4 ADAPTER & BRIDGE)
ADAPTER(适配器)适用性:想使用一个已经存在的类,而它的接口不符合要求。想创建一个可以复用的类,该类可以与其他不相关的类或者不可预见的类协同工作。结构:适配器使用多重继承对一个接口和另一个接口适配。(这和proxy模式可以比较一下)多重继承的更好说法也许是组合。具体如何实现要看适配器的实现复杂程度。思考:被适配的类可能是多样的,但是应该完成相同的功能,适配器类只是用来匹配接口,并不是用来大规转载 2006-04-14 15:11:00 · 624 阅读 · 0 评论 -
设计模式笔记(6 FACADE)
FACADE(外观)适用性:1.需要为一个复杂子系统提供一个简单接口时,为子系统提供一个简单的外观。2.客户程序与抽象类的实现之间存在很大的依赖性3.当需要构建一个层次结构的子系统时,使用FACADE来定义子系统中每层的入口点。思考: 关于第一点,好处是明显的,它降低了客户的学习成本。但是,一般而言,如果这个子系统是一个定制的子系统,可能直接提供一个简单接口更省事。如果这个子系统来是已经实现转载 2006-04-14 15:10:00 · 571 阅读 · 0 评论 -
设计模式笔记(10 MEDIATOR & MEMENTO)
MEDIATOR(中介者)适用性:1.一组对象以定义良好但是复杂的方式进行通信,产生相互依赖关系混乱且难以理解。2.一个对象引用很多其他对象并且直接与这些对象通信,导致难以复用该对象。3.想定制分布在多个类中的行为,而又不想生成太多的子类思考: MEDIATOR模式虽然是协调对象的,但是对对象的组织方式也会带来重大影响。对于一组相互作用的对象,这种相互关系是网状的,搞清楚这组对象之间的联系是转载 2006-04-14 15:06:00 · 557 阅读 · 0 评论 -
设计模式笔记(2 FACTORY METHOD)
FACTORY METHOD(工厂方法)理解:一个类需要创建某个类的实例,但是,又不知道(或者不该知道)如何创建实例时,需要工厂方法.例如一个TEMPLETE METHOD中,创建各种新实例(比如,各种文档),那么需要提供一个单一的创建接口,而将创建的实现分离出去,这种分离的创建行为,就是工厂模式.很显然,所有的创建行为,都必须提供共同的接口,创建的产品,也必须具有共同接口.这一点和抽象类厂是不一转载 2006-04-14 15:13:00 · 552 阅读 · 0 评论 -
设计模式笔记(2 FACTORY METHOD)
FACTORY METHOD(工厂方法)理解:一个类需要创建某个类的实例,但是,又不知道(或者不该知道)如何创建实例时,需要工厂方法.例如一个TEMPLETE METHOD中,创建各种新实例(比如,各种文档),那么需要提供一个单一的创建接口,而将创建的实现分离出去,这种分离的创建行为,就是工厂模式.很显然,所有的创建行为,都必须提供共同的接口,创建的产品,也必须具有共同接口.这一点和抽象类厂是不一转载 2006-04-14 15:13:00 · 554 阅读 · 0 评论 -
设计模式笔记(2 FACTORY METHOD)
FACTORY METHOD(工厂方法)理解:一个类需要创建某个类的实例,但是,又不知道(或者不该知道)如何创建实例时,需要工厂方法.例如一个TEMPLETE METHOD中,创建各种新实例(比如,各种文档),那么需要提供一个单一的创建接口,而将创建的实现分离出去,这种分离的创建行为,就是工厂模式.很显然,所有的创建行为,都必须提供共同的接口,创建的产品,也必须具有共同接口.这一点和抽象类厂是不一转载 2006-04-14 15:13:00 · 496 阅读 · 0 评论 -
设计模式笔记(3 PROTOTYPE & SINGLETON)
PROTOTYPE(原型)适用性:当一个系统应该独立于他的产品创建,构成和表示时,要使用该模式.思考:对比FACTORY METHOD,工厂方法需要统一的Creator,而Creator的提供和被创建对象之间是各自独立的.也就是说,必须为具体的产品类提供相应的Creator(当然,C++的模版技术可以简化一些工作).从语意上来看,工厂方法是凭空创建一个对象,而原型是从已知实例复制新的拷贝.效果上,转载 2006-04-14 15:12:00 · 590 阅读 · 0 评论 -
设计模式笔记(5 COMPOSITE & DECORATOR)
COMPOSITE(组合)适用性:1.想表示对象的部分整体层次结构2.希望用户忽略组合对象和单个对象的不同。思考:组合模式的所有组件应该具备同一个接口。一直感觉,这种组合是一种递归组合的概念。所有的组件,按照树的结构组织起来,树的叶结点行为可能和中间结点的行为并不一致,这看上去违背了Liskov原则,似乎是一个容易引起迷惑的地方。树的叶结点可能并不能增加子结点,删除子结点的行为也可能失败。而一个中转载 2006-04-14 15:11:00 · 553 阅读 · 0 评论 -
设计模式笔记(7 FLYWEIGHT & PROXY)
FLYWEIGHT(享元)意图:运用共享技术有效地支持大量细粒度的对象。适用性:1.一个程序应用了大量的对象,造成很大的存储开销。2.对象的大多数状态可变为外部状态。3.如果删除对象的外部状态,那么可以用相对较少的公象对象取代很多组对象。4.应用程序不依赖于对象标识思考: 上述的适用性和别的模式中介绍的不太一样。基本上,适合使用FlyWeight模式的场景需要同时满足上述四个条件,而别的模式转载 2006-04-14 15:09:00 · 628 阅读 · 0 评论 -
设计模式笔记(8 CHAIN OF RESPONSIBILITY & COMMAND)
CHAIN OF RESPONSIBILITY(职责链)适用性:1.有多个对象可以处理统一请求,但是,那个对象处理要到运行时刻决定。2.希望在不明确接收者的情况下,向多个对象中的一个提交一个请求。3.可处理一个请求的对象集合应该被动态指定。思考:既然要向未知的接收者提交请求,那么就需要统一的提交界面,也就是说,所有接收者应该实现一个公共接口,来接收请求,当然Delegate可以改变这一状况。一个典转载 2006-04-14 15:08:00 · 569 阅读 · 0 评论 -
设计模式笔记(9 INTERPRETER & ITERATOR)
INTERPRETER(解释器)适用性:当有一个语言需要解释执行,并且你可以将语言中的句子表示为一个抽象语法树时,可使用解释器模式。思考:一个常见使用情况当然是操纵一种程序语言,例如JavaScript,Python。这个时候,我们通常使用一个脚本引擎库来实现解释器。然而,并不是所有语言都是程序语言,解释器模式更多的时候可以用来处理非程序语言,例如正则表达式。语言的规则也可以简单,也可以复杂,通常转载 2006-04-14 15:08:00 · 573 阅读 · 0 评论 -
设计模式笔记(11 OBSERVER & STATE)
OBSERVER(观察者)适用性:1.当一个抽象模型有两个方面,其中一个方面依赖于另一个方面。将这二者封装在独立的对象中以是他们可以各自独立地改变和复用。2.当对一个对象的改变需要同时改变其他对象,而不知道具体有多少对象有待改变。3.当一个对象必须通知其他对象,而他有不能假定其他对象是谁。思考: 考虑MVC架构的一个GUI场景,当一个模型对象改变,需要在多个View中及时的更新,而模型并不关转载 2006-04-14 15:05:00 · 616 阅读 · 0 评论 -
设计模式笔记(1 ABSTRACT FACTORY & BUILDER)
设计模式的书已经被翻的很旧了,最近,似乎开始明白书中讲述的内容了.还是把心得体会记录下来,算是一个脚印.1. ABSTRACT FACTORY(抽象工厂)适用性:一个系统要独立于其产品的创建时.一个系统要由多个产品系列中的一个来配置时.强调一个产品系列从而联合使用时.为一个产品库提供接口,屏蔽实现时.理解:抽象工厂通常作用于多个类似的类系列上,每个系列中,有着基本一致的类元素,或者说,可以为这转载 2006-04-14 15:14:00 · 585 阅读 · 0 评论