[讨论] 如何区别和理解理解设计模式 ？

    学习设计模式已经有一段时间了，但经常还是会很困惑。看书上的代码会发现很多不同的设计模式的代码结构非常相似。比如 Bridge 和 Strategy 。。。

     既然是一个讨论贴，那我就先抛砖引玉，希望各位牛人赐教。。

    
     设计模式就是我们设计过程中经常出现的一些相同的情景的解决方案。它也严格遵循设计原则，几乎所有的设计模式都遵循封装变化的原则，个人觉得GOF队设计模式的分类也是根据封装变化的不同来进行的分类，创建型模式封装的是对象的创建的变化，结构型模式封装的是结构的变化，而行为型模式封装的是行为的变化。
     
      对于每个具体的模式区别则在于意图，看到网上有很多人写工厂方法模式和抽象工厂模式的区别，水平参差不齐，有的直接就从树上拷段代码，然后对着代码的结构来分析两者的区别。这样的分析对于初学而又迷惑的人来说非常的不好。

     我这只是个水帖，希望大家多来点口水，不要吝惜。。。。

评论

34 楼 airsise 2008-11-14  

个人体会，没有设计模式。只有应用场景。一切从需求出发， 逐步重构（最好是最小重构）。然后就是多写代码，多总结，自然就水到渠成了。

33 楼 tianmo2008 2008-11-14  

jeff.chuh 写道

tianmo2008 写道

这几天看书，工厂方法确实很不好理解，感觉没有必要，我的理解是引进工厂的目的之一是要是要隐藏掉new,但在工厂方法里，实现了工厂接口的具体工厂类自身也是要new的，这样，为什么不直接去new一个产品呢？而且和抽象工厂对比，我觉得工厂方法是定位在一个产品应该对应一个工厂类的，这样的话，没添加一个产品就得有对应的一个工厂，还得new一个工厂，这样还不如直接用产品接口，然后new一个具体产品不是更直观吗？工厂方法和接口感觉不到有什么优势.

你是没发现工厂用到什么地方，
当然对于ArrayList在代码里你可以到处new，
因为ArrayList的实现是稳定的，不需要你实现一个MyArrayList，
但是有些情况不一样，
比如有个FileLogger，从名字看出它是向文件输出log的实现类，
但你并不能保证你做好的项目以后不会变成向DB输出log，
这时你又实现了DBLogger，这时你发现FileLogger被new到各个地方，
你不得不一个个都替换成DBLogger。
而如果使用工程的话，你只需要修改工厂的实现就可以了，甚至你工厂是读取配置文件得到FileLogger的，
那么你只需要修改配置文件就可以了。

至于接口，你可以找找为什么要面向接口编程，这样做可以给你带来什么。

宏光点来看工厂模式的话，我是可以理解工厂的优势的，但现在是在工厂模式里面细分简单工厂、工厂方法和抽象工厂的时候，我个人觉得工厂方法在简单工厂和抽象工厂之间成了鸡肋，简单工厂和抽象工厂我都可以找到他们的应用场合，但工厂方法我却找不到，因为我目前接触的需求，要么就直接用简单工厂了事（尤其在配合反射的情况下），要么就直接分类后用抽象工厂，而没有考虑工厂方法的地方，所以觉得工厂方法很不好理解。
注意，我只是冲着工厂方法，而不是冲着整个工厂模式。

32 楼 neo_q 2008-11-14  

