设计模式整理_模板模式

  模板模式在父类中定义了一个方法的模板,而子类可以动态的实现模板成分方法,但是模板中的方法顺序无法改变.

  父类中的模板方法往往申明为final,用来保证方法不被子类覆盖,因为作为模板,是不可以改变的,但是模板方法内的一系列方法,可以由子类自己静态实现,同时在父类的模板方法中,可以定义钩子(hook)方法.方便子类对于模板方法的优化.下面用两个例子说明.

/*没有钩子(hook)的模板方法,此时模板方法无法修改*/
public abstract class Model {
    public final void eat()/*模板方法*/ {
        prepareFood();
        cookFood();
        eatFood();
    }

    public abstract void prepareFood();//交给子类去实现的方法

    public abstract void cookFood();//交给子类去实现的方法

    public abstract void eatFood();//交给子类去实现的方法
}
class Girl extends Model {
    /*子类实现玩需要实现的方法后,模板方法即可调用,完成操作*/
    @Override
    public void prepareFood() {
        System.out.println("女生在准备饭菜!");
    }

    @Override
    public void cookFood() {
        System.out.println("女生在做饭!");
    }

    @Override
    public void eatFood() {
        System.out.println("女生在吃饭!");
    }

}
/*有钩子(hook)的模板方法,此时模板可以由子类自由修改*/
public abstract class Model {
    public final void eat()/*模板方法*/ {
        prepareFood();
        if(hook())
        cookFood();
        eatFood();
    }

    public boolean hook() {
        return true;
    }

    public abstract void prepareFood();//交给子类去实现的方法

    public abstract void cookFood();//交给子类去实现的方法

    public abstract void eatFood();//交给子类去实现的方法
}
class Girl extends Model {
    /*子类实现玩需要实现的方法后,模板方法即可调用,完成操作*/
    @Override
    public void prepareFood() {
        System.out.println("女生在准备方便面!");
    }

    @Override
    public void cookFood() {
        System.out.println("");
    }

    @Override
    public void eatFood() {
        System.out.println("女生在吃方便面!");
    }

    public boolean hook()/*此方法在子类中返回为false后,cook方法将
    无法调用,因此改变了模板方法,这类方法又称为"钩子",可以改变模板方法.*/ {
        return false;
    }
}
时间: 2024-10-11 14:05:19

设计模式整理_模板模式的相关文章

设计模式整理_组合模式

组合模式允许你将对象组成树形结构,来表现整体和部分的联系.组合能让客户以一致的方式处理个别对象和对象的组合. 组合模式将整体称为组合.(类似于树结构中的树),将组合下面没有其他元素相连的物件称为叶结点.其中,组合和叶结点有着共同的父类,可以将两者所有的方法抽象到父类中,并且对方法有默认的实现,这样如果叶结点或者组合不想实现某个方法的时候,就可以不实现方法.通过将菜单和项放在相同的结构中,我们创建了一个整体/部分的层次结构,即由菜单项和菜单组成的对象树.可以将它视为一个整体.任何一个菜单都可能是组

设计模式整理_策略模式

△策略模式用于在用户行为经常发生变化的情况下,将行为单独提取出来,定义算法族,采用组合的方式,分别封装起来,让他们可以互相替换,此模式,让算法的变化独立于使用算法的客户. 该模式体现了如下设计模式的原则: 封装变化. 多用组合,少用继承. 针对接口编程,而不针对实现编程. 在策略模式中,第一点体现了对于类中变化的部分,进行了封装,第二部分体现了将算法族的接口定义在类中,采用组合的形式来完成对于类行为的定义,第三部分体现了利用借口代表每个行为,而将接口的具体实现交给其实现类来完成.下面是代码示例,

设计模式整理_状态模式

状态模式允许对象在内部状态改变的时候,改变它的行为,对象看起来好像修改了它的类.因为这个模式将状态封装成为独立的类,并将动作委托到代表当前状态的对象,而行为会随着内部状态而改变. 在状态模式中,Context内部持有状态,State接口定义了一个所有具体状态的共同接口,任何状态都实现这个相同的接口,这样一来,各个状态可以互相替换.具体状态实现状态接口,所以当Context改变状态的时候,行为也跟着改变.而不管在什么时候,只要有人调用Context的具体方法,它就会用来委托状态处理,下面用具体事例

