欢迎探讨设计模式

hoopoos

模式的数量取决于应用的范围和深度，系统越复杂可能会采用的模式更多，而且模式是可以嵌套可包含可交互的，例如模式的模式，总的来说就好像一部大机器由许多结构的设计组成，每个结构又包含若干更小的设计。

比如，最常见的一个场合，我们需要一个基本的实现，然后有很多它的变体，behavior大同小异的。最早的OOP是用抽象类加继承，现在呢慢慢的就转变成Factory，Builder，Strategy，Bridge这些模式合在一起完成这个设计。

tkl888

而且模式是可以嵌套可包含可交互的>>严重同意，这个是DP里最难的部分了。

tanliyoung

原帖由 hoopoos 于 6-10-2008 11:43 发表

                               
登录/注册后可看大图

呵呵，上两个月找工作的时候面试常常被问到设计模式，因为自己很熟悉，所以对答如流，感觉这里的analyst，programmer，develope之类的开发职位对设计模式还是很重视的。

看来需要比较扎实的OO知识了。

周星星1832

就知道一个MVC

woodheadz

"Refactoring to Pattern", 这句话非常关键。
我觉得在设计过程中，设计模式大多数时候都是被“发现”出来，而不是“应用”出来的。
就我的经验而言，符合基本设计原则的OO程序大多会含有一个或多个设计模式，这些模式是自然出现在设计中，再由设计者重构，将模式显性化和稳定化，以提高程序的可读性。同时重构到模式的过程也是对设计进一步优化的过程。
对于初学者来说，最忌讳的就是为模式而模式，造成过度设计。 还是应该专心将OO的设计原则学好理解透，在平时编码的时候专心思考如何让代码符合OO原则。设计模式嘛，可以视为让代码符合OO原则的指导手段，也可以视为和其它程序员交流的工具，千万不可将“应用设计模式”视为目标。
总之，要做好的OO程序员（C#,JAVA,C++..），关键是：
1.深刻理解OO基本设计原则，并尽量在实际编程时遵循之
2.要深刻理解到“过度设计”是有一定OO基础的程序员的最大的敌人
3.好好学习设计模式，并在第二条的基础上应用之

gdzack

原帖由 coredump 于 6-6-2008 23:23 发表

                               
登录/注册后可看大图

设计模式迷你手册，一起学习。LZ啥时候开讲？

啥都没有，不会让我看天书吧？

key

原帖由 iceman 于 14-6-2008 00:54 发表

                               
登录/注册后可看大图

2、 BUILDER-MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖）

建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。

上面的“我爱你”例子，我觉得似乎是在说Factory Method，而不是Builder。关于Builder，我觉得下图的例子会更合适。
Builder中的关键是那个Director类中direct的element与builder类中的类架构是很微妙的结合在一起。如果单看类框架，
可能看不出任何的东西，所以需要具体看direct()方法的逻辑关键。

如果把Builder和Factory类进行对比，可以看到，Factory能直接produce不同的products，这些product是直观的，
直接的。而builder则是对product的部件进行操作，由director通过direct()方法对部件进行装配；这个过程不是那么
直观。

key

原帖由 iceman 于 14-6-2008 00:54 发表

                               
登录/注册后可看大图

4、PROTOTYPE-跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你要不要）

原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。

Prototype的关键就在于clone()。但有一个问题，就是要分清prototype中变与不变两个部分。不变的东西就是原型中已经装置好的东西，
而变动的东西很可能是通过参数传入，又或者通过读取外部的环境数据获得。GoF中举的graphic例子，我觉得是很典型的实例：每个graphic
的外型是不变的，可以clone，而变化的是position。

使用Prototype，主要原因是生成的新对象中，不变的部分占很大的比例，而这部分的生成过程/装配过程相对复杂，所以就采用了原型。
如果只是一句肉麻的话，那就没有太大必要用prototype了。如果是大量肉麻的话，对于不同的场合copy不同的一句，那就不是prototype了。

Prototype是一个很数字化的概念，其clone方法似乎在数字世界以外很难找到类比；有时我们尝试找这样的类比，很可能得到的只是一个
工厂类，而不是真正的prototype。

key

原帖由 hoopoos 于 10-6-2008 13:47 发表

                               
登录/注册后可看大图

给一个例子，抛砖引玉吧

比如， Adapter，就是一个很简单，很常见的模式，一般来说，DP都是有现实生活例子的参照（比如head first design pattern里面大量的例子），Adapter在现实生活里面的例子就是电源插座转换 ...

我觉得Adaptor有广义与狭义之分。

广义的Adaptor就如hoo所述，只要需要转换其接口，使之能适应新的应用环境。
而狭义的Adaptor，我觉得则是有明确的Client, Target, Adapter, Adaptee四个元素构建的一种特别的模式。

Design Pattern的一个重要目标是提高代码的复用性。在Adapter这一章，GoF的一句话我觉得很有意义：
“不应该仅仅为了实现一个应用，工具箱就不得不采用一些与特定领域相关的接口”

为了提高代码的可重用性，我们往往提倡purify我们的类，使之功能更加单一、没有牵涉其他不必要的事情。
这样一来，purified的类的在某个特定的应用领域就会显得不适用。于是Adapter模式就应运而生。