首先，谈到设计模式之前，你得明白，为什么要进行设计。有很多人都是为了设计而设计，你扪心自问有多少时候是真的发现这里需要使用某种设计理念而使用，而非刻意去套用某种设计模式。
设计的目标是什么？首先我们之所以要设计是为了应对系统的复杂性。这种复杂可能来自软件需求、变更等等一系列的问题。而作为程序员要做的是什么？只所以要设计是要为了构造一个复用性高、稳定、健壮的系统，要做到这些你必须有理论基础和实践经验。理论基础有很多，设计模式只是其中的一种。
设计模式只是人们总结出来的应对复杂性、需求的多变性的一套固定的手段和方法，并不是你当前项目中一定能用的上的，我觉得我们总是得以高内聚、低耦合为目标来构建系统。前面有位兄弟说的很对，并不能一开始你就会得到一个良好的设计，特别是缺乏经验的时候，一定要多重构，重构是一种良好的习惯，更能帮助你培养设计思想，当以后相似的场景再出现的时候，你自然会知道该使用何种模式。
另外一种看法就是封装变化。你不要把系统的可变性变得不可收拾，就是说你需要给系统一个最稳定的抽象和最灵活的实现，让可能发生的变化出现在你预料中的地方，设计模式就是提示你在某些特定场景下，这些变化在哪里和如何封装他们。
就以楼主自己据的strategy和bridge来说，strategy是意料到变化将会出现在算法部分，那么将比算法高级的部分抽象出来，使其稳定和不需变化，而要变化的那部分算法是可以灵活的，可插拔的。而bridge则将变化放置在两个地方，而他们的关系是不发生变化的，将这种关系抽像成稳定的，不变的，而让两端的事物可以灵活变化而互不干涉。以上都是从封装变化的角度来看待设计模式的。
其实要理解设计模式，首要有丰富的经验可能帮助比较大，如果没有丰富的经验，那么对你已经拥有的代码多做重构是获得经验的一个非常好的途径，其次抛开语言本身的特征，不要被那些实现语言的特性所迷惑，他可能会让你迷失在实现层而非抽象层，如果你的眼光停留在实现层是看不见设计之美的，Robert.c.martin有句话“The quality of an object oriented application is determined far more by the quality of its analysis and design, than by the features of the implementation language.”
多重构，多思考，以上是我的一些分享，欢迎讨论。

31 楼 wanghualeilei 2008-11-14  

设计模式描述了如何接触对象间的耦合 以及如何应对将来出现的变化   创建型模式已经很少使用 因为我们有了IoC 对象生命周期统一交给容器管理。 而另外2种结构型和行为型之所以也让我们感到用处不大  是因为设计模式描述的是对象间的通信和协作 此处的对象 是指真正的对象 是既有数据 又有行为的对象， 而在我们的企业应用中 往往是层次化思想 表示层 业务逻辑层 数据访问层 层次化过于教条 所以导致里面的大部分对象要么有行为没数据 例如Service何Dao 要么有数据没行为 例如Model  所以正是这些不是对象的对象让我们感到设计模式无从下手  但有几种模式还有很大机会使用的 例如Template Method, State, Strategy.

30 楼 zcclark 2008-11-14  

建议多看看Spring的代码，了解一下IOC，你会对工厂模式有更深的理解。
而且Spring写的代码质量也很高。

29 楼 crazy.j 2008-11-14  

我觉得吧，在设计阶段如果刻意的去使用模式是没有意义的，那些模式所能解决的问题你在遇到的同时本着面向对象的的几个原则去思考并解决自然就是使用了相应的模式，这东西不可以滥用，咱们是通过问题出来的模式，而不是拿着模式去找问题。

28 楼 bookong 2008-11-14  

又是一个没读版规的，楼主我同情你——这个帖子会被移到新手区，楼主你会被扣分

27 楼 xijunhu 2008-11-13  

yunhaifeiwu 写道

模式，是为了需求变动而产生，抛开需求谈模式，显得很苍白。

模式，没有完美的模式，它只适应于特别的场合。封装变化点，是最重要的

原则，个人认为封装变化点与解耦有紧密的联系，解耦常用的最基本的技术

手段(仅限于面向对象这个范围，抛弃IOC,否则对讨论设计模式没帮助)，

横穿于23种设计模式。

工厂模式：应用场所是------创建对象的方法相同，但创建具体的对象会经常变化。

换句话说：我的代码中许多地方都要产生一个新的对象，而这个创新的对象在未

来一段时间内，有可能会经常变化。当这个对象真的要变了时，我如何用最少的代价修

改我的代码呢？因此，有必要把"创新对象"进行解耦。尽可能的，我只改一两处，就实现

了所有代码的修改。如何实现呢？  凡是要生成新对象的代码，都统一用个类的方法产

实例，如果对象要变时，修改这个类就行了。

举个例子：

   我有一个游戏，需要在多个地方产生鸡这个实例，假定鸡这个类名为:Chicken ,

这样我的代码将多处出现：
    Chicken  ck1 =new Chicken ();
    ..........
     Chicken  ck2 =new Chicken ();
     ..........
   ..........
     Chicken  ckn =new Chicken ();
     ..........
   
