学习设计模式的一个硬伤

     很多人在学习设计模式，也都能把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，自然有它的用意。所以，对于我来讲，未能充分了解其意图之前，设计模式，还是不用为好。