徐麟家的博客

点评

命令模式是一种松耦合得设计，解耦命令的请求者和命令的实现者。
优点：
1.它能较容易地设计一个命令队列
2.在需要的情况下，可以较容易地将命令记入日志
3.允许接收请求的一方决定是否要否决请求
4.可以容易地实现对请求的撤销和重做
5.由于加进新的具体命令类不影响其他的类，因此增加新的具体命令类很容易

设计警示

敏捷开发原则告诉我们，不要为代码添加基于猜测的、实际不需要的功能。如果不清楚一个系统是否需要命令模式，一般就不要着急去实现它，事实上，在需要的时候通过重构实现这个模式并不困难，只有在真正需要如撤销/恢复操作等功能时，把原来的代码重构为命令模式才有意义。

点评

观察者模式是一个解耦模型。通俗的话来讲，当一个抽象关系中一方依赖于另外一方，观察者可以让双方各自独立。即被观察者不需要知道具体有的观察者（只关心自己的变化），观察者也不需要知道具体的被观察者的细节（只关系如何响应变化）。 整理下思路：观察者的设计模式，引申出了事件设计。在大大小小的框架都会有事件的身影，主要是很好用的设计。事件的颗粒度是方法，观察者的颗粒度是类。两者在设计思想上是完全一样的，只是作用域的范围。我们可以说观察者是对类的抽象；事件是对方法的抽象。观察者显得更为重度，讲究封装，结构会更加完整些；事件就会显得小巧，使用非常灵活。但牺牲的是结构，那么事件的分布会比较零散。在业务逻辑开发的时候，因为业务本身就比较的零散个人会比较倾向于事件，用起来比较的小巧，方便。事件在C#中已经得到语法层的支持————事件和委托。

注意点

使用观察者或者事件都应该注意循环触发。

点评

使用组合模式的一个特点是当你目标需求中有层次式的结构。有部分和整体的区别时，希望忽略组合和对象的不同，可以考虑使用组合模式。

点评

装饰类就好像是一个一个包装的盒子，设计分为两部分ConcreteComponent（被包装的对象）和Decorator（包装类）同时继承自Component， Decorator::Operation（）实现包装的操作，Decorator::SetComponent（Component） 负责如何包装。 装饰模式与创建者模式和模板方法模式相比，后两个模式注重过程的稳定性，时序的确定性；而前者更突出灵活性，可修改性。

点评

享元模式是一个即拿即用的，用于共享对象的设计模式。难点在于区分享元的内部对象（可以被公用的）和外部对象(用户独有的，用户数据等)。 对象池和享元的区别：对象池在创建一个新物体时会先在对象池中寻找需要的对象。如果存在，那么便直接将这个对象取出，并进行初始化。如果不存在，那么便新创建一个对象，在执行上述操作，注册到对象池中，对象池一般不自己创建对象，而是外部创建的。 享元模式则会在享元工厂中寻找需要的对象，将它的引用拿过来，没有就负责创建完它 ——————（即享元的工作会更多些，它会负责创建工作。）

点评

外观模式很好地体现了依赖倒转原则和迪米特法则的思想，所以非常常用。在层次式架构中尤为体现重要性，mvc相信大家有一定的了解，网上也有很多详细的文档，这里不在赘述。为了提供一些子系统的功能，快速操作model、view、control会有一个外观类（也叫门面）facade。为复杂的子系统提供一个简单的接口，能降低耦合度，便利用户使用。

点评

在实际开发中桥接是非常常见的设计，可能当你使用时你并没有发现:"原来你正在使用它"。建议当继承的类非常繁多的时候，可以仔细分析下对象之间的关系。就好像设计模式的名字桥接一样，这条引用的关系就是-桥,也体现了合成复用优先于继承的设计原则。

点评

代理模式其实就是在访问对象时引入一定程度的间接性，因为这种间接性，可以附加多种用途。

点评

在我看来适配器是一种很好的软件系统维护的补救措施。当我们开发了一套新系统，需要兼容老系统不是很快就能修改过来的功能，就可以先使用适配器来做个中间类隔离新系统和老系统的关联，而且很快就能投入使用。

点评

实现了一个克隆自身的接口，用来拷贝自己。在.net中已经存在这个接口ICloneable，实现它即可。