一起谈模式，ok？

Design Patters 四人帮的书，买了两年了，反复也懂或不懂的读了几边了，一点小小的感受，希望与大家分享。
   模式我的感觉就是程式的解决方案，最大限度的适应外界不确定的变化。
   
    低藕合和复用效果应该是想要的一个效果，在delphi的系统架构中，我们经常会用到哪些呢？   创建型模式：
        我们更多的是用了Factory 和 Builder(组合对象)，尤其以Factory为重，而我们的操作主要目的是为了界面的统一。Builder对象的构建与它的表示分离，这是我们值得学习的地方。
        Singleton也有时用到，就是保证该实例是唯一的，比如你要保证某个系统某个窗体排他性。
   行为型模式：
     Chain of Responsebilty ：就是孩子的事情不做，就要老爷子去处理了，类似于win的消息机制，如果孩子有处理消息的需求，就让他处理。
     Command：菜单处理了，或TActionList类中，不同需求，参数化改变，使得客户数据改变。当然这里有类似代理的感觉。要是和备注搭配实现撤销的功能是在我们的设计中很有好处的。
     InterPreter：我们自己的契约，然后我们自己的表达翻译方式。说白了就是我们规定工程中的某些我们有意义的集合或常量，以我们的实际要求显示和追踪，然后翻译成我们的流程或所需。
    Iterator：类似与数组或链表的功能，同时绑定相应的我们需要的实例。实现查询特定的需求，或返回特定的元件。当然和visitor差别不是很大，vsitor对于特定的绑定，或修改特定绑定的操作，使之协调。
    Mediator：用一个对象封装一系列对象交互。使藕合松散，不需要之间直接打交道。porpxy只为某个对象代理，给出的相当于个接口，而Mediator是多个对象的调解。
   Strategy：就是封装你系统用的函数集合。
   Observer，State：我个人认为这两个搭配使用效果更好，他们相当于mvc中的C，某个实例变化，观察到状态，然后改变他们的视图。
   比如：我的一个系统中有多个相同的树型控件，并且在不同的界面，开始的做法是我们每到一个页面就要进行刷新，可是多层架构数据处理切换会带来速度和时间上的不爽。我们需要一个观察者，发现数据变化，我们就会去更新。但问题又出来了，如果多个客户端，而别的客户端数据发生改变又如何呢？所以我们就对应一个特定的树状态检测配合观察者实现要求效果。   结构型模式：
     老板让我干活了，有空再写了！
   各位身体健康！工作倍爽！