FreeOZ论坛

标题: 欢迎探讨设计模式 [打印本页]

作者: hoopoos 时间: 6-6-2008 19:15
标题: 欢迎探讨设计模式
我在公司做过一些设计模式的培训，也读过一些设计模式的书，产品实践里面也大量运用了设计模式，愿意和大家探讨，不了解设计模式的，也欢迎提问。

作者: coredump 时间: 6-6-2008 19:41
标题: 回复 #1 hoopoos 的帖子

作者: goldensun 时间: 6-6-2008 19:49
你介绍具体点吧
我都不知道什么叫设计模式,无从问起

作者: 空明七心 时间: 6-6-2008 22:11
Design Pattern? Cool! Teach me from beginning!

[ 本帖最后由空明七心于 6-6-2008 22:41 编辑 ]

作者: coredump 时间: 6-6-2008 22:23
设计模式迷你手册，一起学习。LZ啥时候开讲？

作者: hoopoos 时间: 10-6-2008 11:08
如果对DP一无所知，建议先读一些书，比较好，因为内容太多也不是很直观，而且不适合bbs里面这样快速简略的学习。

大多数知识都是可以自学的，然后带着问题和别人一起探讨更有效果，特别是有了一些自己的实践后学习的效果更好。

我自己做了一套DP的PPT，结合了我们自己公司产品的实际例子，但是因为涉及版权，所以不方便公开，网上应该有其他的open的材料，比如楼上贴的。

作者: langchu 时间: 10-6-2008 12:54
标题: 回复 #6 hoopoos 的帖子
DP还是得有实际应用理解才有效果，偶现在干的活根本都没应用，学都没法弄

作者: hoopoos 时间: 10-6-2008 13:47
给一个例子，抛砖引玉吧

比如， Adapter，就是一个很简单，很常见的模式，一般来说，DP都是有现实生活例子的参照（比如head first design pattern里面大量的例子），Adapter在现实生活里面的例子就是电源插座转换头，比如我们的笔记本插头是3脚的，来到英国，都是大的方头插座，用不了，那么，我们用一个Adapter，一头是英式的方脚插头，一头是美式的插座，我们把笔记本插头插进Adapter，然后把Adapter的插头插进插座就能用了。

在软件开发里面，如果有个外部程序要求我们提供一个API，参数是指定的，我们发现之前有个类似的API能完成同样的任务，但是参数格式不一样，那么我们要做的就是写一个Adapter

例如：我们现在需要提供的是 public externalMethod(int i)，我们已经有的是public internalMethod(String s)，现在我们要做的是写一个Adapter

// interface required by third party
public interface ExternalInterface
{
  public void externalMethod(int i);
}

//interface we already have
public interface internalInterface
{
  public void internalMethod(String s);
}

//adapter  class we are implementing
public class Adapter implements ExternalInterface
{
   private InternalInterface fooImpl;
   public void setAdapterImpl(InternalInterface  i)
   {
      this.fooImpl=i;
   }

// adapting....
   public void externalMethod(int i)
   {
      fooImpl.internalMethod(String.parseInt(i));
   }
}

在上面这个例子里面，我用了composite一个现有method实现类的方式，来做adapt这件事情，这叫做object adapter，同样，我可以采用inheritant现有实现类的方式来做。不过，一般来说，在同样的情况下，我们推荐composite而不是inheritance。

作者: shenlh 时间: 10-6-2008 16:09
标题: 严重支持
欢迎详细资料，因为dp只在我心里，我从来不在我的设计文档里面体现这些。希望多位高手多指教。

看来楼主是Java Specialist

作者: langchu 时间: 10-6-2008 18:48
标题: 回复 #9 shenlh 的帖子
这不明摆着嘛，看看lz的头就很清楚了

作者: hoopoos 时间: 10-6-2008 19:30
既然有人支持，就斗胆再写一段，说说decorator

decorator，顾名思义就是装饰，通常给一间空白的房子，先刷一层漆，然后装上地毯窗帘，再搞上一些灯，最后放进去家具，弄点鲜花玩具，这样一层层的装饰，就不断完善了这个房子，让它从空荡荡的，变成功能齐全，富有生活情趣的一个居所。

在软件开发里，我们常常要扩展一个类的功能，有时候我们直接修改这个类，增加方法和属性，这是比较直接的做法，但是，这样做可能会破坏原来类的功能引入新的bug，为了保证不影响原来类的功能，我们采用这样的方式来扩展它

public abstract class Decorator
{
   public abstract Decorator(Decorator base);
   public void work()
   {
   //put some basic operation here
   }
}

public class CurtainDecorator extends Decorator
{
private Decorator base;
public CurtainDecorator (Decorator ba)
{
   this.base=ba;
}
   public void work()
   {
   //decorating on existing class
   this.base.work();
   //additional code put here
   System.out.println("i'm decorating the house with curtains!");
   }
}

