学习设计模式的一个硬伤

     很多人在学习设计模式，也都能把GOF书中的factory, state, singleton, decorator等等说的叽里呱啦的，但是很多人其实都不知道怎么来用设计模式，工作几年，看过一些优秀的设计，但看过的更多的是滥用模式的设计，大部分人对设计模式的了解也都停留在层面上，在工作中曾有机会去对资历年长过自己的同行进行过面试，GOF中的模式随便挑一些出来问询，模式的用途，解决的问题以及优缺点什么的，大部分都能答个八九不离十，但是再往深入点，比如问，state与strategry的区别？或者两个维度的业务变化可以用Bridge来分离，那面对大于两个维度的业务变化时呢？ 对于此类稍微深入点的问题，面试者往往不知如何作答。

      或许是交际圈太窄，在现实生活中还没有接触到传说中的大牛，能够给予点播，以致往往在遇到问题时，只能闷着头颅去网络中四处寻找，然而网络中大多数人的理解显然都还是停留在理论层面，甚少有实际运用的例子，以致在某些时候，使用了模式后和使用之前没多大区别，有点画蛇添足的味道。

      举个工厂模式的例子，大多数文章都只是描述了工厂模式是什么，为什么要用，以及优缺点什么的，却唯独少了描述如何使用。比如说，工厂模式是为了封装对象的创建，降低具体产品和Client的耦合等等，大体上就是说，原先使用new Shape的地方， 换成factory创建的方式。

//使用工厂模式前，client调用的方式
Shape shape=new Circle();


//使用工厂模式后，client调用的方式
ShapeFactory factory=new CircleFactory();
Shape shape=factory.createShape();

 

    从上面的代码中，你看出了什么不对劲的地方了吗？ 如果我们真的这么来使用工厂模式，那么使不使用工厂模式没有什么两样，为什么？ 使用工厂模式前，client的代码依赖于具体的产品对象-Circle,使用工厂模式后，client的代码是不依赖于具体的产品对象-Circle了，但是转而依赖具体的工厂对象-CircleFactory了，依赖关系只是转移了，并没有降低。 但是这正是网上以及一些书籍中讲解工厂模式时所使用的方式，而且鲜有说明其中的缘由。这就造成了很多初学者乃至一些工作了多年的程序员都在这样使用着设计模式。

    再举个策略模式的例子，这是一个很简单的模式，但是仍然有很多人不知道策略模式还有一个Context元素，也不知道这个Context元素的作用， 既然模式里包含了这个Context，自然有它的用意。所以，对于我来讲，未能充分了解其意图之前，设计模式，还是不用为好。

评论

3 楼 狂放不羁 2010-04-08  

对， 你说的这个是使用工厂的另一个方面，如果仅仅是一个简单的全局控制，那么是可接受的，即具体产品只有一个，否则，那就不是工厂模式而是工厂方法，一个单例加上若干个创建不同具体对象的方法，不然还是需要工厂模式+工厂的工厂进行解耦。

软件设计确实是一门艺术，但是软件往往不能让客户和设计师同时满意，会偏向客户的满意度更多一些，在工作中，并不会有很多机会对代码进行重构，原因很简单，客户的满意度，特别是对于产品来说，如果你的产品有上千万的收费用户，你会不会经常因为你不满意但是却工作的很OK的代码进行重构？即使有单元测试+回归测试来做保证，但我仍然不会这么做，我只会发现现有的问题，并进行总结，等待一个可以重构的时机。架构师的职责很多，不仅仅是在于设计这一方面。

scanfprintf123 写道

狂放不羁 写道