假设有一天：需要把鸡，改成dog，不是一下就要改n处吗？如果这个n很大，是不是工作

量大，且容易出错呢？也就是说现在，我的生成的对象与我的代码紧密的耦合在一起

了。需要解耦。仔细观察 ，我们要创建对象这个是不变的，而具体要创建的对象在变化

了。这就是说，在这里产生了变化点。按设计模式原则：要在这个生成对象的地方，要

封装起来。好了，我们由统一的方法产生。假定完成这个工作的类叫Factory,在这个工

厂中传入我们要生成的实例参数，然后由 createInstance.产生。其次，通常情况下，

需要为所有要变化的类抽象出公共基类，在这里假定为Animal。这个类，可以如下表

示(仅是举个例子，具体语法之类的，请自行调试。不足之处，请谅解）：

    class  Factory {
        private Animal  ani;
        public Factory ();
        public static setAnimal(Animal ani){
           this.ani=ani;
        }
        public static  Animal createInstance(){
           return ani;
        }
    }
   

   我的代码相应变动：
  
    首次如下使用，把Factory  的fac对象弄成全局变量。

    Factory  fac＝new Factory ();
    Animal ani=new Chicken();
    fac.setAnimal( ani);

    其他要产生新的对象，都这样写：

     Animal  ani1=fac. createInstance();
-----------------------------------
     Animal  ani2=fac. createInstance();

----------------------------------
    Animal  ani3=fac. createInstance();


如果我要dog,该怎么办呢？

      仅需在fac首次使用的地方改成：
      
        Factory  fac＝new Factory ();
        Animal ani=new Dog();
         fac.setAnimal( ani);

------------------

说明：如果 用泛型或类反射，可直接去掉更多的设置，可以连chicken与dog共有的

父类 Animal 去掉。这里仅仅是说明工厂模式应用的场景。至于工厂模式如何应用，实

现，可以参考相关教材。望网友见谅。（如果单例模式结合工厂模式，则可以免去

设全局变量的麻烦。凡是全局变是，在多线程 情况下，要注意线程安全。

----------有点画蛇添足了！）


最后，说明3点：

   1  如果我要创建工厂的这个Factory在实际需求中，也会不断的变，怎么办？怎么解

耦？怎么找出变化点？怎么封装变化点？于是有了，抽象工厂。抽象 工厂与其他模式，

我不想参于讨论了。望本回复能起抛砖引玉的作用。

  
   2  设计械式的理解与掌握，不在于23种模式中各个类之间的关系 理清，更不在于具体的

语言（只有是面向对象的语言都可以),而在于23种模式面临的需求场景。要从发现需求变动，

准确找到变化点，如何封装它的角度去研究，去学习，

而不要拘泥于具体的形式。换句说话：在23种设计模式的需求中，要准确

找出哪些地方是强耦合，并且由于实际需要，要对这些耦合进行解耦。23种模式中，用

了哪些最基本的技术手段进行解耦了呢？ （据我的观察体会，大约有5种，最常见的方

法是，把一个类的对象，注入另一个类中，然后调用这个对象的方法。）

    3 与其他网友的观点一样，要在实践中不断学习与领悟。书与实践相结合。

本回贴 ，仅是个人观点，不足之处，望众网友见谅！本回复，仅是抛砖引玉。如果认为

有参考价值，就参考一下；如果狗屁不通，就付诸一笑；如果观点性错误，请给其他网友

指出来，误已可以，不想误人！再次谢谢各网友了！

这个我看懂了，觉得说得有道理。

26 楼 sea7 2008-11-13  

狼人小木 写道

现在也正在学设计模式，关注各位牛人的见解！呵呵！

大家都是初学者，讨论可以交换大家的不同的理解，同时增加自己的理解

25 楼 狼人小木 2008-11-13  

现在也正在学设计模式，关注各位牛人的见解！呵呵！

24 楼 aone 2008-11-13  

正在看<<head first 设计模式>>,这本书还不错.

23 楼 high_java 2008-11-13  

推荐书《head first 设计模式》
或者如果你英语好的话，可以参考pattern in j2ee

22 楼 realvalkyrie 2008-11-13  

推荐看两本书 基本就可以有个概念 ，强烈推荐第二本

重构:改善既有代码的设计

敏捷软件开发:原则、模式与实践

21 楼 xxrrss 2008-11-13  