扩展了若干个decorator后（有些负责加布艺，有些负责加灯具），我们可以这样的方式来实现装饰的过程：

Decorator decorator=new LampDecorator(new CurtainDecorator (new PaintDecorator ()));
decorator.work();

从上面的代码可以看出，先装饰油漆，再装饰窗帘，最后装饰灯。显然，这个顺序也是可以调整的，每个decorator之间是独立的。

decorator最典型的例子就是io input output streams，具体可以参考thinking in java。

[ 本帖最后由 hoopoos 于 10-6-2008 19:32 编辑 ]

作者: coredump 时间: 10-6-2008 19:47
好的很，等有版主的就建议加精。楼主把经典23模式统统给大家讲一遍吧。如果有现有软件的经典用例则更精彩

作者: MSPro 时间: 11-6-2008 00:01
能不能讲一下用 ASP.Net 框架如何实现MVC？

作者: hoopoos 时间: 11-6-2008 11:02

原帖由 MSPro 于 11-6-2008 00:01 发表

 登录/注册后可看大图

能不能讲一下用 ASP.Net 框架如何实现MVC？

我大概有很多年没有接触MS的开发框架，不过，一般来说OO的系统都是差不多的，首先要做的就是把一个表现层（presentation tier）的view, controller, model很好的分割开来。

举个例子，如果我们有个简单的登陆模块，有三个page: login, login_success, login_failed.那么，我们可以有3个view，1个controller，1个model。按照activity flow，第一个page是login，让你输入账号登陆，view上显示的是输入框，提交按钮，他的动作提交到controller，controller获取model对应的账号数据（可能是数据库的一条记录），然后controller根据查询是否匹配，跳转到login_success或者login_failed。

作者: beysup 时间: 12-6-2008 13:53
dp其实就是polymorphism的延伸，我做pm的时候尝试用了几个，还好

作者: iceman 时间: 14-6-2008 00:54
设计模式一直是我的爱好，可惜我没太多的实践经验，向各位前辈多学习了。。。。
搞个设计模式的搞笑版，大家一起FUN一下。。。。
创建型模式
1、FACTORY-追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory

工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。

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

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

3、FACTORY METHOD-请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。

工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。

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

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

5、SINGLETON-俺有6个漂亮的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，她们只要说道“老公”，都是指的同一个人，那就是我(刚才做了个梦啦，哪有这么好的事)

单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。

作者: uniwg 时间: 15-9-2008 12:23
有关DP，我在看的书是JAVA DESIGN PATTERNS A TUTORIAL，作者　JAMES W. COPER，有其他朋友推荐一些好书吧，英文的。顺便问楼主，现在的JAVA　开源的一些项目，比如Structs,AJAX,hibernate,看的人眼花缭乱，都不知道外面是否在用。

[ 本帖最后由 uniwg 于 15-9-2008 12:41 编辑 ]

作者: media000 时间: 15-9-2008 18:09
欢迎LZ继续讲课

作者: hoopoos 时间: 15-9-2008 18:44
标题: 回复 #17 uniwg 的帖子
struts, hibernate用的还是很多的，尤其是hibernate。ajax很新鲜很管用，但是就那么点东西，并且浏览器支持有限。

越是这些流行的framework，越是能在里面发现大量模式的运用。

作者: 春天来了 时间: 24-9-2008 16:47
跟着学习了！

作者: wanjx 时间: 6-10-2008 01:02
终于看到熟悉的东西了，以后要多向楼主学习。。。。。

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

作者: coredump 时间: 6-10-2008 17:28
标题: 回复 #22 hoopoos 的帖子
再恭喜一下

再问个问题

