转载请标明出处:
http://blog.csdn.net/coder_nice/article/details/46990317
本文为阅读高焕堂老师的《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的结合使用。