模式总结——模板方法

在这么多有用的模式中，个人觉得模板方法是最难以理解的，而且不太好用，说实在的，是不太好设计，不知道何时要应用这个模式，其实每个模式都要理解很重要的一点：出发点是什么？换句话说，是什么因素，导致我需要这个模式。

public   class  Action1  ... {
    
    public void open()...{
        //打开数据库
    }
    public void close()...{
        //关闭数据库
    }
    
    public void action()...{
        open();
        //执行一些程序
        close();
    }
}

public   class  Action2  ... {
    
    public void open()...{
        //打开数据库
    }
    public void close()...{
        //关闭数据库
    }
    
    public void action()...{
        open();
        //执行另外一些程序
        close();
    }
}

上2个类的open close方法是一摸一样的，唯一不同的就在于action方法，当我们再需要这样一个类的时候，可以复制open close方法，其实也挺方便的，但恐怖之处在于，万一open或者close方法有点小BUG，那岂不是每个类都要去修改？这样就带来了很大的风险，于是我们的出发点在于，把open close 方法提取出来，我们来建立一个类

public abstract class  AbstractAction  ... {

    public void open()...{
        //打开数据库
    }
    public void close()...{
        //关闭数据库
    }
    
}

public   class  Action1  extends  AbstractAction  ... {
    

    public void action()...{
        open();
        //执行一些程序
        close();
    }
}

public   class  Action2  extends  AbstractAction  ... {
    

    public void action()...{
        open();
        //执行另外一些程序
        close();
    }
}

让Action1 Action2 这2个类继承它，好了，现在是不是已经把open 和 close都提取出来了，action1 和 action2调用的都是同一套方法了，接着的精华在于，把 action也提取到抽象类上

public   abstract   class  AbstractAction  ... {

    public abstract void action();
    
    public void open()...{
        //打开数据库
    }
    public void close()...{
        //关闭数据库
    }
    
}

这样设计好之后， AbstractAction action = new  Action1();          action.action()    接口就统一起来了


调用的流程其实是比较复杂的， AbstractAction  的action方法往 Action1里面找，action1里面的action方法里面的open close方法再往 AbstractAction 里找，有一个调用来调用去的过程，优美往往伴随着复杂，就是这个道理

总结下，我们设计的出发点，其实是从子类出发的，这样只是便于理解，其实更多的时候在于从父类出发考虑，父类把一些通用的方法都定义好，然后交代清楚要让子类做什么，也就是定义abstract方法。这样的设计非常像刻模子，子类继承父类就是一个复制品，但还不能拿来用，需要加工一下，也就是要实现abstract方法。 ...