从这个角度来看，在一个特定的应用领域进行编程的时候，一方面根据这个领域的实际需要建立其特定的类hierarchy，
而另一方面，当某个类可以从通用领域/别的领域，接到合适的复用目标时，就可以考虑采用Adapter进行适配。
所以Target在这里很重要，GoF提倡Adapter是从Target上继承，而结合Adaptee。而hoo在举例时提出电源插座
转换器这个东西，个人觉得不是Adapter的一个好的例子，因为没有突出Target。

如果一定要给电源适配器按一个Design Pattern的名字，我觉得proxy会更合适。不知道hoo同不同意？使用了proxy
模式后，我们会看到，三个不同的接口分别指向了对应的插座接口，进行了代理。

[ 本帖最后由 key 于 1-5-2009 11:02 编辑 ]

key

原帖由 black_zerg 于 10-1-2009 18:39 发表

                               
登录/注册后可看大图

说实话那些模式太多，有点吓人，我觉得来个四五个也就差不多了，顶多再补个四五个不常用的，10个，10个撑死。怎么会搞出那么多来，bridge什么的就看着很晕菜。

bridge的关键应该在于Impl与对象的表现/逻辑部分进行分离，型成了两个不同的进化路径。GoF采用了Bridge这个名称我觉得非常的不好，
很多人晕的原因可能不在于pattern本身，而在于bridge这个词。

而之所以叫做bridge，我认为不是从内涵而言，而是从pattern的外型而言。因为从Class Diagram来看，bridge模式采用了一个象高架桥这样的图例，除了最上面的桥相连接
之外，没有其他的关联点。而偏偏对于参与bridge两边的类来说，都有着高高的hierarchy。

key

原帖由 hoopoos 于 10-6-2008 19:30 发表

                               
登录/注册后可看大图

既然有人支持，就斗胆再写一段，说说decorator

decorator，顾名思义就是装饰，通常给一间空白的房子，先刷一层漆，然后装上地毯窗帘，再搞上一些灯，最后放进去家具，弄点鲜花玩具，这样一层层的装饰，就不断完善 ...

hoo对于decorator的解释消除了我不少误解，谢谢！

我觉得在GoF的书中，关于decorator与composite的区分说得很不错，虽然只有一句话，但很到位。

1. decorator可以看做一个composite，但简化了。这样看的原因是，一个加了装饰的物件还是一个物件；
而decorator采用组合的方式，把原来的物体放入其中。
2. decorator没有add()/remove()等接口，这使它成为一个功能不完全的composite
3. decorator的设计目标是为了改变类的外部表现，这个外部表现包括了输入和输出的表现，比如在输出时
加入色彩渲染，数据压缩、编码，而在输入时去掉一些信息，对数据进行解压缩、解码，等

GoF说decorator的一个别名是wrapper，结果大家都看Adapter去了；事实上我觉得decorator的别名为管道会更合适。
因为decorator这个词本身就让人想到输出的渲染，而pipe或管道则让人想到输入的reshape

black_zerg

原来bridge这名字感情是个象形名，这么多年总算明白了，哭了。

klux

设计模式就像武功招数，初学呢是要学点套路，跟着一步一步来
但是打架的时候如果还是按照套路，生搬硬套，那就有点迂腐了
无招胜有招才是最终境界

valpa

原帖由 hoopoos 于 6-6-2008 19:15 发表

                               
登录/注册后可看大图

我在公司做过一些设计模式的培训，也读过一些设计模式的书，产品实践里面也大量运用了设计模式，愿意和大家探讨，不了解设计模式的，也欢迎提问。

太需要了
正好为理解公司代码的设计模式发愁呢。而公司同事之间几乎都埋头干活，没有时间pure学习的

valpa

hoopoos兄？不上线了么？

felix100

原帖由 iceman 于 14-6-2008 01:54 发表

                               
登录/注册后可看大图

设计模式一直是我的爱好，可惜我没太多的实践经验，向各位前辈多学习了。。。。
搞个设计模式的搞笑版，大家一起FUN一下。。。。
创建型模式
2、 BUILDER-MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖）

建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。

我觉得builder应该是这样的，翻译机上有很多语言选择按钮，只有一个“我爱你“按钮。要翻译机讲我爱你之前，先选择一种语言，过后按“我爱你“按钮，翻译机就可以从语言库中分别找出“我“，“爱”，“你“，或“I","Love", "you"，并且安装正确的顺序读出来。

earthengine

注意：以下内容为本人原创，首发本论坛。这不是论文，只是一个简介，希望抛砖引玉。

设计模式：Parser （处理器）
目的：经常遇到的一种情况是，程序需要根据成文的协议进行处理。协议会规定各种封包或者对象的格式，然后程序需要根据接收到的数据生成相应的对象。这时候，我们可能需要一种灵活的方式以便适应对协议的修改。

实现：通过组合一些经典的设计模式，可以设计一种非常灵活的方式来实现以上功能。首先，Factory Method可以用以最终生成对象。其次，由于封包类型可能是递归的（即一个特定的包类型可以递归地包含自己），那么可以选择使用Composit来表达这种递归关系，这样很方便对生成的对象进行后续处理。然后，关键的一点是，每种对象必须负责自己的生成，这可以使用Responsibility Chain来实现。整体上，这种根据数据生成对象的方法可以看作是Interpretor的实例。

例子：在本人做的一个项目里，利用本模式实现了对电子邮件的处理。