设计模式整理_工厂模式

一.简单工厂模式. 通常情况下,在代码中需要创建一系列对象的时候,如果需要创建新的同类型的对象,就需要对原代码进行修改,此时就不符合对修改关闭的原则,因此,我们将创建对象于使用对象的代码分隔开来,在工厂类中创建工厂,然后如果需要新的对象,只需要修改工厂的类即可. public interface Car /*在这里定义需要生成的实例,针对抽象组件*/{ public void run(); } class BenzCar /*实例*/ implements Car { @Override pub

设计模式整理_迭代器模式

迭代器模式提供了一种方法顺序访问一个聚合对象中的各个元素,而又不是暴露其内部的表示.将在聚合对象内部游走的任务放在迭代器上而不是放在聚合上,这样简化了聚合的接口和实现,也让责任各得其所. 例如在没有进行优化的下列代码中,在处理不同的对象的聚合的时候,获取了对象的内部实现,这对封装造成了破坏,另外一方面,当需要处理其他类型的聚合对象的时候,也会造成需要对源代码进行修改,不利于扩展. /* * 定义Food类,Food类是需要被聚合的对象 * */ public class Food { priva

设计模式整理_命令模式

命令模式将请求封装成对象,以便使用不同的请求,队列或者日志来参数化其他对象,命令模式也支持可撤销的操作.当需要将发出请求的对象和执行请求的对象解耦的时候,采用命令模式. 命令模式中有几个名词:调用者,命令,接受者,客户.客户负责创建命令和调用者,调用者将命令封装在自己里面,当客户需要执行某些操作的时候,调用者就将调用命令对象的方法,命令对象通知接受者执行操作.一个命令对象通过在特定的接受者上绑定一组动作来封装一个请求,调用者可以接受命令作为自己的参数,甚至在运行的时候动态的执行,命令可以支持撤销

设计模式整理_外观模式

外观模式提供了一个统一的接口,用来访问子系统中的一群接口,外观定义了一个高层的接口,让子系统更容易使用.因为有了外观,客户的工作将更加快捷简便. 组件建立后,将会组装于外观中,并直接将外观派发给客户,方便使用,因此外观模式简化了组件中的一系列接口,方便客户的操作.外观将客户从一个复杂的子系统中解耦.当需要简化并统一一个很大的接口或者一群复杂的接口时,使用外观. 下面是外观模式的具体使用,可以看出,通过外观模式,大大的简化了客户的操作,对于组件的操作将在具体的外观内部进行操作. //组件 publ

设计模式(2)_代理模式 ————— 控制对象访问

设计模式(2)_代理模式 ----- 控制对象访问 一.动机 需求 现在有这样一个需求:有一个出版社,该出版社有一个工厂,专门用来生产制造图书,该工厂里有很多台生产制造图书的机器.每个机器有自己的位置坐标,用 int表示,机器的状态,{正在工作,暂停,故障},已经印刷了多少页图书.在出版社 在工厂 厂长的电脑屏幕上,可以随时打印出任何一台机器的报告信息(report infomation). 下来 我们用代码实现这个需求: PrinterMachine.java package com.crg;

Head First 设计模式系列之一----模板模式

开篇序言:四人帮的设计模式对于我这个菜鸟看着打瞌睡,后面果断买了一本head first的,感觉还可以像看报纸似的,花了一个寒假的晚上看了大半,确实内容也挺吸引人的,讲的很风趣.否则我也不可能,大过年的小伙伴们还在外面耍,自己还在那里装B.可是看完的困惑也随之而来,我怎么才能熟练的操练这些模式呢!书上讲的头头是道,可是实际中我们确不知道怎么运用!后面看到别人牛逼的都是随便一个模式都能脱口面而出,还有就是实际项目接触多了,肯定也有一定的职业嗅觉!所以希望自己也能够通过写博客,让自己对设计模式有一个