欢迎探讨设计模式
我在公司做过一些设计模式的培训，也读过一些设计模式的书，产品实践里面也大量运用了设计模式，愿意和大家探讨，不了解设计模式的，也欢迎提问。回复 #1 hoopoos 的帖子
:support: :zan 你介绍具体点吧我都不知道什么叫设计模式,无从问起 Design Pattern? Cool! Teach me from beginning!:welcome:
[ 本帖最后由 空明七心 于 6-6-2008 22:41 编辑 ] 设计模式迷你手册，一起学习。LZ啥时候开讲？:o 如果对DP一无所知，建议先读一些书，比较好，因为内容太多也不是很直观，而且不适合bbs里面这样快速简略的学习。
大多数知识都是可以自学的，然后带着问题和别人一起探讨更有效果，特别是有了一些自己的实践后学习的效果更好。
我自己做了一套DP的PPT，结合了我们自己公司产品的实际例子，但是因为涉及版权，所以不方便公开，网上应该有其他的open的材料，比如楼上贴的。
回复 #6 hoopoos 的帖子
DP还是得有实际应用理解才有效果，偶现在干的活根本都没应用，学都没法弄:Q :Q :Q :Q :Q :Q :Q 给一个例子，抛砖引玉吧比如， 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);
}
//adapterclass we are implementing
public class Adapter implements ExternalInterface
{
private InternalInterface fooImpl;
public void setAdapterImpl(InternalInterfacei)
{
this.fooImpl=i;
}
// adapting....
public void externalMethod(int i)
{
fooImpl.internalMethod(String.parseInt(i));
}
}
在上面这个例子里面，我用了composite一个现有method实现类的方式，来做adapt这件事情，这叫做object adapter，同样，我可以采用inheritant现有实现类的方式来做。不过，一般来说，在同样的情况下，我们推荐composite而不是inheritance。
严重支持
欢迎详细资料，因为dp只在我心里，我从来不在我的设计文档里面体现这些。希望多位高手多指教。看来楼主是Java Specialist
回复 #9 shenlh 的帖子
这不明摆着嘛，看看lz的头就很清楚了;P ;P ;P ;P ;P 既然有人支持，就斗胆再写一段，说说decoratordecorator，顾名思义就是装饰，通常给一间空白的房子，先刷一层漆，然后装上地毯窗帘，再搞上一些灯，最后放进去家具，弄点鲜花玩具，这样一层层的装饰，就不断完善了这个房子，让它从空荡荡的，变成功能齐全，富有生活情趣的一个居所。
在软件开发里，我们常常要扩展一个类的功能，有时候我们直接修改这个类，增加方法和属性，这是比较直接的做法，但是，这样做可能会破坏原来类的功能引入新的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 编辑 ] 好的很，等有版主的就建议加精。楼主把经典23模式统统给大家讲一遍吧。如果有现有软件的经典用例则更精彩:qiang :oil 能不能讲一下用 ASP.Net 框架如何实现MVC？ 原帖由 MSPro 于 11-6-2008 00:01 发表 http://www.freeoz.org/forum/images/common/back.gif
能不能讲一下用 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。 dp其实就是polymorphism的延伸，我做pm的时候尝试用了几个，还好:lol 设计模式一直是我的爱好，可惜我没太多的实践经验，向各位前辈多学习了。。。。
搞个设计模式的搞笑版，大家一起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，她们只要说道“老公”，都是指的同一个人，那就是我(刚才做了个梦啦，哪有这么好的事)
单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。 有关DP，我在看的书是JAVA DESIGN PATTERNS A TUTORIAL，作者 JAMES W. COPER，有其他朋友推荐一些好书吧，英文的。顺便问楼主，现在的JAVA 开源的一些项目，比如Structs,AJAX,hibernate,看的人眼花缭乱，都不知道外面是否在用。
[ 本帖最后由 uniwg 于 15-9-2008 12:41 编辑 ] 欢迎LZ继续讲课
回复 #17 uniwg 的帖子
struts, hibernate用的还是很多的，尤其是hibernate。ajax很新鲜很管用，但是就那么点东西，并且浏览器支持有限。越是这些流行的framework，越是能在里面发现大量模式的运用。 跟着学习了！ 终于看到熟悉的东西了，以后要多向楼主学习。。。。。 呵呵，上两个月找工作的时候面试常常被问到设计模式，因为自己很熟悉，所以对答如流，感觉这里的analyst，programmer，develope之类的开发职位对设计模式还是很重视的。
回复 #22 hoopoos 的帖子
再恭喜一下:congra再问个问题:lol是关于Mixin的， 能不能帮我们讲讲这个Mixin在Java这样的语言里如何实现啊(C++可以通过多继承实现，但不知道Java, C#这类的单继承语言怎么处理这个问题)？ 从wikipedia上 http://en.wikipedia.org/wiki/Mixin 看，似乎可以近似理解Mixin为带实现的Interface， 那么这个Mixin到底有哪些好处，哪些不好呢？ 在实践中如何把握？ 对应于23个经典的设计模式，Mixin和哪些最接近？
请教了:)
A very good Design Patterns web site
http://www.edlin.org/cs/patterns.html head first design pattern 不错，比GOF好理解多了。回复 #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，关于接口的继承，和实现与接口的分离。 个人感觉, 要想使用DP, 脑袋里就要忘记DP.这是我的感觉和经验.
GOF的是类层次上的DP, 还有很多upper和low的DP. 学习了，非常感谢！
mixin ？ruby 中也有mixin。coredump 大大应该说得是这个吧？.NET 的设计也挺有意思，感觉学习了这个mixin，不过它是叫做 Extension Method，是一堆静态方法 。
从mixin 的命名来看，是不是就是在说要混入？为已有的class 增加新的能力。哈哈
随便说一下俺对Java、.NET 两种代表OO 语言的感觉，感觉Java 的设计更简单纯粹，更OO，不过有些时候显得死板化，.NET则更灵活方便，没有太多清规戒律，反而显得更开放。
俺都是只看过些皮毛，瞎抛砖。大家都来详细说说。 DP的书很多，head first，四人帮的，或者连带着看看Refactoring to Pattern。
说白了也就是前人的经验总结罢了，很多模式包括decorator adapter， observer都是浅显易懂的。singleton java里面都在用，用代理包装算法那也是OO的基本思想。
所以我同意设计模式解析这本书里的一句话，其实设计模式最重要的，是方便了大家的交流沟通，只要一提xx模式，大家就都清楚这个模式用在什么场景，类通常怎么设计。
如果你还年轻，多看看算法，写写程序，数学基础也可以再沓实下。
设计模式也只是能帮你有效的组织程序，代码看起来更漂亮更合理罢了。但他不是灵丹妙药咯 说实话那些模式太多，有点吓人，我觉得来个四五个也就差不多了，顶多再补个四五个不常用的，10个，10个撑死。怎么会搞出那么多来，bridge什么的就看着很晕菜。
页:
[1]
2