设计模式总结

最近准备换个工作，看招聘信息上有的需要熟悉设计模式，这几天晚上又顺便看了一下，在这里写一下我的理解。因为网上相关内容很多，这里就不写具体算法，只大致总结一下各个设计模式的用途。
我们知道，设计模式分为创建型、结构型、行为型三类，直接说可能有一些抽象，我们从日常生活的角度来看一下设计模式，我以我们大部分男生都喜欢的打篮球为例来说，创建型就是我们准备的装备，结构型就是我们大家的能力和关系，行为型就是我们如何比赛。
--------------以下为创建型模式-----------------------------------------------
今天天气很好，大家准备下午打球，我要去打篮球，但是我什么都没有，所以我准备采购一下装备。
首先我要买篮球鞋，于是我找到一家鞋店进去，说我想要双某某型号的鞋，然后它就给我拿了过来。这就是工厂方法模式（factory method），我告诉鞋店我要什么鞋，然后它就给我，这双鞋背后的生产就是工厂（一个工厂可以产生同一系列的产品）。
但是问题来了，我还要球衣，篮球等等打篮球需要的东西，我总不能一样一样自己去找店家吧，还好有体育用品店，我在一个店里面就找到了所有我要的东西。这个就是抽象工厂模式（abstract factory），我告诉它我要篮球，它拿给我篮球，我要球衣，它给我球衣（一个工厂可以产生多个系列的产品）。
体育用品店也要找一个好的，这样质量才有保证，于是，我找了一个某一牌子的体育用品店去买，这就是单例模式（singleton），因为无论你去哪一个门店，只要是这个牌子的，它的产品都是同一个工厂生产的（保证系统中只有一个实例）。
嗯，基本东西买好了，但是因为很多不同样式的装备我都喜欢所以都买了，到底穿那几件出去又是一件纠结的事情，选了半天，才决定就穿蓝色的鞋、白色球衣、戴个黄色护腕，准备出发。这里用到的就是建造者模式（builder），选鞋，选球衣，选护腕，完整的搭配出一身的穿着（根据需要进行创建复杂对象）。
整理完毕，出发，到了场地一哥们看我衣服不错，问我在哪买的，结果几天后再次打球时就发现他也穿了和我上次相同款式的一套，只是颜色不同。这就是原型模式（prototype），通过“克隆”我的穿着，换了个颜色，就成为新的一套（对原有对象进行复制克隆，生成新的相似对象）。
-----------------以下为结构型模式-----------------------------------------------------
言归正传，人集合好之后准备打球，这里先介绍一下打球的人们。
我，司职控球后卫，同时偶尔打打得分后卫。我就是一个适配器模式（adapter），我自己是控球后卫，同时适配得分后卫（这个例子可能不太合适，简单说就是封装一个或多个对象或行为使其成为一个我们期望的对象）。
小三，小前锋，这小子最喜欢带一些稀奇古怪的东西了。他就是一个装饰模式（decorator）（动态增加新的功能）。
小四，司职大前锋，他前几天崴脚了，还没完全好，结果我们就找了另外小五来打大前锋，由于他第一次跟我们打球，小四告诉了他我们一般如何配合，由他来代理小四打球，并按照小四的意愿打球，当然他也有自己的打球方式。小五就是代理模式（proxy），由他来代理小四打球，并加入了自己的打球方式（调用原有方法，并进行控制）。
这里插一句，装饰模式和代理模式很类似，区别是装饰模式只能添加行为而没有控制权，简单来说它只能加东西而不能改变被装饰对象的行为，代理模式则可以控制被代理对象的访问。
小六，司职中锋，我们这群人中最活跃的家伙，我们打球都是他召集的。平时如果想打球，就给他打电话，他就会找我们这一票人出来一起玩。小六就是外观模式（facade），通过他来联系我们去打篮球（将一系列对象通过外观模式对象进行统一管理）。
同样的，小六交友广泛，隔一段时间也会找其他的人和我们来一场友谊赛，我们只知道要打比赛，具体对手是谁，就不知道了。这里小六就是桥接模式（bridge），我们只知道要打比赛，对手是谁就看小六找的人了（抽象化和实现化解耦，具体到这里就是我们知道有对手（抽象），而具体对手（实现）由小六（桥）确定）。
我们大家都是通过业余篮球爱好认识的，比不上人家专业队伍，有什么教练、一队、二队、队长、队员的称号，当然我们也不想有这些称号，感觉就不是纯粹的玩乐了。这里专业队伍的组成就是组合模式（composite），整个队伍有教练，教练下面有一队二队的队长、队长下面又有队员等（实现部分整体关系）。
我们这边有三个篮球场，每次来的时候看哪个场地没人就去哪个场地，当然，如果我们能够自创篮球场的话就更好了。篮球场就是享元模式（flyweight），场地是我们共享的（实现对象共享）。
------------以下为行为型模式-----------------------------------------------------------
下面说一说我们打球的时候的事情。
因为我们大家长时间一起打球，我们培养了很好的默契，这样我们也有了一些简单的战术。这里这些简单的战术就是策略模式（strategy），我们根据需要就可以选择相应的来完成（封装每个战术，根据需要调用）。
当然，有一些比较复杂的战术我们也采取一些方式也能打出来，比如我们规定了这些战术中的一些细节，但是还有一部分通过在比赛的时候根据情况不同采取不同的打法。这个复杂的战术就是模板方法模式（template method），我们规定了战术的一部分，但是其他部分根据情况采取不同的实现（封装一个战术的实现部分，其它未实现部分不同的继承者有不同的实现）。
我们比赛中的灵魂人物自然就是控卫，他会根据场上的形式打出不同的手势或者动作，我们就会根据这些手势和动作来采取不同的进攻方式。这里我们就是观察者模式（observer）。控卫手势或动作变化时，我们就会随之变化（对象变化时，依赖本对象的其它对象都随之变化）。
我们偶尔会聚到一起，然后根据我们总结的战术一个一个的分析什么时候会用到它，有时是看小六的那个战术小本子，有时是看电脑上的资料。这里就是迭代器模式（iterator），一个一个的看这些战术，但我们只关心战术，而不关心从本子上还是电脑上看这些战术（不暴露对象具体内部实现的情况下顺序访问每个元素）。
有时我们打球会遇到那些高个子，这时，我们就会不停的快速传球，当有人有好的机会时就投篮，没有的话就快速传球。这里就是责任链模式（chain of responsibility），如果自己不能解决，就传给下一个（请求在对象之间传递而不确定由哪个对象处理）。
我们比赛的间隙都后聚到一起，拿个小黑板写写画画一些战术，以便之后能够更好的打好比赛。这个就是命令模式（command），把命令（战术）“封装”到黑板，交给比赛的人执行（请求和实现解耦）。
我们在每场比赛后都会进行一下简单的总结，看看自己有什么地方需要改进的，有时我们也会对自己总结的战术进行修改，但是这个修改可能也不一定合适，所以，我们都会根据修改日期来进行备份，这样，我们如果感觉现在的不太合适，就把原来的拿过来用。这个就是备忘录模式（memento），备份信息且备份信息不能修改（实现备份和恢复）。
我们在比赛的时候难免会因为身体的状态而影响发挥。例如昨晚没睡好，精神就不集中，这样就很难有比较好的命中率，更比如崴脚了就连比赛都不能打了。这个就是状态模式（state），状态改变（崴脚），行为也改变（不能比赛而下场）（状态改变则行为改变）。
我们知道，篮球只有五个位置，我们根据这五个位置有着各种各样的战术安排，这个就是访问者模式（visitor），数据结构（位置）不变，行为（战术）改变（数据结构与在此结构上的操作解耦）。
篮球的很多战术的发动点是控卫，他会协调场上队友的大部分跑位配合，这样就避免了大家相互关注对方而分散注意力进而造成战术没办法发挥作用。这个就是中介者模式（mediator），控卫充当中介，协调队友的配合（由中介者协调不同对象之间的交互行为）。
很多复杂的战术，我们需要有专门研究一下这个战术，然后让他给我们详细讲解具体过程，这个就是解释器模式（interpreter），研究战术的人充当解释器，将战术分析成我们能够理解的方式（定义某种文法，并根据文法解释某种语言或行为）。
--------------------------------------------------------------------------
这里只是一些个人看后的简单总结，有些可能比较片面，并且也有可能出现错误的地方，欢迎大家给予指正。

评论

2 楼 风云无浪 2014-05-06  

我觉得这种总结对于学习来说没啥意义，该不会还是不会。对于了解设计模式的人来说，就是笑一笑

1 楼 灵动的水 2014-05-06  

挺生动的，抽象的概念通过日常生活比喻的讲解。
这样理解更深刻了。这种解释也可以当作一种写程序的过程。
概念是从具体到抽象，写程序是从抽象到具体。