Sunlight

淡泊明志 宁静致远
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

05 2006 档案

设计模式笔记(11 OBSERVER & STATE)

摘要：OBSERVER(观察者)适用性：1.当一个抽象模型有两个方面，其中一个方面依赖于另一个方面。将这二者封装在独立的对象中以是他们可以各自独立地改变和复用。2.当对一个对象的改变需要同时改变其他对象，而不知道具体有多少对象有待改变。3.当一个对象必须通知其他对象，而他有不能假定其他对象是谁。思考： 考虑MVC架构的一个GUI场景，当一个模型对象改变，需要在多个View中及时的更新，而模型并不关... 阅读全文

posted @ 2006-05-13 18:58 Happypig 阅读(136) 评论(0) 推荐(0)

设计模式笔记(12 STRATEGY & TEMPLATE METHOD)

摘要：STRATEGY(策略)适用性：1.许多相关的类仅仅是行为有异。”策略“提供了一种用多个行为中的一个行为来配置一个类册方法。2.需要使用一个算法的不同变体。3.算法使用客户不应该知道的数据。可使用策略避免暴露复杂的、于算法有关的数据结构。4.一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的行署出现。将相关的条件分支移入他们各自的strategy类中以代替这些条件语句。思考： ... 阅读全文

posted @ 2006-05-13 18:58 Happypig 阅读(165) 评论(0) 推荐(0)

设计模式笔记(8 CHAIN OF RESPONSIBILITY & COMMAND)

摘要：CHAIN OF RESPONSIBILITY(职责链)适用性：1.有多个对象可以处理统一请求，但是，那个对象处理要到运行时刻决定。2.希望在不明确接收者的情况下，向多个对象中的一个提交一个请求。3.可处理一个请求的对象集合应该被动态指定。思考：既然要向未知的接收者提交请求，那么就需要统一的提交界面，也就是说，所有接收者应该实现一个公共接口，来接收请求，当然Delegate可以改变这一状况。一个典... 阅读全文

posted @ 2006-05-13 18:57 Happypig 阅读(150) 评论(0) 推荐(0)

设计模式笔记(10 MEDIATOR & MEMENTO)

摘要：MEDIATOR(中介者)适用性：1.一组对象以定义良好但是复杂的方式进行通信，产生相互依赖关系混乱且难以理解。2.一个对象引用很多其他对象并且直接与这些对象通信，导致难以复用该对象。3.想定制分布在多个类中的行为，而又不想生成太多的子类思考： MEDIATOR模式虽然是协调对象的，但是对对象的组织方式也会带来重大影响。对于一组相互作用的对象，这种相互关系是网状的，搞清楚这组对象之间的联系是... 阅读全文

posted @ 2006-05-13 18:57 Happypig 阅读(138) 评论(0) 推荐(0)

设计模式笔记(9 INTERPRETER & ITERATOR)

摘要：INTERPRETER(解释器)适用性：当有一个语言需要解释执行，并且你可以将语言中的句子表示为一个抽象语法树时，可使用解释器模式。思考：一个常见使用情况当然是操纵一种程序语言，例如JavaScript，Python。这个时候，我们通常使用一个脚本引擎库来实现解释器。然而，并不是所有语言都是程序语言，解释器模式更多的时候可以用来处理非程序语言，例如正则表达式。语言的规则也可以简单，也可以复杂，通常... 阅读全文

posted @ 2006-05-13 18:55 Happypig 阅读(120) 评论(0) 推荐(0)

设计模式笔记(7 FLYWEIGHT & PROXY)

摘要：FLYWEIGHT(享元)意图：运用共享技术有效地支持大量细粒度的对象。适用性：1.一个程序应用了大量的对象，造成很大的存储开销。2.对象的大多数状态可变为外部状态。3.如果删除对象的外部状态，那么可以用相对较少的公象对象取代很多组对象。4.应用程序不依赖于对象标识思考： 上述的适用性和别的模式中介绍的不太一样。基本上，适合使用FlyWeight模式的场景需要同时满足上述四个条件，而别的模式... 阅读全文

posted @ 2006-05-13 18:55 Happypig 阅读(107) 评论(0) 推荐(0)

