2012年5月25日

设计模式笔记(25)---总结

摘要: 断断续续经历了几个月的时间将WebCast的设计模式讲座重新完整听了一遍,并做了笔记,才有了这个设计模式笔记系列,本系列的文章大部分只是给出了基本代码的实现,而并没有去衍生其他的一些例子,笔者认为通过基本的代码实现就能够了解到模式的应用场景,弄出些花哨的例子反倒会让人眼花缭乱,可能并达不到预期的效果,毕竟在实际的应用中我们不是去套用模式。本文作为该系列的最后一篇,将对设计模式做个总结。首先看下创建型、结构型、行为型这三种类型的模式的解释创建型Singleton模式解决的是实体对象个数的问题。除了Singleton之外,其他创建型模式解决的都是new所带来的耦合关系。Factory Method 阅读全文

posted @ 2012-05-25 15:02 zhuhai 阅读(138) 评论(0) 推荐(0)

设计模式笔记(24)---访问者模式(行为型)

摘要: Gof定义表示一个作用于某对象结构中的各元素的操作。它可以在不改变各元素的类的前提下定义作用于这些元素的新的操作。动机在软件构建过程中,由于需求的改变,某些类层次结构中常常需要增加新的行为(方法),如果直接在基类中做这样的更改,将会给子类带来很繁重的变更负担,甚至破坏原有设计。如何在不更改类层次结构的前提下,在运行时根据需要透明地为类层次结构上的各个类动态添加新的操作,从而避免上述问题?请看下面访问者模式结构图和代码。访问者模式结构图:基本代码如下:/// <summary>/// 声明了一个或多个需要添加的操作/// </summary>public abstract 阅读全文

posted @ 2012-05-25 15:02 zhuhai 阅读(173) 评论(0) 推荐(0)

设计模式笔记(23)---策略者模式(行为型)

摘要: Gof定义定义一系列算法,把它们一个个封装起来,并且使它们可互相替换。该模式使得算法可独立于使用它的客 户而变化。动机在软件构建过程中,某些对象使用的算法可能多种多样,经常改变,如果将这些算法都编码到对象中,将会使对象变得异常复杂;而且有时候支持不使用的算法也是一个性能负担。如何在运行时根据需要透明地更改对象的算法?将算法与对象本身解耦,从而避免上述问题?看下面的策略者模式的结构图和基本代码,策略者模式比较简单,下面只是给出基本的代码实现。策略者模式结构图:基本实现代码:/// <summary>/// 抽象算法类/// </summary>public abstrac 阅读全文

posted @ 2012-05-25 15:00 zhuhai 阅读(157) 评论(0) 推荐(0)

设计模式笔记(22)---状态模式(行为型)

摘要: Gof定义允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。动机在软件构建过程中,某些对象的状态如果改变,其行为也会随之而发生变化,比如文档处于只读状态,其支持的行为和读写状态支持的行为就可能完全不同。如何在运行时根据对象的状态来透明地更改对象的行为?而不会为对象操作和状态转化之间引入紧耦合?看下面状态模式的结构图和代码。状态模式结构图:日常生活中我们常见的灯会有两种状态开和关,当灯亮着时我们可以用开关使之熄灭,反之则变量,看下面的代码就是改变灯的开关状态的一个过程:/// <summary>/// 灯的状态开和关/// </summary> 阅读全文

posted @ 2012-05-25 14:59 zhuhai 阅读(184) 评论(0) 推荐(0)

设计模式笔记(21)---备忘录模式(行为型)

摘要: Gof定义在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。动机在软件构建过程中,某些对象的状态在转换过程中,可能由于某种需要,要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态,便会暴露对象的细节实现。如何实现对象状态的良好保存与恢复?但同时又不会因此而破坏对象本身的封装性,看下面的结构图和代码。备忘录模式结构图:上图中Originator为原发器,也可以讲发起者,可以创建一个备忘录(CreateMemento),Memento为备忘录,负责存储原发器中的内部状态。Caretake 阅读全文