重构！自然知道代码的不足，代码的可重用性！自然对理解设计模式有很大的好处！但是如果你对书本上的设计模式了然于胸的话，你思考的空间就更大了，你重构的价值也就小了！

20 楼 yunhaifeiwu 2008-11-13  

模式，是为了需求变动而产生，抛开需求谈模式，显得很苍白。

模式，没有完美的模式，它只适应于特别的场合。封装变化点，是最重要的

原则，个人认为封装变化点与解耦有紧密的联系，解耦常用的最基本的技术

手段(仅限于面向对象这个范围，抛弃IOC,否则对讨论设计模式没帮助)，

横穿于23种设计模式。

工厂模式：应用场所是------创建对象的方法相同，但创建具体的对象会经常变化。

换句话说：我的代码中许多地方都要产生一个新的对象，而这个创新的对象在未

来一段时间内，有可能会经常变化。当这个对象真的要变了时，我如何用最少的代价修

改我的代码呢？因此，有必要把"创新对象"进行解耦。尽可能的，我只改一两处，就实现

了所有代码的修改。如何实现呢？  凡是要生成新对象的代码，都统一用个类的方法产

实例，如果对象要变时，修改这个类就行了。

举个例子：

   我有一个游戏，需要在多个地方产生鸡这个实例，假定鸡这个类名为:Chicken ,

这样我的代码将多处出现：
    Chicken  ck1 =new Chicken ();
    ..........
     Chicken  ck2 =new Chicken ();
     ..........
   ..........
     Chicken  ckn =new Chicken ();
     ..........
   
假设有一天：需要把鸡，改成dog，不是一下就要改n处吗？如果这个n很大，是不是工作

量大，且容易出错呢？也就是说现在，我的生成的对象与我的代码紧密的耦合在一起

了。需要解耦。仔细观察 ，我们要创建对象这个是不变的，而具体要创建的对象在变化

了。这就是说，在这里产生了变化点。按设计模式原则：要在这个生成对象的地方，要

封装起来。好了，我们由统一的方法产生。假定完成这个工作的类叫Factory,在这个工

厂中传入我们要生成的实例参数，然后由 createInstance.产生。其次，通常情况下，

需要为所有要变化的类抽象出公共基类，在这里假定为Animal。这个类，可以如下表

示(仅是举个例子，具体语法之类的，请自行调试。不足之处，请谅解）：

    class  Factory {
        private Animal  ani;
        public Factory ();
        public static setAnimal(Animal ani){
           this.ani=ani;
        }
        public static  Animal createInstance(){
           return ani;
        }
    }
   

   我的代码相应变动：
  
    首次如下使用，把Factory  的fac对象弄成全局变量。

    Factory  fac＝new Factory ();
    Animal ani=new Chicken();
    fac.setAnimal( ani);

    其他要产生新的对象，都这样写：

     Animal  ani1=fac. createInstance();
-----------------------------------
     Animal  ani2=fac. createInstance();

----------------------------------
    Animal  ani3=fac. createInstance();


如果我要dog,该怎么办呢？

      仅需在fac首次使用的地方改成：
      
        Factory  fac＝new Factory ();
        Animal ani=new Dog();
         fac.setAnimal( ani);

------------------

说明：如果 用泛型或类反射，可直接去掉更多的设置，可以连chicken与dog共有的

父类 Animal 去掉。这里仅仅是说明工厂模式应用的场景。至于工厂模式如何应用，实

现，可以参考相关教材。望网友见谅。（如果单例模式结合工厂模式，则可以免去

设全局变量的麻烦。凡是全局变是，在多线程 情况下，要注意线程安全。

----------有点画蛇添足了！）


最后，说明3点：

   1  如果我要创建工厂的这个Factory在实际需求中，也会不断的变，怎么办？怎么解

耦？怎么找出变化点？怎么封装变化点？于是有了，抽象工厂。抽象 工厂与其他模式，

我不想参于讨论了。望本回复能起抛砖引玉的作用。

  
   2  设计械式的理解与掌握，不在于23种模式中各个类之间的关系 理清，更不在于具体的

语言（只有是面向对象的语言都可以),而在于23种模式面临的需求场景。要从发现需求变动，

准确找到变化点，如何封装它的角度去研究，去学习，

而不要拘泥于具体的形式。换句说话：在23种设计模式的需求中，要准确

