Java设计模式——行为型模式

来源:互联网 发布:ecshop2.7.3源码下载 编辑:程序博客网 时间:2024/06/05 03:55

行为型模式共有十一种:策略模式、模板方法模式、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
一、策略模式(strategy)
策略模式就是将具体实体中变化的行为抽离出来,封装成一个个的算法,然后再在具体实体的基类中,对每一个具体的行为的算法进行聚合。另外在基类中我们还可以每一个子类的不变的行为进行定义,而且我们在父类中在定义具体的行为的时候我们调用该行为对应的算法中的实现即可。以下是鸭子类的策略模式实现:
这里写图片描述
从图中就可以看出:
策略模式中主要涉及类之间的关系有:组合、继承、实现
策略模式推崇:多用组合少用继承,多用面向接口编程时候面向实现编程。

二、观察者模式(Observer)
观察者模式就是定义了主题对象(Subject)与观察者对象(Observer)之间的一对多依赖,这样一来,当一个主题对象状态改变的时候,依赖他的观察者就会收到通知并且自动更新自身状态。下面我们看一下JDK自带观察者模式的API:
这里写图片描述
从图中可以看出,每一个主题都是一个Observeable对象,每一个观察者都是一个Observer对象,而Observable对象中拥有一系列的Observer对象的引用,如果Observable对象自身的状态改变那么他就调用自身的notifyObservers方法来唤醒所有的观察者。以上描述的观察者模式是一种“推”的形式,即主题对象主动的将消息推送给观察者对象而观察者对象被动接受;其实相对的还有一种叫做“拉”的形式,即每一个观察者主动的想主题对象索取指定的消息而不是一次像“推”中一样一次接受所有的消息,这样主题对象就是被索取指定的消息。

再说说JDK中观察者模式对象的好处弊端,好处就是在JDK自带的API中“推”“拉”都支持,缺点就是我们可以看到JDK中的主题(Observable)是类而不是一个接口,所以缺陷很大。

观察者中体现了:封装变化、多用组合,少用继承、针对接口编程不正对实现编程、为交互对象之间的松耦合度设计而努力。

三、命令模式(Command)
http://www.cnblogs.com/wangjq/archive/2012/07/11/2585930.html

四、模板方法(Template)
在一个方法中定义一个算法的骨架,而将算法中某些具体的步骤延迟到子类中去实现。模板方法使得子类在不改变算法结构的情况下,重新定义算法中的某些步骤。

这里写图片描述
在模板方法中常常还会使用“钩子”,即一些boolean型返回值的方法或者使用一些状态变量,“钩子”的存在可以让子类有能力对算法的不同点进行挂钩,要不要挂钩都由子类来决定。

public abstract class CaffeineBeverageWithHook {    void prepareRecipe() {        boilWater();        brew();        pourInCup();        if (customerWantsCondiments()) {            addCondiments();        }    }    abstract void brew();    abstract void addCondiments();    void boilWater() {        System.out.println("Boiling water");    }    void pourInCup() {        System.out.println("Pouring into cup");    }    boolean customerWantsCondiments() {        return true;    }}

customerWantsCondiments方法就是一个钩子方法,即子类可以重写这样的方法,却决定要不要加载算法的某个步骤。
模板方法的还有一个准则是:超类应该能主控一切,当超类需要的时候会主动的去掉用子类中的方法,而不是由子类中的方法来调用父类中的方法。这个原则其实就是和依赖倒置原则很像,只要我们的编写代码是准守依赖倒置原则就行。

四、迭代器模式(Iterator)
提供了中一种顺序访问聚合内部元素的方法,而且还不暴露其内部的表示。
这里写图片描述

从图中可以看出来每一个具体的聚合对象都会实现一个产生能够遍历自身内部元素的Iterator对象,而这个实际的Iterator对象又是实现了一个叫做Iterator的接口。

另外我们其实可以让聚合实现他自己的内部的集合,以及相关的遍历操作,但是这样以来就会增加方法的个数,和聚合类中的可变因素。导致该类承担过多的责任。而我们在设计代码的时候应该尽量的使一个类只有一个引起变化的因素。

0 0
原创粉丝点击