posted @ 2012-05-25 14:58 zhuhai 阅读(178) 评论(0) 推荐(0)

设计模式笔记(20)---职责链模式(行为型)

摘要: Gof定义使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递请求,直到有一个对象处理它为止。动机在软件构建过程中,一个请求可能被多个对象处理,但是每个请求在运行时只能有一个接受者,如果显式指定,将必不可少地带来请求发送者与接受者的紧耦合。如何使请求的发送者不需要指定具体的接受者?让请求的接受者自己在运行时决定来处理请求,从而使两者解耦。职责链模式结构图如下:代码实现:/// <summary>/// 抽象处理类/// </summary>public abstract class BaseHandler{ pu 阅读全文

posted @ 2012-05-25 14:57 zhuhai 阅读(168) 评论(0) 推荐(0)

设计模式笔记(19)---观察者模式(行为型)

摘要: Gof定义定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通 知并自动更新动机在软件构建过程中,我们需要为某些对象建立一种“通知依赖关系” ——一个对象(目标对象)的状态发生改变,所有的依赖对象(观察者对象)都将得到通知。如果这样的依赖关系过于紧密,将使软件不能很好地抵御变化。使用面向对象技术,可以将这种依赖关系弱化,并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。看这样一个场景,银行的ATM机在处理完成银行账户的存入或取出后会给用户发送手机短信和电子邮件,那么就会有这样三个对象,BankAccount Emailer Mobile,代码如下: 阅读全文

posted @ 2012-05-25 14:56 zhuhai 阅读(204) 评论(0) 推荐(0)

设计模式笔记(18)---迭代器模式(行为型)

摘要: Gof定义提供一种方法顺序访问一个聚合对象中的各个元素, 而又不暴露该对象的内部表示。动机在软件构建过程中,集合对象内部结构常常变化各异。但对于这些集合对象,我们希望在不暴露其内部结构的同时,可以让外部客户代码透明地访问其中包含的元素;同时这种“透明遍历”也为“同一种算法在多种集合对象上进行操作”提供了可能。使用面向对象技术将这种遍历机制抽象为“迭代器对象”为“应对变化中的集合对象”提供了一种优雅的方式。迭代器模式结构图:Aggregate:集合结构接口Iterator:迭代器接口Concreteaggregate:集合结构的具体类,继承Aggregate接口ConcreteIteator:具 阅读全文

posted @ 2012-05-25 14:54 zhuhai 阅读(137) 评论(0) 推荐(0)

设计模式笔记(17)---中介者模式(行为型)

摘要: Gof定义用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。动机在软件构建过程中,经常会出现多个对象互相关联交互的情况,对象之间常常会维持一种复杂的引用关系,如果遇到一些需求的更改,这种直接的引用关系将面临不断的变化。在这种情况下,我们可使用一个“中介对象”来管理对象间的关联关系,避免相互交互的对象之间的紧耦合引用关系,从而更好地抵御变化。中介者模式的结构图:代码实现:/// <summary>/// 抽象的中介者/// </summary>public abstract class Media 阅读全文

posted @ 2012-05-25 14:51 zhuhai 阅读(181) 评论(0) 推荐(0)

设计模式笔记(16)---解释器模式(行为型)

摘要: Gof定义给定一个语言,定义它的文法的一种表示,并定义一种解释器,这个解释器使用该表示来解释语言中的句 子。动机在软件构建过程中,如果某一特定领域的问题比较复杂,类似的模式不断重复出现,如果使用普通的编程方式来实现将面临非常频繁的变化。在这种情况下,将特定领域的问题表达为某种语法规则下的句子,然后构建一个解释器来解释这样的句子,从而达到解决问题的目的。下面看下解释器模式的结构图基本代码:/// <summary>/// 上下文信息/// </summary>public class Context{ public string Data { get; set; }}// 阅读全文