找出哪些地方是强耦合，并且由于实际需要，要对这些耦合进行解耦。23种模式中，用

了哪些最基本的技术手段进行解耦了呢？ （据我的观察体会，大约有5种，最常见的方

法是，把一个类的对象，注入另一个类中，然后调用这个对象的方法。）

    3 与其他网友的观点一样，要在实践中不断学习与领悟。书与实践相结合。

本回贴 ，仅是个人观点，不足之处，望众网友见谅！本回复，仅是抛砖引玉。如果认为

有参考价值，就参考一下；如果狗屁不通，就付诸一笑；如果观点性错误，请给其他网友

指出来，误已可以，不想误人！再次谢谢各网友了！








   

19 楼 jeff.chuh 2008-11-13  

tianmo2008 写道

这几天看书，工厂方法确实很不好理解，感觉没有必要，我的理解是引进工厂的目的之一是要是要隐藏掉new,但在工厂方法里，实现了工厂接口的具体工厂类自身也是要new的，这样，为什么不直接去new一个产品呢？而且和抽象工厂对比，我觉得工厂方法是定位在一个产品应该对应一个工厂类的，这样的话，没添加一个产品就得有对应的一个工厂，还得new一个工厂，这样还不如直接用产品接口，然后new一个具体产品不是更直观吗？工厂方法和接口感觉不到有什么优势.

你是没发现工厂用到什么地方，
当然对于ArrayList在代码里你可以到处new，
因为ArrayList的实现是稳定的，不需要你实现一个MyArrayList，
但是有些情况不一样，
比如有个FileLogger，从名字看出它是向文件输出log的实现类，
但你并不能保证你做好的项目以后不会变成向DB输出log，
这时你又实现了DBLogger，这时你发现FileLogger被new到各个地方，
你不得不一个个都替换成DBLogger。
而如果使用工程的话，你只需要修改工厂的实现就可以了，甚至你工厂是读取配置文件得到FileLogger的，
那么你只需要修改配置文件就可以了。

至于接口，你可以找找为什么要面向接口编程，这样做可以给你带来什么。

18 楼 sea7 2008-11-13  

woods 写道

我对模式的感觉:
1.设计模式能给你一个设计的起点，然后随后慢慢根据需要重构出适合你的项目的设计.
2.给了你一个交流的语境.(讨论时候:"恩恩 我觉得这里需要个strategy...")
3.没必要非得死靠这是某某模式,实际使用往往是某几种模式的综合
4.设计模式的核心感觉:封装变化，抽象行为，多用组合:P

同意

17 楼 woods 2008-11-13  

我对模式的感觉:
1.设计模式能给你一个设计的起点，然后随后慢慢根据需要重构出适合你的项目的设计.
2.给了你一个交流的语境.(讨论时候:"恩恩 我觉得这里需要个strategy...")
3.没必要非得死靠这是某某模式,实际使用往往是某几种模式的综合
4.设计模式的核心感觉:封装变化，抽象行为，多用组合:P

16 楼 ksysteven 2008-11-13  

学习模式光看书是没用，我觉得学习模式要在有一定项目经验后，否则是白学的。最好要懂得比较有用模式和没有用模式的代码区别，不要为了模式而用模式。

15 楼 xiao_2008 2008-11-13  

tianmo2008 写道

这几天看书，工厂方法确实很不好理解，感觉没有必要，我的理解是引进工厂的目的之一是要是要隐藏掉new,但在工厂方法里，实现了工厂接口的具体工厂类自身也是要new的，这样，为什么不直接去new一个产品呢？而且和抽象工厂对比，我觉得工厂方法是定位在一个产品应该对应一个工厂类的，这样的话，没添加一个产品就得有对应的一个工厂，还得new一个工厂，这样还不如直接用产品接口，然后new一个具体产品不是更直观吗？工厂方法和接口感觉不到有什么优势.

在理解工厂方法之前，你要知道为什么要使用工厂方法，所以你要理解依赖倒转原则，依赖倒转原则是OO的设计核心，工厂方法设计模式只是依赖倒转思想的一种实现一种表现形式，而要理解依赖倒转原则 你就要去看OO了，这是思路
在遇到问题的时候，多想想为什么而不是你的“感觉没有必要”，
在你控制情绪之前，情绪是你的主人