设计模式
文章平均质量分 54
wingfiring
这个作者很懒,什么都没留下…
展开
-
设计模式笔记(3 PROTOTYPE & SINGLETON)
PROTOTYPE(原型)适用性:当一个系统应该独立于他的产品创建,构成和表示时,要使用该模式.思考:对比FACTORY METHOD,工厂方法需要统一的Creator,而Creator的提供和被创建对象之间是各自独立的.也就是说,必须为具体的产品类提供相应的Creator(当然,C++的模版技术可以简化一些工作).从语意上来看,工厂方法是凭空创建一个对象,而原型是从已知实例复制新的拷贝.效果上,原创 2006-03-09 13:35:00 · 1715 阅读 · 0 评论 -
模式批判之Singleton
人们常说,模式是解决方案的重用,是经验的重用。借助已有的经验和典范,可以帮助我们少走弯路,还可以在更高的语言层次描述系统和相互沟通。然而,模式本身是如此的抽象,对于模式的理解和运用很大程度上依赖于程序员个人或团队的经验和技艺。模式是很好的东西,然而传授模式却是如此的困难。模式的适用性是一个非常重要的指标,错误地运用模式,将会加剧表达的不自然,恶化代码的可读性原创 2006-08-08 11:12:00 · 5008 阅读 · 7 评论 -
设计模式笔记(12 STRATEGY & TEMPLATE METHOD)
STRATEGY(策略)适用性:1.许多相关的类仅仅是行为有异。”策略“提供了一种用多个行为中的一个行为来配置一个类册方法。2.需要使用一个算法的不同变体。3.算法使用客户不应该知道的数据。可使用策略避免暴露复杂的、于算法有关的数据结构。4.一个类定义了多种行为,并且这些行为在这个类的操作中以多个条件语句的行署出现。将相关的条件分支移入他们各自的strategy类中以代替这些条件语句。思考:原创 2006-04-10 16:38:00 · 2262 阅读 · 0 评论 -
设计模式笔记(9 INTERPRETER & ITERATOR)
INTERPRETER(解释器)适用性:当有一个语言需要解释执行,并且你可以将语言中的句子表示为一个抽象语法树时,可使用解释器模式。思考:一个常见使用情况当然是操纵一种程序语言,例如JavaScript,Python。这个时候,我们通常使用一个脚本引擎库来实现解释器。然而,并不是所有语言都是程序语言,解释器模式更多的时候可以用来处理非程序语言,例如正则表达式。语言的规则也可以简单,也可以复杂,通常原创 2006-04-05 13:06:00 · 1952 阅读 · 0 评论 -
设计模式笔记(11 OBSERVER & STATE)
OBSERVER(观察者)适用性:1.当一个抽象模型有两个方面,其中一个方面依赖于另一个方面。将这二者封装在独立的对象中以是他们可以各自独立地改变和复用。2.当对一个对象的改变需要同时改变其他对象,而不知道具体有多少对象有待改变。3.当一个对象必须通知其他对象,而他有不能假定其他对象是谁。思考: 考虑MVC架构的一个GUI场景,当一个模型对象改变,需要在多个View中及时的更新,而模型并不关原创 2006-04-07 14:24:00 · 3608 阅读 · 0 评论 -
设计模式笔记(10 MEDIATOR & MEMENTO)
MEDIATOR(中介者)适用性:1.一组对象以定义良好但是复杂的方式进行通信,产生相互依赖关系混乱且难以理解。2.一个对象引用很多其他对象并且直接与这些对象通信,导致难以复用该对象。3.想定制分布在多个类中的行为,而又不想生成太多的子类思考: MEDIATOR模式虽然是协调对象的,但是对对象的组织方式也会带来重大影响。对于一组相互作用的对象,这种相互关系是网状的,搞清楚这组对象之间的联系是原创 2006-04-06 16:19:00 · 2018 阅读 · 0 评论 -
设计模式笔记(1 ABSTRACT FACTORY & BUILDER)
设计模式的书已经被翻的很旧了,最近,似乎开始明白书中讲述的内容了.还是把心得体会记录下来,算是一个脚印.1. ABSTRACT FACTORY(抽象工厂)适用性:一个系统要独立于其产品的创建时.一个系统要由多个产品系列中的一个来配置时.强调一个产品系列从而联合使用时.为一个产品库提供接口,屏蔽实现时.理解:抽象工厂通常作用于多个类似的类系列上,每个系列中,有着基本一致的类元素,或者说,可以为原创 2006-03-07 11:18:00 · 1895 阅读 · 0 评论 -
设计模式笔记(2 FACTORY METHOD)
FACTORY METHOD(工厂方法)理解:一个类需要创建某个类的实例,但是,又不知道(或者不该知道)如何创建实例时,需要工厂方法.例如一个TEMPLETE METHOD中,创建各种新实例(比如,各种文档),那么需要提供一个单一的创建接口,而将创建的实现分离出去,这种分离的创建行为,就是工厂模式.很显然,所有的创建行为,都必须提供共同的接口,创建的产品,也必须具有共同接口.这一点和抽象类厂是不一原创 2006-03-08 15:50:00 · 1672 阅读 · 0 评论 -
设计模式笔记(8 CHAIN OF RESPONSIBILITY & COMMAND)
CHAIN OF RESPONSIBILITY(职责链)适用性:1.有多个对象可以处理统一请求,但是,那个对象处理要到运行时刻决定。2.希望在不明确接收者的情况下,向多个对象中的一个提交一个请求。3.可处理一个请求的对象集合应该被动态指定。思考:既然要向未知的接收者提交请求,那么就需要统一的提交界面,也就是说,所有接收者应该实现一个公共接口,来接收请求,当然Delegate可以改变这一状况。一个典原创 2006-04-04 11:50:00 · 1714 阅读 · 0 评论 -
设计模式笔记(7 FLYWEIGHT & PROXY)
FLYWEIGHT(享元)意图:运用共享技术有效地支持大量细粒度的对象。适用性:1.一个程序应用了大量的对象,造成很大的存储开销。2.对象的大多数状态可变为外部状态。3.如果删除对象的外部状态,那么可以用相对较少的公象对象取代很多组对象。4.应用程序不依赖于对象标识思考: 上述的适用性和别的模式中介绍的不太一样。基本上,适合使用FlyWeight模式的场景需要同时满足上述四个条件,而别的模式原创 2006-04-03 14:17:00 · 2002 阅读 · 0 评论 -
设计模式笔记(5 COMPOSITE & DECORATOR)
COMPOSITE(组合)适用性:1.想表示对象的部分整体层次结构2.希望用户忽略组合对象和单个对象的不同。思考:组合模式的所有组件应该具备同一个接口。一直感觉,这种组合是一种递归组合的概念。所有的组件,按照树的结构组织起来,树的叶结点行为可能和中间结点的行为并不一致,这看上去违背了Liskov原则,似乎是一个容易引起迷惑的地方。树的叶结点可能并不能增加子结点,删除子结点的行为也可能失败。而一个中原创 2006-03-27 23:49:00 · 2155 阅读 · 2 评论 -
设计模式笔记(6 FACADE)
FACADE(外观)适用性:1.需要为一个复杂子系统提供一个简单接口时,为子系统提供一个简单的外观。2.客户程序与抽象类的实现之间存在很大的依赖性3.当需要构建一个层次结构的子系统时,使用FACADE来定义子系统中每层的入口点。思考: 关于第一点,好处是明显的,它降低了客户的学习成本。但是,一般而言,如果这个子系统是一个定制的子系统,可能直接提供一个简单接口更省事。如果这个子系统来是已经实现原创 2006-03-28 11:46:00 · 2056 阅读 · 0 评论 -
设计模式笔记(4 ADAPTER & BRIDGE)
ADAPTER(适配器)适用性:想使用一个已经存在的类,而它的接口不符合要求。想创建一个可以复用的类,该类可以与其他不相关的类或者不可预见的类协同工作。结构:适配器使用多重继承对一个接口和另一个接口适配。(这和proxy模式可以比较一下)多重继承的更好说法也许是组合。具体如何实现要看适配器的实现复杂程度。思考:被适配的类可能是多样的,但是应该完成相同的功能,适配器类只是用来匹配接口,并不是用来大规原创 2006-03-14 11:05:00 · 2160 阅读 · 0 评论 -
从设计模式到梁思成
Design Pattern已经成为软件设计中一个耳熟能详的词语了。并且,多半会联想到GOF的那本设计模式的名著。事实上,对我来说,尽管四位作者都是大牛,花边 新闻也关注了不少,但让我写出凭记忆写出四位作者的名字还是困难的。没办法,对老外的名字就是如此的不敏感。然而,GOF却很好记。 Gang of Four,第一次看到的反应,F4?F4挺有学问啊。起初,对于把GOF翻译成四人帮颇不以为然。干嘛搞原创 2008-01-06 20:18:00 · 4225 阅读 · 0 评论