posted @ 2012-05-25 14:50 zhuhai 阅读(149) 评论(0) 推荐(0)

设计模式笔记(15)---命令模式(行为型)

摘要: Gof定义将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。动机在软件构建过程中,“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合——比如需 要对行为进行“记录、撤销/重做(undo/redo)、事务”等处理,这种无法抵御变化的紧耦合是不合适的。在这种情况下,如何将“行为请求者”与“行为实现者”解耦?将一组行为抽象为对象,可以实现二者之间的松耦合。先来看个反例(版本1),假设在一个应用程序中需要用到要用到很多的一些外部的类,并且要对这些类中的操作进行撤销、记录等操作,如果像下面这样实现就会很乱并且不容易实现:pu 阅读全文

posted @ 2012-05-25 14:48 zhuhai 阅读(170) 评论(0) 推荐(0)

设计模式笔记(14)---模板方法模式(行为型)

摘要: Gof定义定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个 算法的结构即可重定义该算法的某些特定步骤。动机在软件构建过程中,对于某一项任务,它常常有稳定的整体操作结构,但各个子步骤却有很多改变的需求,或者由于固有的原因(比如框架与应用之间的关系)而无法和任务的整体结构同时实现。如何在确定稳定操作结构的前提下,来灵活应对各个子步骤的变化或者晚期实现需求?模板方法模式结构图:AbstractClass类:这个抽象类中定义了一个模板方法TemplateMethod,该方法通常为一个具体方法,将抽象类中的一些抽象的操作组合在其中,推迟到子类实现 阅读全文

posted @ 2012-05-25 14:47 zhuhai 阅读(125) 评论(0) 推荐(0)

设计模式笔记(13)---代理模式(结构型)

摘要: Gof定义为其他对象提供一种代理以控制对这个对象的访问。动机在面向对象系统中,有些对象由于某种原因(比如对象创建的开销很大,或者某些操作需要安全控制,或者需要进程外的访问等),直接访问会给使用者、或者系统结构带来很多麻烦。如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性?增加一层间接层是软件开发中常见的解决方式。看下结构图:Subject:该类中定义了一些RealSubject和Proxy中共有的方法。RealSubject:这个类是Proxy所要代理的实体类,客户端只和Proxy交互。代码实现:/// <summary>/// 公共接口/// </summar 阅读全文

posted @ 2012-05-25 14:45 zhuhai 阅读(132) 评论(0) 推荐(0)

设计模式笔记(12)---享元模式(结构型)

摘要: Gof定义运用共享技术有效地支持大量细粒度的对象。动机采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,从而带来很高的运行时代价——主要指内存需求方面的代价。如何在避免大量细粒度对象问题的同时,让外部客户程序仍然能够透明地使用面向对象的方式来进行操作?这需要用到享元模式,不过应用享元模式是需要进行评估的,也就是说在当前情况下是否会对系统造成性能上的影响,如果会那么就是用,下面先来看个小例子是如何进行评估的。假设有一个字符的类Charator,如下:public class Charator{ char c; Font f;}为了方便评估,Charator类中的Font... 阅读全文

posted @ 2012-05-25 14:44 zhuhai 阅读(189) 评论(0) 推荐(0)

My97日历控件常用功能记录

摘要: My97相信大家都不陌生,应该是我所见过的最强大的一个日历控件了,最近的项目中也比较多地用到了此控件,而且项目中经常会有不同时间范围的需求,在此列出一些比较常用的日期范围格式的设置,尽管在My97的官方文档中有很详细的介绍,正是因为很详细所以查找起来不是很方便。1 可以选择任何日期<input id="txtDate" class="Wdate" type="text" onfocus="WdatePicker()" />2 今天以前的日期<input type="text" 阅读全文

posted @ 2012-05-25 14:43 zhuhai 阅读(205) 评论(0) 推荐(0)

设计模式笔记(11)---外观模式(结构型)

