
设计模式
文章平均质量分 76
yarshray
这个作者很懒,什么都没留下…
展开
-
由实例计数器引出(C#)
由实例计数器引出(C#)好久没发表文章了,说也有趣,突然感觉C#中的有些类,为什么,其构造器是不可见的?而且通常这些类在一个程序中往往只有一个实例存在。于是,我做了个实验结果如下:由该例子引出:using System; namespace ConsoleApplication1{ /// /// Class1 的摘要说明。 /// class Class1 { ///原创 2003-01-20 12:47:00 · 1194 阅读 · 0 评论 -
共同的天空(FlyWeight)
很多情况下.大量的类似之处使得我们不得不为重复的数据使用少的可怜的内存.这样的情况很糟糕.既然如此.我们必须找到一个好的办法.把那些可能重复的数据统一管理这样是在合理不过的事情了.好的..我们应该从如下几个方面来考虑.首先要找出对象之间的共同之处.这部分是可以共享.那么就需要封装到一个类中.那么剩下的不能共享的就只好封装到另外的类中.换句话说.就是把对象的粒度扩大.让FlyW原创 2003-07-14 08:07:00 · 1104 阅读 · 0 评论 -
局部神经(Composite)
某些情况.你也许希望当你改变某一个个体.而使得整个系统的其他与之关联的个体也能感应到并作出正确的判断.这种情况很常见.如同.当你对你的主系统芯片升级的时候.你的整体性能也得到相应的提高.(现实中不一定.我只是打个比方).那么很明显,你的其它部件也感应到了主系统的性能的改变.也就是说.主系统传递给没个与之关联的子系统.我现在升级了.你们会得到更多的辅助性能的提升.这样就达成了局原创 2003-07-14 17:55:00 · 1072 阅读 · 0 评论 -
决策者得选择(Strategy)
我们似乎总是在为选择这个词苦恼.当我们选择生活得时候就放弃了激情.当我们选择程序员得时候就放弃了时间.这一切都是在动态得抉择得.并非有命运决定.而是在动态得自身来决定.好了现在考虑一个比较现实得问题.假设.如果你有个临时会议.却无法确定什么时候要去.因为是临时决定得.就无法决定.如果现在得时间是5:00--6:00那么你必须要去参加.否则你依然可以留在公司办公.且开会和办原创 2003-07-15 17:12:00 · 1214 阅读 · 0 评论 -
中介者(Mediator)
这个模式的定义就很简单用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。好处是什么呢?很显然就是为了降低复杂度.使的原本使多对多关系.现在变成了1对多关系.因为所有对象都只和Mediator中介者单线联系.而中介者隐士的包含了对象之间的关系.下面还是举个简单的事例.如:小王要把稿件交给小李.小李要原创 2003-07-16 08:13:00 · 1255 阅读 · 0 评论 -
C#中多重继承
其实想写这篇文章,是因为突然在整理论坛上的帖子的时候,突然发现一个人问我如何才能在C#中实现多重继承,当时我答的很隐晦,因此这里我想补充说明一下.首先,我要说明一下,C#中是没有类的多重继承这个概念.要使用多重继承必须要通过接口Interface来完成.可是大家都知道Interface实际上就是一个虚函数列表指针.内部封装的只有函数和属性.而且接口(Interface)不能实力化只能通过派生(原创 2003-03-31 09:38:00 · 6376 阅读 · 0 评论 -
记忆点(Memento)
很多情况下在我们改变了很多东西的时候。却开始后悔了。也许这就是人类的软弱一面。不管怎么样人生是无法回到原点的。可是软体可以,因为一切运行的程序都是加载在内存中的。所以即使改变了,我们也是可以有办法回到原点的。我想你也许已经猜到我要说什么了吧?是的。Memento 模式。一个很简单的模式。//原对象public class Originator { public int number;原创 2003-07-13 12:27:00 · 1055 阅读 · 0 评论 -
魔力拼图(Builder)
假如有一种拼图可以拼贴成任何图形.那么我们只要生产出这种拼图的单个部件就可以了.那样就会使复杂的图形变的简单化.也就是说我们只用设计每一个单个步骤就可以了.这样做的好处是什么呢?很显然.我们在利用元件生产产品.而不需要直接生产一个巨大的产品.因为可能这些元件本身就具有通用性.另外的好处是.来自与其本身的复杂性.因为要生产就必须要组装.而把生产和组装分开来考虑.那么复杂性就会有原创 2003-07-14 15:59:00 · 1148 阅读 · 0 评论 -
前人栽树后人乘凉(Template)
这个模式可能是目前最简单的模式了.因为几乎所有的面向对象语言都支持抽象因为.毕竟这是面向对象的基本法则.而Template的模式定义一个操作中的算法的骨架,而将一些步骤延迟到子类中,这在明确不过了.就是使用抽象类.所以几乎不用太过多的介绍什么.不过考虑到要写完所有的23种模式所以,还是写一篇吧虽然简单.但是常见.也很通用.假如我们要设计一个容器.而容器的样式无法提前确定,原创 2003-07-15 07:17:00 · 1397 阅读 · 0 评论 -
孪生兄弟(Prototype)
某一天,当你发现有另外一个你存在的时候是高兴还是感到害怕?这也许违背目前人类的道德准则可是对于可以协作的对象来说如果有必要的时候需要动态的生成一个和自己一样的对象.那么无疑是一个好的发展方向.也许你听说了.是的.那就是在你无需知道具体如何复制的时候.只需要一个主动创建对象然后通过Prototype原型来达到你的目的.在.NET中一切对象都派生自object类.也就是说从一开始就具备了Memb原创 2003-07-13 22:27:00 · 1016 阅读 · 0 评论 -
旅行中的状态(state)
我不知道我的这个标题是否合适.反正不管了.我只是希望用轻松的写法把设计模式表示清楚.(当然也许不清楚)反正我就怎么写了.OK,现在好了.如果在旅行中一个旅者有很多种状态.这些状态会直接影响到他的行为.例如.饿了就去吃饭.渴了就要喝水.累了就要休息.正常状态就要继续旅行.并且这些状态相互切换.那么你会怎么做?如果是我.我首先会想到使用开关.那要直观简单.Ok那我们就那么做enum mySt原创 2003-07-13 22:15:00 · 1149 阅读 · 0 评论 -
一脚踢掉NEW
为什么不要NEW?如果你要问我这个问题。我想我必须答,否则你一定认为,这样做是多余的。好的,我来回答。首先我想说你在什么情况用NEW,你毫无疑问的回答到。构造对象的时候。答的很好。听着,如果构造的对象不是普通的对象而是相当复杂的对象。可能要从数据库读取数据或者还要执行其它附加问题呢?你要统统把他们写入构造函数吗?只能是那样吗?噢。。。听着在这之前。我必须说。你违背了面向对象的封装和派分。如果某一天原创 2003-07-13 11:28:00 · 1037 阅读 · 0 评论 -
我的代理人(Proxy)
很显然.我们目前所生活的世界里.到处都有这类人.他们很愿意帮助我们去完成我自身完成起来很困难的工作.愿意充当一个中间层.在这一个层次中.Proxy代理就是主导.他会为我们处理那些看上去很别扭的事情.毕竟我们的目的是制定总体方针.儿细节可以交给代理来完成.事实上,很多情况.我们都用到了代理.例如典型的我们在.NET中使用WebService就已经在使用Proxy.通过这个代理和实际的远程对象打原创 2003-07-13 22:14:00 · 1124 阅读 · 0 评论 -
统一求存(Facade)
感觉有点政治的味道.当然.我们并不讨论政治.只是在说明很多情况下都必须进行的一种措施事实上.当你并不想为每一个子系统建立独立的操作的时候.你也许更加希望能够有一个单一的操作方案可供选择.那要不必为每个子系统都寻求其特有的操作方案.使操作变的单一.Facde就可以做到这一点.假设你有三个播音设备.分别使CD 磁带机,Mp3 它们分别有自己独立的操作放案.这让你很头痛因为你必原创 2003-07-14 15:57:00 · 1081 阅读 · 0 评论 -
通讯兵(Chain of Responsibility)
如果看英文名字的话你可能会想到责任链.其定义为使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。那么可能会误解.其实这个模式很类似消息通讯.也就好象是在对应的消息函数.至少我看完这个模式首先想到的就是这个.的确也是十分象.你甚至也可以构造一个句柄来判断消息处理函数.当然我们没必要原创 2003-07-16 08:13:00 · 1578 阅读 · 1 评论 -
让你插上翅膀(Decorator)
对你的对象进行扩展这是在平常不过的事情了.问题是,你该如何做?很多方案不是吗?例如派生子类是的.这是个不错的方案.可是如果是在这样一种情况.我们需要在运行期间添加功能并且有客户程序来决定合适添加何种功能.那么单纯的扩展子类对象能够办到吗?那么我们必须想办法新的办法了.是的.你也许已经想到我要说的Decorator模式了吧.由它来帮你在想要的时候插上翅膀.通过接口来组合是个非常原创 2003-07-14 16:14:00 · 1139 阅读 · 0 评论 -
魔法牌里的模式(Bridge)
不知道各位有没有玩过魔法牌.基本分也两种.一种称为攻击卡.另一种称为辅助卡片.攻击卡负责攻击.而辅助卡则负责效果.例如加强攻击效果.或者减弱敌方攻击效果等等这样看了.实现部分是就是所谓的攻击卡.而抽象部分就是效果卡.他们有联系可是联系并非平行的联系.也就是说并不象如同剑士可以派生出魔法剑士,光明剑士等这样的情况攻击效果卡.和攻击卡本身的联系不是静态的可以通过继承来完成的.而是原创 2003-07-15 07:17:00 · 1397 阅读 · 0 评论 -
随着变化而变化(Observer)
对于很多事物.都在不断变化.也就是说.在不断变化的情况下.我们必须能够得到其相互关联的对象之间的变化.也就是能够通知到其他对象.但不同于牵一动百的情况因为毕竟只是告诉相互关联的对象与之对应的数值才发生变化.换句话就是某个对象的状态发生变化.于它相对应的一组对象将要随着变化.这里就引出了观察者.通知者的对应关系.观察者发现变化.通知者就告诉每个与之相关的对象都发生相应的变化.原创 2003-07-15 07:16:00 · 1164 阅读 · 0 评论 -
执行方案(Command)
这个模式.可能是变化比较多的一个模式.也是最没有定型的一个模式.因为相对比较灵活.常见的是对GUI图形界面的命令封装这样即使更改界面元素只要功能不变那么也不影响执行效果.就如同以前面向过程的编程环境那要.吧功能封装到多个过程.进行调用.但是Command模式.又一个优点就是可以还原把以前做过的工作还原到未做工作之前.这个也就是事务性.这就必须要一个事务列表来维护.事务回滚原创 2003-07-15 13:36:00 · 1180 阅读 · 0 评论 -
订阅属于自己得资料(Visitor)
有时候.我们总是不希望出现不速之客.而是更希望来的是我们的朋友.可是如果用一支普通的笔把所有人的名字记录下来我们很难判断那些才是我们的朋友.所以.如果有一支友情之笔和一个之能呈现友情之笔的笔记本.那么情况就好的多了.就如同当你使用ArrayList或Hashtable之类的容器装载数据的时候.所有的数据都别染成了同样的颜色---object 而你必须时刻判断是否你想要的数据类原创 2003-07-15 16:15:00 · 1118 阅读 · 0 评论