但是可能多个地方都需要对象，而这个时候工厂就比new好了，同时工厂还可以提供全局控制，比如jive里面的ForumFactory,系统所有需要用Forum的地方都需要从这里来拿，这样封装了整个系统获取Forum的入口，方便控制。
总之，模式这东西，原理很简单，关键是如何能将理论和实际结合起来。也许很多人觉得，软件只要客户觉得满意就行了。但是我觉得，软件要让客户和咱们设计师或者架构师都满意。这也是我经常重构自己以前写的代码的原因。因为我现在对以前写的代码不满意，虽然重构了对客户没意义，但是对于我来说有意义。软件设计是一个艺术的过程。只有真正热爱它，把他当做兴趣，而不仅仅是工作才可以领会到其中乐趣。

对， 你说的这个是使用工厂的另一个方面，如果仅仅是一个简单的全局控制，那么是可接受的，即具体产品只有一个，否则，那就不是工厂模式而是工厂方法，一个单例加上若干个创建不同具体对象的方法，不然还是需要工厂模式+工厂的工厂进行解耦。

软件设计确实是一门艺术，但是软件往往不能让客户和设计师同时满意，会偏向客户的满意度更多一些，在工作中，并不会有很多机会对代码进行重构，原因很简单，客户的满意度，特别是对于产品来说，如果你的产品有上千万的收费用户，你会不会经常因为你不满意但是却工作的很OK的代码进行重构？即使有单元测试+回归测试来做保证，但我仍然不会这么做，我只会发现现有的问题，并进行总结，等待一个可以重构的时机。架构师的职责很多，不仅仅是在于设计这一方面。

呵呵，对。认同你的观点。我说的重构是重构自己因为兴趣而写的一些框架或者软件。对于公司的项目，目前重构的很少。

2 楼 scanfprintf123 2010-04-04  

狂放不羁 写道

但是可能多个地方都需要对象，而这个时候工厂就比new好了，同时工厂还可以提供全局控制，比如jive里面的ForumFactory,系统所有需要用Forum的地方都需要从这里来拿，这样封装了整个系统获取Forum的入口，方便控制。
总之，模式这东西，原理很简单，关键是如何能将理论和实际结合起来。也许很多人觉得，软件只要客户觉得满意就行了。但是我觉得，软件要让客户和咱们设计师或者架构师都满意。这也是我经常重构自己以前写的代码的原因。因为我现在对以前写的代码不满意，虽然重构了对客户没意义，但是对于我来说有意义。软件设计是一个艺术的过程。只有真正热爱它，把他当做兴趣，而不仅仅是工作才可以领会到其中乐趣。

对， 你说的这个是使用工厂的另一个方面，如果仅仅是一个简单的全局控制，那么是可接受的，即具体产品只有一个，否则，那就不是工厂模式而是工厂方法，一个单例加上若干个创建不同具体对象的方法，不然还是需要工厂模式+工厂的工厂进行解耦。

软件设计确实是一门艺术，但是软件往往不能让客户和设计师同时满意，会偏向客户的满意度更多一些，在工作中，并不会有很多机会对代码进行重构，原因很简单，客户的满意度，特别是对于产品来说，如果你的产品有上千万的收费用户，你会不会经常因为你不满意但是却工作的很OK的代码进行重构？即使有单元测试+回归测试来做保证，但我仍然不会这么做，我只会发现现有的问题，并进行总结，等待一个可以重构的时机。架构师的职责很多，不仅仅是在于设计这一方面。

1 楼 狂放不羁 2010-04-04  

但是可能多个地方都需要对象，而这个时候工厂就比new好了，同时工厂还可以提供全局控制，比如jive里面的ForumFactory,系统所有需要用Forum的地方都需要从这里来拿，这样封装了整个系统获取Forum的入口，方便控制。
总之，模式这东西，原理很简单，关键是如何能将理论和实际结合起来。也许很多人觉得，软件只要客户觉得满意就行了。但是我觉得，软件要让客户和咱们设计师或者架构师都满意。这也是我经常重构自己以前写的代码的原因。因为我现在对以前写的代码不满意，虽然重构了对客户没意义，但是对于我来说有意义。软件设计是一个艺术的过程。只有真正热爱它，把他当做兴趣，而不仅仅是工作才可以领会到其中乐趣。