Android设计模式之美---Factory Method

转载请标明出处：

/article/1802510.html

本文为阅读高焕堂老师的《android设计招式之美》后，整理出来的自己的理解。

Template Method 模式图

如果是简单的对象，那么我们随时用到ConcreteProduct随时new就可以，然而加上业务逻辑之后对象是不可能很简单的。

在编程中，产品类的实例化有时候是比较复杂和多变的，通过工厂模式，将产品的实例化封装起来，使得调用者根本无需关心产品的实例化过程，只需依赖工厂即可得到自己想要的产品。

class Engine {  

    public void getStyle(){  

        System.out.println("这是汽车的发动机");  

    }  

}  

class Underpan {  

    public void getStyle(){  

        System.out.println("这是汽车的底盘");  

    }  

}  

class Wheel {  

    public void getStyle(){  

        System.out.println("这是汽车的轮胎");  

    }  

}  

public class Client {  

    public static void main(String[] args) {  

        Engine engine = new Engine();  

        Underpan underpan = new Underpan();  

        Wheel wheel = new Wheel();  

        ICar car = new Car(underpan, wheel, engine);  

        car.show();  

    }  

}

可以看到，调用者为了组装汽车还需要另外实例化发动机、底盘和轮胎，而这些汽车的组件是与调用者无关的，严重违反了迪米特法则，耦合度太高。并且非常不利于扩展。另外，本例中发动机、底盘和轮胎还是比较具体的，在实际应用中，可能这些产品的组件也都是抽象的，调用者根本不知道怎样组装产品。假如使用工厂方法的话，整个架构就显得清晰了许多.

(迪米特法则（Law of Demeter）又叫作最少知识原则（Least Knowledge Principle 简写LKP），就是说一个

对象应当对其他对象有尽可能少的了解,不和陌生人说话。英文简写为: LoD. )



这是由Client类别的FactoryMethod（）来负责创建ConcreteProduct 子类别的对象，这是可行的

下面是流程图


























可以看的出来，框架里面的Client和Product是稳定不变的，不需改变就能搭配新的应用类别，这就发挥了应用框架的职能：确保不变的抽象类能随时与多遍的应用类别相搭配，然后组合出各种应用软件。即使未来有需要更改子类（上图的IntegerNumber类别名称）也只需要更改FactoryMethod（）函数内的new IntegerNumber（）指令而已。






这是Activity创建的流程图



创建Activity是极其复杂的过程，一句两句无法说清楚，比如我们把绿色圆圈内抽象成一个过程，而不去关注他。



此图中的绿色圆圈就是上图中的绿色圆圈，这就是android中对于Template method和factory method的结合使用。