1、模板方法模式的概念
定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重新定义该算法的某些特定步骤
如果能够看懂上面这句话,那么你一定会觉得:模板方法模式的理解真是太TM简单了!
它不就是我们Android应用、Java应用的基类吗!?
我TM的?使用场景都不用说了…
2、UML图
使用场景还是大致说一下,比如我们在Android应用中,因为每个页面它们多少都会有一个共同的特点,所以我们需要对他们进行归纳,最后归纳到一个基类中,这个基类就是UML中的AbstractClass
:
//该类就是AbstractClass
//该类不做任何逻辑相关的操作,而是定义好算法框架
public abstract class BaseClass {
public abstract int doAdd(int a, int b);
public abstract int doMulti(int a, int b);
public abstract int doDivision(int a, int b);
}
定义好基类后,之后的类会继承这个类,并且实现它的方法:
//该类就是ConcreteClass,具体实现类,我们要在这个类做逻辑
//该类继承了基类
public class NormalClass extends BaseClass {
@Override
public int doAdd(int a, int b) {
return a + b;
}
@Override
public int doMulti(int a, int b) {
return a * b;
}
@Override
public int doDivision(int a, int b) {
return a / b;
}
}
当然了,如果只有一个实现类的话那没有必要用到这个模式,会显得臃肿,如果你另外一个类对象不会使用到其中的一些方法, 直接不实现,放在那里就可以了。
//另一个实现方法
public class SBClass extends BaseClass {
@Override
public int doAdd(int a, int b) {
return a * b;
}
@Override
public int doMulti(int a, int b) {
return a - b;
}
//嘻嘻,这个方法我用不着
@Override
public int doDivision(int a, int b) {
return 0;
}
}
总结
- 这个真的模式真的没有什么好讲的,因为我们用的太多了,已经把它当成变成习惯了,不过这个习惯很好
- 这个模式非常便于扩展,其实一开始实现类只有一两个,我们也可以抽出这一层,便于这个后的扩展,就是一个代码复用平台
- 在使用的时候一定要分清楚,什么是可变行为,什么是不可变行为,不可变行为,然后把可变行为作为抽象类,不可变行为作为统一在父类中实现好。这样可以避免不变的行为在子类重复出现,可变的行为不规则的出现可能会导致可读性降低。
- 这个设计模式得和策略模式区分开,模板方法模式更加宏观,一般是对整个模块或者整个应用进行算法抽取。而策略模式则是对于某一个功能进行分离算法,选择实现。
- 该模式属于行为型模式,对子类的行为做了统一。