责任链模式、中介者模式、观察者模式

食堂里厨房最远的窗口没熬白菜了，要告诉厨房，快送过来。
责任链模式：一个窗口一个窗口地传话，一直传到食堂，食堂一看不妙，赶快做好送过去。
中介者模式：专门派一个人负责传话，任何窗口没菜了，就要这个人赶快去厨房催。
观察者模式：厨房那边派一个盯着，看哪个窗口没菜了就开始大声嚷嚷。

举例：之所以要把这三个设计模式放在一块儿，是因为我在我的站里面结合这三者建立了一个好玩的东西，可以说是我的网站的核心所在。它解决了我的flash里面各个mc的通信问题。
比如，影片A放完了，要通知影片B开始播放，直接的做法是在A的最后一帧，写从A到B的相对路径或B的绝对路径，让B play()。这样做A和B的耦合性是相当高的，也就是说，相互依赖程度太高。运用设计模式的解决方案如下：

 

//MessageMap.as
//消息映射类
class MessageMap extends Object {
    var Message:String;
    var MessageWatcher:Function;
    var Target;
    var MessageList:Array;
    var Num_Msg:Number;
    function MessageMap() {
        Num_Msg = 0;
        MessageList = new Array();
        Message = "HANG_UP";
        MessageWatcher = function (prop, oldVar, newVar, Param) {
            for (var i = 0; i<Num_Msg+1; i++) {
                if (newVar == MessageList[i][0]) {
                    MessageList[i][1].apply(MessageList[i][3], MessageList[i][2]);
                    if (!MessageList[i][4]) {
                        MessageList.splice(i, 1);
                        Num_Msg--;
                        i-=1;
                    }
                }
            }
     
        };
        his.watch("Message", MessageWatcher, "test");
    }
    function SendMessage(Msg:String, mc:MovieClip) {
        Message = Msg;
    }
    function UpdateMessageMap(Msg:String, objFunction:Function, ArrayParam:Array, objRefer,IsMultiUsed:Boolean) {
        MessageList[Num_Msg] = new Array();
        MessageList[Num_Msg][0] = new String();
        MessageList[Num_Msg][0] = Msg;
        MessageList[Num_Msg][1] = new Function();
        MessageList[Num_Msg][1] = objFunction;
        MessageList[Num_Msg][2] = new Array();
        MessageList[Num_Msg][2] = ArrayParam;
        MessageList[Num_Msg][3] = objRefer;
        MessageList[Num_Msg][4] = IsMultiUsed;
        Num_Msg++;
    }
    function DeleteMessageMap(objRefer) {
        for (var i = 0; i<Num_Msg; i++) {
            if (MessageList[i][2] == objRefer) {
                MessageList.splice(i, 1);
                Num_Msg--;
            }
        }
    }
}
 
class SubTemplateMovie extends BaseMovie {
    var MovieRemoveFunction:Function;
    function SubTemplateMovie() {
        this.stop();
        MovieStartFunction = function () {
        Lock();
        this.play();
    };
    MovieEndFunction = function () {
        Lock();
        this.play();
    };
     
    MovieRemoveFunction = function () {
        this.stop();
        SendMsg("SUB_TEMPLATE_REMOVED", this);
        _parent.unloadMovie();
    };
    MovieMainFunction = function () {
        stop();
        SendMsg("SUB_TEMPLATE_OPEN", this);
        };
        UpdateMessage("LOADING_BAR_OVER", MovieStartFunction, null, this, false);
        UpdateMessage("BACK_TO_INDEX", MovieEndFunction, null, this, false);
    }
}

 

大概机制就是，影片提前提交一个数据结构，声明，如果有影片提交这条消息，就执行这条函数。原理在于，发送消息，实际上是把消息映射的一个变量赋值，由于消息映射继承自object类，可以用watch方法对该变量进行监视，一旦改变，在已经提交上来的消息映射列表里检查，如果有，执行对应函数。实际上这也造成了一定程度的耦合性，但是我们已经成功地把耦合性控制在了下级类，上级子类完全不用理会这一套消息机制的实现过程。

这个机制可以让我们对oop的真正目的有更深的看法。举例说明，影片A播放完了，就声明自己播放完了，至于我播完了你要干什么，不是我的事，我不控制你。所谓的降低耦合度是个相对概念，别忘了在计算机最底层，耦合度还是一样，cpu总是不断的直接或间接寻址，但我们需要做的是，改变系统的拓扑结构，把耦合度控制在某一个范围之内。

整个消息映射类相当于一个中介者，内部生成一个观察器，一旦触发消息，以责任链的方式执行。