the_fire的技术博客

      前天看了一个设计模式视频，是用Java实现简单工厂模式，要是用if……else来判断的话，改到.net下也是很好实现的，但是在Java里面用到了反射的机制，这样就省去了工厂内部或是客户端内对要生产东西的判断。直接根据传进来的参数既可以完成生产。下面我给出我做的例子，先给出一般的通过if ……else来判断的：Imports System.ReflectionImport

上次米老师把我叫过去，问了一通MVC的东西，在确定我真的是不知道之后，决定让李坤师哥给我们来不上这么一课——很重要的一课——对于UML以及应用。想了几天关于mvc的东东，再加上上次米老师给我说的，我现在用一个例子来说明一下。就是简单工厂模式——这也是米老师当时给我讲的。类的关系图是这样的： 从这个图中应该很容易看得出其中各个模块之间的关系，对比一下M-V-C图：

同上一个简单工厂模式一样，都是那计算器来说事，先看UML图。在客户端（form1）中，通过对工厂子类的实现来操作具体的计算类。Factory Method：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。和简单工厂模式不同的是这里把一个大的工厂（原先用来控制所有具体计算类）分解为了相应的

前几天嗓子不舒服，去校医院买药。到校医院，看挂号那没开门（里面有人的），就直接到取药的地方去拿药。谁知人家就是不给拿。无奈之下只好去挂号那，A说明要来一盒西瓜霜，然后又跑过去拿药，我给钱人家说不行，这边不管收费，B到收费室去吧。（汗~），只好又去收费室，把钱给了，C然后又拿着盖好章的药单过去，这才拿到药。我想亏着我不是急诊，要是急诊也这么着，还真得把人给急死。下面用图形

<!-- /* Style Definitions */ table.MsoNormalTable {mso-style-name:普通表格; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-q

商场经常在节日期间做出不同的促销计划，因此商场的计费机制要不停地变动，因此在设计时应该考虑使用策略模式策略模式（Strategy），策略模式定义了算法家族，分别封装起来，让它们之间可以相互替换，此模式让算法的变化，不会影响到使用算法的客户。通过UML图来说事：其中CashContext算是一个简单工厂吧。现在有些理解简单工厂了，其实并不是一个设计模式，只

说有天有人来找，要出去。倒持了半天。完毕，然后出门。开始还得先看图：这个的具体实现可以自己试验一下。后来又去参加一个什么晚会，要求戴墨镜（带上之后发现天真黑。）上面的那个图显然不能用了，再改吧，把抽象的person类改了？no no no。开闭原则不允许我这么做。为了能够刷一把帅，只有这样了，看图：这样就好了。又不用违法，又为以后再添加别的装饰物开辟

最近打算去买块移动硬盘，买品牌的还是组装的呢？因为不是很富裕，也没有那么高的要求，就买个组装的吧。便宜些。最近还是在看设计模式，觉得建造者模式和外观模式差不多。于是仔细的比较一番，下面就虚拟用建造者实现买硬盘的过程。先看图：再来看一个具体的实现：Module Module1 Sub Main() Console.Wri