设计模式笔记(6 FACADE)

摘要：FACADE（外观）适用性：1.需要为一个复杂子系统提供一个简单接口时，为子系统提供一个简单的外观。2.客户程序与抽象类的实现之间存在很大的依赖性3.当需要构建一个层次结构的子系统时，使用FACADE来定义子系统中每层的入口点。思考： 关于第一点，好处是明显的，它降低了客户的学习成本。但是，一般而言，如果这个子系统是一个定制的子系统，可能直接提供一个简单接口更省事。如果这个子系统来是已经实现... 阅读全文

posted @ 2006-05-13 18:53 Happypig 阅读(173) 评论(0) 推荐(0)

设计模式笔记(4 ADAPTER & BRIDGE)

摘要：ADAPTER(适配器)适用性：想使用一个已经存在的类，而它的接口不符合要求。想创建一个可以复用的类，该类可以与其他不相关的类或者不可预见的类协同工作。结构：适配器使用多重继承对一个接口和另一个接口适配。（这和proxy模式可以比较一下）多重继承的更好说法也许是组合。具体如何实现要看适配器的实现复杂程度。思考：被适配的类可能是多样的，但是应该完成相同的功能，适配器类只是用来匹配接口，并不是用来大规... 阅读全文

posted @ 2006-05-13 18:53 Happypig 阅读(191) 评论(0) 推荐(0)

设计模式笔记(5 COMPOSITE & DECORATOR)

摘要：COMPOSITE(组合)适用性：1.想表示对象的部分整体层次结构2.希望用户忽略组合对象和单个对象的不同。思考：组合模式的所有组件应该具备同一个接口。一直感觉，这种组合是一种递归组合的概念。所有的组件，按照树的结构组织起来，树的叶结点行为可能和中间结点的行为并不一致，这看上去违背了Liskov原则，似乎是一个容易引起迷惑的地方。树的叶结点可能并不能增加子结点，删除子结点的行为也可能失败。而一个中... 阅读全文

posted @ 2006-05-13 18:52 Happypig 阅读(127) 评论(0) 推荐(0)

设计模式笔记(3 PROTOTYPE & SINGLETON)

摘要：PROTOTYPE(原型)适用性:当一个系统应该独立于他的产品创建,构成和表示时,要使用该模式.思考:对比FACTORY METHOD,工厂方法需要统一的Creator,而Creator的提供和被创建对象之间是各自独立的.也就是说,必须为具体的产品类提供相应的Creator(当然,C++的模版技术可以简化一些工作).从语意上来看,工厂方法是凭空创建一个对象,而原型是从已知实例复制新的拷贝.效果上,... 阅读全文

posted @ 2006-05-13 18:51 Happypig 阅读(163) 评论(0) 推荐(0)

设计模式笔记(2 FACTORY METHOD)

摘要：FACTORY METHOD(工厂方法)理解:一个类需要创建某个类的实例,但是,又不知道(或者不该知道)如何创建实例时,需要工厂方法.例如一个TEMPLETE METHOD中,创建各种新实例(比如,各种文档),那么需要提供一个单一的创建接口,而将创建的实现分离出去,这种分离的创建行为,就是工厂模式.很显然,所有的创建行为,都必须提供共同的接口,创建的产品,也必须具有共同接口.这一点和抽象类厂是不一... 阅读全文

posted @ 2006-05-13 18:50 Happypig 阅读(159) 评论(0) 推荐(0)

设计模式笔记(1 ABSTRACT FACTORY & BUILDER)

摘要：设计模式的书已经被翻的很旧了,最近,似乎开始明白书中讲述的内容了.还是把心得体会记录下来,算是一个脚印.1. ABSTRACT FACTORY(抽象工厂)适用性:一个系统要独立于其产品的创建时.一个系统要由多个产品系列中的一个来配置时.强调一个产品系列从而联合使用时.为一个产品库提供接口,屏蔽实现时.理解:抽象工厂通常作用于多个类似的类系列上,每个系列中,有着基本一致的类元素,或者说,可以为这... 阅读全文

posted @ 2006-05-13 18:49 Happypig 阅读(114) 评论(0) 推荐(0)