浅淡设计模式之精髓-----封装变化点(回贴成文）

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

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

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

手段(仅限于面向对象这个范围，抛弃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 与其他网友的观点一样，要在实践中不断学习与领悟。书与实践相结合。

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

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

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