“戏”说设计模式——模板方法模式

首先请出今天的主人公——“程序员天敌”产品经理

 

哈哈哈！这篇文章产品经理看了，估计会原地爆炸。

在最开始学习java时，我们知道了抽象类和接口这两个名词的意思。那么对于面向对象（OOP）编程来说，他们的具体含义又是很模糊的。我们都知道一个方法就是某种事物的行为封装。那么接下来引入“模板方法”，通过直译我们得知，这个应该类似一种具体事物产生时的“模具”，那么这个“模具”又具有那些特点呢？大小尺寸是否可以改变？它是否能跟随开发者的主观意志改变呢？

这里引用一位大佬的话：“模板方法，显而易见是说某个方法充当了模板的作用，其充分利用了抽象类虚实结合的特性，虚部抽象预留，实部固定延续，以达到将某种固有行为延续至子类的目的。反观接口，则达不到这种目的。”

我们先由一个简单抽象类的例子来描述吧。

public abstract class Mammal {
    //人类作为自然界最强大的统治者（讽刺！）
    protected final void man(){
        System.out.println("我是自然界的统治者，我可以破坏大自然！");
        
        /*
       
        省去对大自然的破坏方法。。。
        
         */
    }
    //哺乳动物可以移动，想去哪就去哪！
    public abstract void move();
}

 我是一只快乐的奶牛

public class Cattle extends Mammal{
    @Override
    public void move() {
        System.out.println("我可以用四条腿走路！");
    }
}

 我是一只自由的小鸟！

 

public class Bird extends Mammal{
    @Override
    public void move() {
        System.out.println("我可以用翅膀飞翔！");
    }
}

我是一只聪明的海豚！

public class Dolphin extends Mammal{
    @Override
    public void move() {
        System.out.println("我可以在大海里游泳！");
    }
}

 我们从哺乳动物的抽象类里可以看到子类的实现都是自己独有的行为方式，而在抽象本类里实现的人类破坏大自然，它是属于抽象哺乳类的共有行为，哺乳子类不能进行任何干涉。这便是接口与抽象的最大区别了，接口是虚的，抽象类可以有虚有实，接口不在乎实现类是什么，抽象类会延续其基因给子类。

下面就“请”出我们的产品经理了，在现代计算机软件开发过程中，都非常重视软件工程中的项目管理，包括软件开发前期的概念设计和物理设计，那么如果我们要做一个按照“瀑布式”开发的软件，我们通常将软件生命周期划分为制定计划、需求分析西、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

public abstract class WaterfallModel {
    protected abstract void draw();//制定计划
    protected abstract void analyze();//需求分析
    protected abstract void design();//设计
    protected abstract void develop();//开发
    protected abstract void test();//测试
    protected abstract void OperationAndMaintenance();//运行维护
}

 对于“瀑布式”开发模型，我们需要对每一步做详细的检测评估，否则在软件开发后期很可能会出现前期问题放大化，导致软件整体出现较大的问题，所以我们加入分部检测能力。

protected final void kickoff(){
              analyze();
              design();
              develop();
              test();
              operationAndMaintenance();
    }

 这样就限制了整个项目周期的任务流程，注意这里要用final声明此方法子类不可以重写，只能乖乖的继承下去用。至于其他的抽象方法，子类可以自由发挥，比如测试方法test()，子类可以用人工测试，自动化测试，作为决策者我们不用关心具体实现，我们是站在项目管理的抽象高度，只把控流程进度。

下面就好解决了吗，我们写一个设计时的系统自动检测

public class AutoTestDesign extends WaterfallModel{

    @Override
    protected void draw() {
        
    }

    @Override
    protected void analyze() {

    }

    @Override
    protected void design() {
        System.out.println("对软件基本需求设计");
    }

    @Override
    protected void develop() {

    }

    @Override
    protected void test() {

    }

    @Override
    protected void operationAndMaintenance() {

    }
}

 至此，我们的模板方法就完成了，抽象类WaterfallModel中的实方法kickoff()中，以某种逻辑编排调用了其他各个抽象方法，提供了一种固定模式的行为方式或是指导方针，以此达到虚实结合、柔中带刚、刚柔并济，灵活中不失规范的目的。