是关于Mixin的，能不能帮我们讲讲这个Mixin在Java这样的语言里如何实现啊(C++可以通过多继承实现，但不知道Java, C#这类的单继承语言怎么处理这个问题)？从wikipedia上 http://en.wikipedia.org/wiki/Mixin 看，似乎可以近似理解Mixin为带实现的Interface，那么这个Mixin到底有哪些好处，哪些不好呢？在实践中如何把握？对应于23个经典的设计模式，Mixin和哪些最接近？

请教了

作者: coredump 时间: 18-10-2008 22:24
标题: A very good Design Patterns web site
http://www.edlin.org/cs/patterns.html

作者: datouming 时间: 21-10-2008 15:41
head first design pattern 不错，比GOF好理解多了。

作者: hoopoos 时间: 21-10-2008 19:52
标题: 回复 #23 coredump 的帖子
在Java里面目前没有Mixin的概念，因为确实Java是不支持class多继承的，但是interface是可以多继承的。设计模式的推广，尤其是Head First Design Pattern里面强调的OO原则，重点在于把握一些OO的良好设计准则（面向抽象，低耦合，高内聚），而不在于为了模式而使用模式。如果遇到需要多继承的场合，通常是采用接口多继承，和implementation composition的方式实现的，比如，对于一个多继承的case，在C++这样的语言里可能是这样
class B
class A
class C:public B,A
每个class里面都直接包含了implementation

如果是Java，那么是这样的
interface B, 有一个public method mforB
interface A, 有一个public method mforA
interface C extends B,A
同时，有
class FooB implements B
class FooA implements A
class FooC implements C
那么，FooC在implement C的时候，是先把interface A,B的实现类FooA，FooB Aggregate进来
private A a;
private B b;
public void mforA()
{
this.a.mforA();
}
public void mforB()
{
this.b.mforB();
}

这个方式一样实现了多继承，虽然有点罗嗦，但是仍然是个好的设计，因为为了重用而使用的继承最好是接口的继承，而不是concrete class的继承，原因是：抽象的方法是稳固的，而对象的属性等特征是脆弱的。在上面的例子里面，如果我修改了FooA，FooB，只要A，B这两个接口不变，对FooC一点影响都没有。但是如果我是类似于C++那样，直接FooC继承FooA，FooB，那就不好说了，因为子类是允许访问父类的非private方法和成员的。

这个话题，可以参考GoF的Bridge Pattern和Strategy Pattern，关于接口的继承，和实现与接口的分离。

作者: sliuhao 时间: 21-11-2008 10:03
个人感觉, 要想使用DP, 脑袋里就要忘记DP.这是我的感觉和经验.
GOF的是类层次上的DP, 还有很多upper和low的DP.

作者: lilianaya 时间: 21-11-2008 11:59
学习了，非常感谢！
mixin ？ruby 中也有mixin。coredump 大大应该说得是这个吧？.NET 的设计也挺有意思，感觉学习了这个mixin，不过它是叫做 Extension Method，是一堆静态方法。
从mixin 的命名来看，是不是就是在说要混入？为已有的class 增加新的能力。哈哈
随便说一下俺对Java、.NET 两种代表OO 语言的感觉，感觉Java 的设计更简单纯粹，更OO，不过有些时候显得死板化，.NET则更灵活方便，没有太多清规戒律，反而显得更开放。
俺都是只看过些皮毛，瞎抛砖。大家都来详细说说。

作者: hxuanyu 时间: 18-12-2008 23:19
DP的书很多，head first，四人帮的，或者连带着看看Refactoring to Pattern。
说白了也就是前人的经验总结罢了，很多模式包括decorator adapter， observer都是浅显易懂的。singleton java里面都在用，用代理包装算法那也是OO的基本思想。
所以我同意设计模式解析这本书里的一句话，其实设计模式最重要的，是方便了大家的交流沟通，只要一提xx模式，大家就都清楚这个模式用在什么场景，类通常怎么设计。

如果你还年轻，多看看算法，写写程序，数学基础也可以再沓实下。

设计模式也只是能帮你有效的组织程序，代码看起来更漂亮更合理罢了。但他不是灵丹妙药咯

作者: black_zerg 时间: 10-1-2009 18:39
提示: 作者被禁止或删除, 无法发言 说实话那些模式太多，有点吓人，我觉得来个四五个也就差不多了，顶多再补个四五个不常用的，10个，10个撑死。怎么会搞出那么多来，bridge什么的就看着很晕菜。

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

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

作者: tkl888 时间: 30-1-2009 09:21
而且模式是可以嵌套可包含可交互的>>严重同意，这个是DP里最难的部分了。

作者: tanliyoung 时间: 3-2-2009 17:25

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

 登录/注册后可看大图

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

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

作者: 周星星1832 时间: 10-2-2009 13:56
就知道一个MVC

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

作者: gdzack 时间: 4-4-2009 10:40

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

 登录/注册后可看大图

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

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

作者: key 时间: 1-5-2009 09:37

原帖由 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 时间: 1-5-2009 09:55

原帖由 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 时间: 1-5-2009 10:47

原帖由 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 时间: 1-5-2009 11:00

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

 登录/注册后可看大图

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

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

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

作者: key 时间: 1-5-2009 11:32

原帖由 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 时间: 1-5-2009 20:28
提示: 作者被禁止或删除, 无法发言 原来bridge这名字感情是个象形名，这么多年总算明白了，哭了。

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

作者: valpa 时间: 26-6-2009 22:50

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

 登录/注册后可看大图

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

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

作者: valpa 时间: 26-6-2009 22:53
hoopoos兄？不上线了么？

作者: felix100 时间: 1-11-2009 20:14

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

 登录/注册后可看大图

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

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

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

作者: earthengine 时间: 9-11-2009 21:18
注意：以下内容为本人原创，首发本论坛。这不是论文，只是一个简介，希望抛砖引玉。

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

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

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

欢迎光临 FreeOZ论坛 (https://www.freeoz.org/bbs/)