我对设计模式的理解

      很久很久以前，我问我的朋友：“现在有什么好书可以研究研究的啊？”“设计模式啊。”他不假思索的回答我。想想也是，设计模式确实是一本经典的书，于是乎我又开始了《设计模式》这本书的阅读过程。本人对于设计模式的理解有限，而且限于个人能力，说实在的，在开始看设计模式这本书的时候，我就已经有些力不从心了，而且又了放弃的念头。因为翻开书第一页，我就已经被弄懵了。开篇第一个模式，我已经吃不透了，你觉得我还有兴趣继续看下去吗？答案显而易见，当然不看了，难道找打击不成？

     在平时开发的时候，会经常看到一些模式的应用，虽然不是很理解为什么这么做，但是既然大家都这么做，估计应该有其原因吧。最近看到工厂模式，其实我是很不理解为什么要用工厂模式的。既然可以通过一个类的构造函数来构造一个类的实例，为什么还要用工厂呢？目前为止唯一我能够想到的原因就是，用工厂模式可以方便管理在整个程序中某一个对象的所有实例。因为对象的实例都是通过工厂生产出来的。但是如果在写代码的时候，我没有用这个工厂去生产，而是直接用类的构造函数new了一个类的实例出来，那工厂岂不是做不到管理所有类的实例了？于是我认为，既然用工厂模式来生产类的对象了，那就不应该允许用户直接new出对象来。那怎么才能让用户不能new对象呢？对了，就是让对象的构造函数为私有的。但是如果构造函数是私有的，工厂又怎么生产呢？这不是矛盾的很么？那么就让构造函数为protected吧，然后再让工厂继承自对象。但是java是不允许多继承的，那怎么办呢？这个时候，我想到了友元，但是java好像没有友元啊？啊，C++的友元真伟大，不过再伟大在java这也没有用，哎。带着这个问题，我思考了一会儿，几分钟后，终于得到了答案。于是我设计出了如下的几个类：

  1: class Factory{
  2:     static public ArrayList<A> arrA;
  3:     static public ArrayList<B> arrB;
  4:     public A createA(){
  5:         return A.createA();
  6:     }
  7:     public B createB(){
  8:         return B.createB();
  9:     }
 10: }
 11: 
 12: class A{
 13:     private A(){}
 14:     static public A createA(){
 15:         A a = new A();
 16:         Factory.arrA.add(a);
 17:         return a;
 18:     }
 19:     
 20: }
 21: 
 22: class B{
 23:     private B(){}
 24:     static public B createB(){
 25:         B b = new B();
 26:         Factory.arrB.add(b);
 27:         return b;
 28:     } 
 29: }

以上两个类A、B都不能通过构造函数来构造自己，而是通过类自己的一个静态函数来创建，在创建类的同时，把类的实例放到Factory中的静态成员变量中，这样来实现利用Factory来统一管理所有A、B对象的目的。

做完这些之后，我突然又在想，我这样做的目的是什么？难道真的只是为了统一管理所有的类的实例吗？这样做有意义吗？这些问题，我自己到目前为止很难回答，之后在以后的开发过程中慢慢体验了。工厂模式真可谓是“博大精深”，各种各样的应用都值得研究。说实在的，我对设计模式的理解很浅薄很浅薄，也就这些而已。而且，这些理解都未必跟当初设计工厂的人一致，我只是把这些当做随笔记下来，如果有哪位大侠路过，希望不吝赐教，吾将感激不尽！