摘要: Gof定义为子系统中的一组接口提供一个一致的界面,Façade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。先来看个小例子,假设我们需要开发一个坦克模拟系统用于模拟坦克车在各种作战环境中的行为,其中坦克系统由引擎、控制器、车轮、车身等各子系统构成。就会有下面这些类的产生public class Wheel{ }public class Engine{ }public class Controller{ }public class BodyWork{ }不同的场景中的要求都不一样,可能会用到某些子系统,也可能不会用到,这些不同的场景就相当是外部接口,这些场景和子系统的关系 阅读全文

posted @ 2012-05-25 14:43 zhuhai 阅读(150) 评论(0) 推荐(0)

设计模式笔记(10)---装饰模式(结构型)

摘要: Gof定义动态地给一个对象增加一些额外的职责。就增加功能而言,Decorator模式比生成子类更为灵活。首先来看一个小例子,假如我们需要给游戏开发一种坦克,除了各种不同型号的坦克外,还希望在不同的场合来给坦克增加以下的一种或多种功能:比如红外线夜视功能、水陆两栖功能、GPS定位功能等。通常做法如下:/// <summary>/// 抽象坦克/// </summary>public abstract class Tank{ public abstract void Shot(); public abstract void Run();}//型号public class T 阅读全文

posted @ 2012-05-25 14:42 zhuhai 阅读(166) 评论(0) 推荐(0)

设计模式笔记(9)---组合模式(结构型)

摘要: Gof定义将对象组合成树形结构以表示“部分--整体”的层次结构。Composite使得用户对单个对象和组合对象使用具有一致性。在面向对象系统中,我们经常会遇到一类具有”容器“特征的对象---即他们在充当对象的同时,又是其他对象的容器。比如在一些管理系统中就会出现总公司下面有很多的分公司,分公司下面有很多的部门,每个部门下又有很多的员工,像分公司和部门就是既充当了“对象”的角色也充当了“容器”的角色;还有我们可能玩过的“俄罗斯套娃”也是这种结构,一个大娃娃里面装个小娃娃,小的里面又有个小的直到最小的一个,中间的娃娃就是既充当了“对象”也充当了“容器”。先看下面这个例子:interface IBo 阅读全文

posted @ 2012-05-25 14:41 zhuhai 阅读(183) 评论(0) 推荐(0)

设计模式笔记(8)---桥接模式(结构型)

摘要: Gof定义将抽象部分与实现部分分离,使他们都可以独立地变化。先来看一个简单的例子,假设我们需要开发一个同时支持PC和手机的坦克游戏,游戏在PC和手机上的功能都一样,有同样的类型,有同样的功能需求变化,而这些游戏中的坦克有多种不同的型号:T50 T60等。根据面向对象的思想,我们可以很容易设计一个坦克(Tank)的抽象类,然后不同的型号都继承抽象类,并且PC和手机上的图形绘制,操作等都是不相同的,所以不同的平台都要提供自己的一套实现:坦克抽象类/// <summary>/// 坦克的抽象类/// </summary>public abstract class Tank{ 阅读全文

posted @ 2012-05-25 14:40 zhuhai 阅读(161) 评论(0) 推荐(1)

设计模式笔记(7)---适配器模式(结构型)

摘要: Gof定义将一个类的接口转换成客户所希望的另一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。动机在软件系统中,由于应用环境的变化,常常要将“一些现存的对象”放在心的环境中应用,但是新环境要求的接口是这些现存对象所不满足的。适配的意思是在不改变原有实现的基础上,将原先不兼容的接口转换为兼容的接口。在我们的生活中有着很多适配器的例子,笔记本的电源适配器、一些卡的USB读卡器等等。在Gof23这本书中将适配器模式分成了两种:对象适配器和类适配器对象适配器上图中的Target是客户所期待的,希望去使用的类或接口。Adaptee是被适配的对象。Adapter为适配的对象。首 阅读全文

posted @ 2012-05-25 14:36 zhuhai 阅读(206) 评论(0) 推荐(0)

导航

我的百度空间