I、创建型模式
1、ABSTRACT FACTORY
球场作为一个抽象工厂，可以举办球赛（产品）。法兰克福球场作为一个具体工厂，生产 具体的产品（例如巴西对法国的比赛）。你可以直接说到球场看比赛，到底是什么比赛由具体球场产生，比如盖尔森基兴球场（另一个具体工厂）就产生了英格兰对 葡萄牙的比赛。当某个具体工厂的产品发生改变的时候（比如柏林球场原来生产德国对阿根廷的比赛，后来生产XX对YY的决赛），对其他部分没有影响。你说话 也省了很多事儿，“到球场看比赛”，多么统一。球场还可以生产演唱会呢，球赛，演唱会这都是抽象产品，嗯，不多说了。
抽象工厂模式：提供一个创建一系列相关或互相依赖的对象的接口，而无须指定其具体的类。
点评：这个故事有些意思，但不是很好和编程的DP结合在一起。将实际生活例子套用到OO中，一个不协调点就是，OO中的对象应该是具有主动性的，自我负责的。这种意义上，”球场“的现实含义是不适当的。
我 的例子：假设你是一名教练，你的队伍缺少一名前锋。你找来一个经纪人，让他找一个，不管是肥罗，还是鲁尼，你都不关心，只要能满足前锋的要求就可以了。这 个经纪人的职责就是一个抽象工厂，目的是根据一个抽象类，产生一个特定对象。你也可以对经纪人提出附加要求，比如“长的要吸引眼球”，这就是对工厂的要求 参数了，已经有些变形了。
2、BUILDER
看完比赛有很多感想，兼有对两队的正面评价和负面评价，这时你的大脑就是个 builder，见到英格兰球迷的时候实例化为EnglandBuilder，拿出对英格兰的正面评价和对葡萄牙的负面评价，具体可能是“红牌不公平”之 类的，见到没有倾向的人，有可能实例化为CommonBuilder，把所有评价都表示出来。
建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。
点评：说实话，没看懂这个例子在说什么。
我 的例子：延续上面的例子，这次假设你是一个俱乐部经理，你要打造一只“百年俱乐部”，要组建足球队。你找来一个教练，把这个任务交给他。这次需要他至少寻 找10个会踢球的，还有一个会守门的，以及队医、后勤、等等。至于这10个人怎么配合，是352，还是442，都不是你要管的。我们看到，这是在执行个大 规模的Build过程，而过程的细节不是客户（也就是你，一个经理）所不关心的。你只关心成绩。
II、结构型模式
3、ADAPTER
看球的时候旁边竟然是个帅哥！可是他不懂你的中文，你也不懂它的德语，恰好你的朋友熟练掌握这两门语言，于是这朋友就作为你和帅哥之间的Adapter，让你们相互交流。
适配器模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。
点评：翻译是一种Adapter，但一般的Adapter没有这个复杂的功能，只有有限的接口，并将功能转发出去。
我 的例子：这次你还是作为一名教练出现在比赛场上。不幸的是，你是一名中国队的中国教练。你在场边大喊大叫，命令队员“全力进攻”，“注意防守”，“保持队 形”等等。你的命令接口是汉语，场上的队员也使用这个接口。有一天，齐达内加入了你的队伍，他听不懂汉语，也就是你们之间的接口不兼容了。于是你找来一个 法语翻译。这次，你喊“全力进攻”，实际上是对场上的10名队员加上一个翻译发布的。翻译再喊叫对应的法语，其实他也不知道如何进攻。他只是一个 Adapter。
4、BRIDGE
把球作为足球、排球、篮球的抽象，当球又有一个子类“艺术球（风格方面）”的时候，就得分别搞 出艺术足球，艺术排球，艺术篮球。增加乒乓球后，也要在“艺术球”里增加相应的艺术乒乓球。所以把一个类层次专用于接口，分出篮球足球等，另设一个独立的 类层次针对实现部分，艺术球啊实用球啊什么的，这样两方面的改变都灵活多了。
桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。
点评：想法对头，可是“艺术”似乎不是一种实现。呵呵
我 的例子：还是拿球来说事。我们知道这次世界杯的足球制品引起一些争议，这就是一种实现。将球类按照功能分类为大球、小球，然后是足球、篮球、乒乓球、羽毛 球（这个似乎不太像球）等等。然后我们会找不同的公司生产，以及不同的品种。我们一般不会将这两种分类联合使用，非要举办一场“阿迪达斯”的世界杯。相 反，这作为一种实现隐藏在世界杯的画面中。
5、COMPOSITE
闲暇时你打算买点儿纪念品回来散给亲朋好友。送某一套钥匙链，送某某一只国家瓶……送我一个大包，里面有一套钥匙链，一套国家瓶，徵标瓶，庆典瓶，符号瓶……哈哈，恭喜你，学会Composite模式了！
合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。
点评：例子很好。这里面要强调的是，一个钥匙链是礼物，一个大礼包也是礼物。至于给朋友什么东西要看对象（又是对象）了。理解了这一点，就真正理解COMPOSITE了。
6、FACADE
看球的时候也拍些照片吧，近处的帅哥美女，远处的球场，可是你不会调光圈啊什么的，没关系，有自动模式呢，只要对准目标按快门就行了，一切由相机自动调整。
门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。
点评：不错的例子。一个误区是Facade是为对象提供一致的接口，这是不对的。Facade强调一个简明的接口，就像傻瓜相机一样，但不排斥更高级的操作。如果你对相机理解程度足够深，傻瓜相机也可以专业化操作。不过这个FACADE我一般翻译为装饰模式
7、PROXY
陌生人来搭讪，总是那几个问题，你支持哪个球队？你来自哪里？很无聊，不如写个程序做为你的Proxy吧，凡是接收到这些话都按照设置自动回答，接收到其他的新鲜话时再通知你。
代 理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况 下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并 不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须有系统的其他角色代为创建并传入。
点评：故事不错，不过还要推敲。
III、行为模式
8、COMMAND
组织大家在看台上摆出国旗的样子，听到“举布条”的指令（Command），有的举白的，有的举蓝的，有的举红的（各种具体的Command，它们分别对应着特定的对象）。
命 令模式：命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发 送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。系统支 持命令的撤消。
点评：这个例子似乎不是Command模式，而是虚函数。
我的例子：还是延续上面的例子，你作为一个教练 出现在比赛场边。你在大喊大叫，发布一系列命令。作为场上的球队这一个整体，并不是同步地执行你的命令的。他们会把命令记载下来，有些命令会即时执行，比 如让谁谁罚点球；有些是要通过球队内部的一个复杂过程来完成的，比如“加强进攻”；有些命令可能会被忽略；还有些会被撤销。
我觉得Command模式的一个精髓在于将同步模式转为异步的。当然，命令接口抽象化也是一个特点。
9、OBSERVER
有一个消息发布栏，每次有人去发布或更改内容的时候，发布栏主人会通知大家前去收看，而不直接告诉你到底发生了哪些改动。
观察者模式：观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。
点评：可是你说的是哪种发布栏呢？像新浪的网站就不是这种模式。Observer模式的精髓在于订阅和通知，RSS算一种。
我 的例子：传统的媒体发布需要我们自己关注，因此不是Observer模式。只有那些实现“push”功能的才是。比如我们比较深恶痛绝的各种短信。当你傻 傻地定制了一个世界杯短信，你就是一个Observer了。当比赛结果出来之后，会有一条短信告诉你，法国1：0胜葡萄牙，想了解细节么，你还是要上网， 也就是还要从被观察对象中取信息。当然这条短信是要收费的，而且不在乎你是否关注这个具体通知，只要你订阅过，好处在于你不用一直刷新网站等待结果。
10、STRATEGY
跟不同的队伍比赛，排兵布阵策略不同。有的要着重进攻，有的则回缩防守，有的给裁判塞点儿钱^^……Strategy就负责根据情况灵活选择不同的策略。
策 略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下 发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由于算法和环境独立开来，算法的增减，修改都不会影响 到环境和客户端。
点评：策略模式将算法封装起来，实际中很难找出非常贴切的例子。这个故事也还可以。
上面是对 sunnier的一些故事的点评，还有一些模式，如：Factory Method；Prototype；Singleton；Decorator；Chain of responsibility；Iterator；Mediator；State；Visitor；她没有提到，以后有时间再补充
1、ABSTRACT FACTORY
球场作为一个抽象工厂，可以举办球赛（产品）。法兰克福球场作为一个具体工厂，生产 具体的产品（例如巴西对法国的比赛）。你可以直接说到球场看比赛，到底是什么比赛由具体球场产生，比如盖尔森基兴球场（另一个具体工厂）就产生了英格兰对 葡萄牙的比赛。当某个具体工厂的产品发生改变的时候（比如柏林球场原来生产德国对阿根廷的比赛，后来生产XX对YY的决赛），对其他部分没有影响。你说话 也省了很多事儿，“到球场看比赛”，多么统一。球场还可以生产演唱会呢，球赛，演唱会这都是抽象产品，嗯，不多说了。
抽象工厂模式：提供一个创建一系列相关或互相依赖的对象的接口，而无须指定其具体的类。
点评：这个故事有些意思，但不是很好和编程的DP结合在一起。将实际生活例子套用到OO中，一个不协调点就是，OO中的对象应该是具有主动性的，自我负责的。这种意义上，”球场“的现实含义是不适当的。
我 的例子：假设你是一名教练，你的队伍缺少一名前锋。你找来一个经纪人，让他找一个，不管是肥罗，还是鲁尼，你都不关心，只要能满足前锋的要求就可以了。这 个经纪人的职责就是一个抽象工厂，目的是根据一个抽象类，产生一个特定对象。你也可以对经纪人提出附加要求，比如“长的要吸引眼球”，这就是对工厂的要求 参数了，已经有些变形了。
2、BUILDER
看完比赛有很多感想，兼有对两队的正面评价和负面评价，这时你的大脑就是个 builder，见到英格兰球迷的时候实例化为EnglandBuilder，拿出对英格兰的正面评价和对葡萄牙的负面评价，具体可能是“红牌不公平”之 类的，见到没有倾向的人，有可能实例化为CommonBuilder，把所有评价都表示出来。
建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。
点评：说实话，没看懂这个例子在说什么。
我 的例子：延续上面的例子，这次假设你是一个俱乐部经理，你要打造一只“百年俱乐部”，要组建足球队。你找来一个教练，把这个任务交给他。这次需要他至少寻 找10个会踢球的，还有一个会守门的，以及队医、后勤、等等。至于这10个人怎么配合，是352，还是442，都不是你要管的。我们看到，这是在执行个大 规模的Build过程，而过程的细节不是客户（也就是你，一个经理）所不关心的。你只关心成绩。
II、结构型模式
3、ADAPTER
看球的时候旁边竟然是个帅哥！可是他不懂你的中文，你也不懂它的德语，恰好你的朋友熟练掌握这两门语言，于是这朋友就作为你和帅哥之间的Adapter，让你们相互交流。
适配器模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。
点评：翻译是一种Adapter，但一般的Adapter没有这个复杂的功能，只有有限的接口，并将功能转发出去。
我 的例子：这次你还是作为一名教练出现在比赛场上。不幸的是，你是一名中国队的中国教练。你在场边大喊大叫，命令队员“全力进攻”，“注意防守”，“保持队 形”等等。你的命令接口是汉语，场上的队员也使用这个接口。有一天，齐达内加入了你的队伍，他听不懂汉语，也就是你们之间的接口不兼容了。于是你找来一个 法语翻译。这次，你喊“全力进攻”，实际上是对场上的10名队员加上一个翻译发布的。翻译再喊叫对应的法语，其实他也不知道如何进攻。他只是一个 Adapter。
4、BRIDGE
把球作为足球、排球、篮球的抽象，当球又有一个子类“艺术球（风格方面）”的时候，就得分别搞 出艺术足球，艺术排球，艺术篮球。增加乒乓球后，也要在“艺术球”里增加相应的艺术乒乓球。所以把一个类层次专用于接口，分出篮球足球等，另设一个独立的 类层次针对实现部分，艺术球啊实用球啊什么的，这样两方面的改变都灵活多了。
桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。
点评：想法对头，可是“艺术”似乎不是一种实现。呵呵
我 的例子：还是拿球来说事。我们知道这次世界杯的足球制品引起一些争议，这就是一种实现。将球类按照功能分类为大球、小球，然后是足球、篮球、乒乓球、羽毛 球（这个似乎不太像球）等等。然后我们会找不同的公司生产，以及不同的品种。我们一般不会将这两种分类联合使用，非要举办一场“阿迪达斯”的世界杯。相 反，这作为一种实现隐藏在世界杯的画面中。
5、COMPOSITE
闲暇时你打算买点儿纪念品回来散给亲朋好友。送某一套钥匙链，送某某一只国家瓶……送我一个大包，里面有一套钥匙链，一套国家瓶，徵标瓶，庆典瓶，符号瓶……哈哈，恭喜你，学会Composite模式了！
合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。
点评：例子很好。这里面要强调的是，一个钥匙链是礼物，一个大礼包也是礼物。至于给朋友什么东西要看对象（又是对象）了。理解了这一点，就真正理解COMPOSITE了。
6、FACADE
看球的时候也拍些照片吧，近处的帅哥美女，远处的球场，可是你不会调光圈啊什么的，没关系，有自动模式呢，只要对准目标按快门就行了，一切由相机自动调整。
门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。
点评：不错的例子。一个误区是Facade是为对象提供一致的接口，这是不对的。Facade强调一个简明的接口，就像傻瓜相机一样，但不排斥更高级的操作。如果你对相机理解程度足够深，傻瓜相机也可以专业化操作。不过这个FACADE我一般翻译为装饰模式
7、PROXY
陌生人来搭讪，总是那几个问题，你支持哪个球队？你来自哪里？很无聊，不如写个程序做为你的Proxy吧，凡是接收到这些话都按照设置自动回答，接收到其他的新鲜话时再通知你。
代 理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况 下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并 不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须有系统的其他角色代为创建并传入。
点评：故事不错，不过还要推敲。
III、行为模式
8、COMMAND
组织大家在看台上摆出国旗的样子，听到“举布条”的指令（Command），有的举白的，有的举蓝的，有的举红的（各种具体的Command，它们分别对应着特定的对象）。
命 令模式：命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发 送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。系统支 持命令的撤消。
点评：这个例子似乎不是Command模式，而是虚函数。
我的例子：还是延续上面的例子，你作为一个教练 出现在比赛场边。你在大喊大叫，发布一系列命令。作为场上的球队这一个整体，并不是同步地执行你的命令的。他们会把命令记载下来，有些命令会即时执行，比 如让谁谁罚点球；有些是要通过球队内部的一个复杂过程来完成的，比如“加强进攻”；有些命令可能会被忽略；还有些会被撤销。
我觉得Command模式的一个精髓在于将同步模式转为异步的。当然，命令接口抽象化也是一个特点。
9、OBSERVER
有一个消息发布栏，每次有人去发布或更改内容的时候，发布栏主人会通知大家前去收看，而不直接告诉你到底发生了哪些改动。
观察者模式：观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。
点评：可是你说的是哪种发布栏呢？像新浪的网站就不是这种模式。Observer模式的精髓在于订阅和通知，RSS算一种。
我 的例子：传统的媒体发布需要我们自己关注，因此不是Observer模式。只有那些实现“push”功能的才是。比如我们比较深恶痛绝的各种短信。当你傻 傻地定制了一个世界杯短信，你就是一个Observer了。当比赛结果出来之后，会有一条短信告诉你，法国1：0胜葡萄牙，想了解细节么，你还是要上网， 也就是还要从被观察对象中取信息。当然这条短信是要收费的，而且不在乎你是否关注这个具体通知，只要你订阅过，好处在于你不用一直刷新网站等待结果。
10、STRATEGY
跟不同的队伍比赛，排兵布阵策略不同。有的要着重进攻，有的则回缩防守，有的给裁判塞点儿钱^^……Strategy就负责根据情况灵活选择不同的策略。
策 略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下 发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由于算法和环境独立开来，算法的增减，修改都不会影响 到环境和客户端。
点评：策略模式将算法封装起来，实际中很难找出非常贴切的例子。这个故事也还可以。
上面是对 sunnier的一些故事的点评，还有一些模式，如：Factory Method；Prototype；Singleton；Decorator；Chain of responsibility；Iterator；Mediator；State；Visitor；她没有提到，以后有时间再补充
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
