摘要: 动机:对象应对某种功能的增加或细微的变化,就要做对其本身或者子类做很大的变化,致使子类急剧膨胀;如何使对象功能的扩展根据需要在运行时动态的实现?如何避免扩展功能的增多带来子类的膨胀问题,从而使任何功能的变化导致的影响降为最低意图:运行时动态地给一个对象增加一些额外的职责。就增加功能而言,Decorator模式比生成子类更为灵活解决主体类在多个方向的扩展可使用性:在不影响其他对象的情况下,以动态、透明的方式给单个对象添加职责。 处理那些可以撤消的职责。 当不能采用生成子类的方法进行扩充时。一种情况是,可能有大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目呈爆炸性增长。另一种情况可能 阅读全文
posted @ 2012-02-24 10:58 JumpByte 阅读(192) 评论(0) 推荐(0) 编辑
摘要: 说明动机:* 在面向对象系统中,我们常常会遇到一类具有“容器”特征的对象——即他们在充当对象的同时* ,又是其他对象的容器。例如:* public class SingleBox:IBox public class ContainerBox:IBox* { {* public void Process(){....} public void Process(){....}* } public ArrayList GetBoxes(){....}* }* 如何我们要对这样的对象容器进行处理:* IBox box=Factory.GetBox();* if(box is ContainerBOx) 阅读全文
posted @ 2012-02-24 10:47 JumpByte 阅读(211) 评论(0) 推荐(0) 编辑
摘要: 问题分析:假如我们需要开发一个同时支持PC和手机的坦克游戏,游戏在PC和手机上功能都一样,都有同样的类型,面临同样的功能需求变化,比如坦克可能有多种不同的型号:T50,T75,T90..对于其中的坦克设计,我们可能很容易设计出来一个Tank的抽象类,然后各种不同型号的Tank继承自该类,但是PC和手机上的图形绘制、声效、操作等实现完全不同...因此对于各种型号的坦克,都 要提供各种不同平台上的坦克实现;而这样的设计带来了很多问题:有很多重复代码,类的结构过于复杂,难以维护,最致命的是引入任何新的平台,比如TV上的Tank游戏,都会让整个类层次级结构复杂化动机:思考上述问题的症结,事实上由于Ta 阅读全文
posted @ 2012-02-24 10:38 JumpByte 阅读(463) 评论(0) 推荐(0) 编辑
摘要: 动机:在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”放在新的环境中应用,但是新环境要求的接口使这些现存对象所不满足的。如何应对这种“迁移的变化”?如何即能利用现有对象的良好实现,同时又能满足新的应用环境所要求的接口?意图:将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作可适用性:你想使用一个已经存在的类,而它的接口不符合你的需求。 你想创建一个可以复用的类,该类可以与其他不相关的类或不可预见的类(即那些接口可能不一定兼容的类)协同工作。(仅适用于对象A d a p t e r )你想使用一些已经存在的子类,但是 阅读全文
posted @ 2012-02-24 10:26 JumpByte 阅读(360) 评论(0) 推荐(0) 编辑
摘要: 意图:使用原型实例指定创建对象的种类,然后通过拷贝这些原型来创建新的对象可适用性:当要实例化的类是在运行时刻指定时,例如,通过动态装载;或者 为了避免创建一个与产品类层次平行的工厂类层次时;或者 当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。UML图解:示例代码: 1 using System; 2 using System.Collections.Generic; 3 using System.Linq; 4 using System.Text; 5 6 namespace Prototype 7 { 8 ... 阅读全文
posted @ 2012-02-24 10:14 JumpByte 阅读(190) 评论(0) 推荐(0) 编辑
摘要: 动机:在软件系统中,有时候面临着“一个复杂对象”的创建工作,其通常由各个部分的子对象用一定的算法构成;由于需求的变化,这个复杂对象的各个部分经常面临着剧烈的变化,但是将它们组合在一起的算法却相对稳定;如何应对这种变化?如何提供一种“封装机制”来隔离复杂对象的各个部分的变化,从而保持系统中的“稳定构建算法不随需求的改变而改变意图:将一个复杂对象的构建与其表示相分离,使得同样的构建过程可以创建不同的表示。——《设计模式》GOF可适用性:当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。当构造过程必须允许被构造的对象有不同的表示时。UML图解:示例代码:游戏场景中Builder模式 阅读全文
posted @ 2012-02-24 10:08 JumpByte 阅读(157) 评论(0) 推荐(0) 编辑
摘要: 动机:在软件系统中,经常面临着“系列相互依赖的对象”的创建工作:同时,由于需求的变化,往往存在更多系列对象的创建工作;如何应对这种变化?如何绕过常规的对象创建方法(new),提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合?意图:提供一个接口,让该接口负责创建一系列“相关或者相互依赖的对象”,无需指定它们具体的类。适用性:一个系统要独立于它的产品的创建、组合和表示时。 一个系统要由多个产品系列中的一个来配置时。 当你要强调一系列相关的产品对象的设计以便进行联合使用时。 当你提供一个产品类库,而只想显示它们的接口而不是实现时。UML图:示例代码:游戏场景中Abstrac 阅读全文
posted @ 2012-02-24 09:54 JumpByte 阅读(168) 评论(0) 推荐(0) 编辑
摘要: 动机:当一个类不知道它所必须创建的对象的类的时候。当一个类希望由它的子类来指定它所创建的对象的时候。当类将创建对象的职责委托给多个帮助子类中的某一个,并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。意图:定义一个用于创建对象的接口,让子类决定实例化哪个子类。FactoryMethod使得一个类的实例化延迟到子类UML图:示例代码:演示说明 ,一个汽车测试软件系统 FactoryMethod的应用 1 public enum Direction 2 { 3 Right,Left 4 } 5 6 public abstract class Abst... 阅读全文
posted @ 2012-02-24 09:44 JumpByte 阅读(152) 评论(0) 推荐(0) 编辑
摘要: 动机:在软件系统中,经常有这样的一些特殊的类,必须保证它们在系统中只存在一个实例,才能确保它们的逻辑正确性、以及良好的效率意图:保证一个类仅有一个实例,并提供一个该实例的全局访问点UML图:示例代码: 1 using System; 2 using System.Collections.Generic; 3 using System.Linq; 4 using System.Text; 5 6 namespace Singleton 7 { 8 /// 9 /// 只适用单线程下的单例模式,在多线程下无法保证其唯一实例10 /// 11 //public c... 阅读全文
posted @ 2012-02-24 09:32 JumpByte 阅读(135) 评论(0) 推荐(0) 编辑