敏捷软件开发 – FACADE模式和MEDIATOR模式

FACADE模式

  Db类使得Application类不需要了解System.Data命名空间中的内部细节。它把System.Data的所有通用性和复杂性隐藏在一个非常简单且特定的接口后面。

  像Db这样的FACADE类对System.Data的使用施加了许多规约。它知道如何初始化和关闭数据库连接。它知道如何将ProductData的成员变量转换成数据库字段,或反之。它知道如何去构建合适的查询和命令去操纵数据库。它对用户隐藏了所有的复杂性。在Application看来,System.Data是不存在的,它隐藏在FACADE后面。

  使用FACADE模式意味着开发人员已经接受了所有数据库调用都要通过Db类的约定。如果Application的任意一部分代码越过该FACADE直接去访问System.Data,那么就违反了该约定。像这样,该FACADE对Application施加了它的规约。基于约定,Db类称为了System.Data的唯一代理。

  可以使用FACADE对程序的任何部分进行隐藏。不过,最常见的做法是使用FACADE来隐藏数据库,因此该模式也称为TABLE DATA GATEWAY。

MEDIATOR模式

  MEDIATOR模式同样也是施加规约。不过,FACADE模式是以可见且强制的方式施加它的规约,而MEDIATOR模式则是以隐藏切自由的方式来施加它的规约的。

using System;
using System.win.Windows.Form;

public class QuickEntryMediator
{
    private TextBox itsTextField;
    private ListBox itsList;

    public QuickEntryMediator(TextBox t, ListBox l)
    {
        itsTextField = t;
        itsList = l;

        itsTextField.TextChagned += new EventHandler(TextFieldChanged);
    }

    private void TextFieldChanged(object sender, EventArgs args)
    {
        String prefix = itsTextField.getText();

        if (prefix.length() == 0)
        {
            itsList.ClearSelection();
            return;
        }

        ListBox.ObjectCollection listItems = itsList.Items;
        boolean found = false;
        for (int i = 0; found == false && i < listItems.Count; i++)
        {
            Object o = listItems[i];
            String s = o.ToString();
            if (s.StartsWith(prefix))
            {
                itsList.SetSelected(i, true);
                found = true;
            }
        }

        if (!found)
        {
            itsList.ClearSelection();
        }
    }
}

  ListBox和TextBox的使用者并不知道该MEDIATOR的存在。它安静的呆着,把它的规约施加在那些对象上,而无需它们的允许或知晓。

结论

  如果规约涉及的范围广泛并且可见,那么可以使用FACADE模式从上施加规约。另一方面,如果规约设计的范围较小并且可以自由定制,那么MEDIATOR模式是更好的选择。FACADE模式通常是约定的关注点。每个人都同意去使用该FACADE而不是隐藏于其下的对象。另一方面,MEDIATOR则对用户是隐藏的。它的规约是既成事实而不是一项约定事务。

摘录自:[美]RobertC.Martin、MicahMartin著,邓辉、孙鸣译 敏捷软件开发原则、模式与实践(C#版修订版) [M]、人民邮电出版社,2013、240-243、

时间: 2024-11-19 01:19:19

敏捷软件开发 – FACADE模式和MEDIATOR模式的相关文章

敏捷软件开发(3)---COMMAND 模式 &amp; Active Object 模式

COMMAND 模式 command模式非常简单,简单到你无法想象的地方. public interface Command { void execute(); } 这就是一个command模式的样子.也许你会觉得,这有点多此一举吗.但是当你使用他的时候,command模式就会闪现光华. 这样一个场景:经理张三叫leader王二去开发一个项目, 王二就安排李四 去开发这个功能A. 李四何时执行,怎么执行就是他自己的事情了. UML图如上所示: 代码如下: public interface Com

敏捷软件开发(1)--- STATE 模式

如果状态在运行过程中,不停的切换和改变,我们怎么办? 状态的迁移是我们生活和工程中非常普遍的一个概念.于是在数学上有一种理论来分析和解决这个问题. 有限状态机理论是一个非常成熟的理论,所有动作和流程的迁移可以归结为状态的迁移. 这个理论的前提是: 状态的数目是确定的,或者说是有限的. 状态的迁移方向是固定的,也就是有向的. 状态存储关于过去的信息,就是说:它反映从系统开始到现在时刻的输入变化.转移指示状态变更,并且用必须满足来确使转移发生的条件来描述它.动作是在给定时刻要进行的活动的描述.有多种

敏捷软件开发:原则、模式与实践——第10章 LSP:Liskov替换原则

第10章 LSP:Liskov替换原则    Liskov替换原则:子类型(subtype)必须能够替换掉它们的基类型(base type). 10.1 违反LSP的情形 10.1.1 简单例子 对LSP的违反导致了OCP的违反: struct Point { double x, y;} public enum ShapeType { square, circle }; public class Shape { private ShapeType type; public Shape(Shape

敏捷软件开发:原则、模式与实践——第11章 DIP:依赖倒置原则

第11章 DIP:依赖倒置原则 DIP:依赖倒置原则: a.高层模块不应该依赖于低层模块.二者都应该依赖于抽象. b.抽象不应该依赖于细节.细节应该依赖于抽象. 11.1 层次化 下图展示了一个简单的层次化方案: 高层的Policy层使用了低层的Mechanism层,而Mechanism层又使用了更细节的Utility层.它存在一个隐伏的错误特征,那就是:Policy层对于其下一直到Utility层的改动都是敏感的.依赖关系是传递的. 下图展示了一个更为合适的模型: 每个较高层次都为它所需要的服

敏捷软件开发:原则、模式与实践——第5章 重构

第5章 重构 在Martin Fowler的名著<重构>一书中,他把重构定义为:“在不改变代码外在行为的前提下对对代码做出修改,以改进代码内部结构的过程.”可是我们为什么要改进已经能够工作的代码结构呢?我们不是都知道“如果它没有坏,就不要去修理它!”吗? 每一个软件模块都有3项职责.第一个职责是它运行起来所完成的功能.这也是该模块得以存在的原因.第二个职责是它要应对的变化.几乎所有的模块在它们的生命周期中都要变化,开发者有责任保证这种变化应尽可能地简单.一个难以改变的模块是有问题的,即使能够工

敏捷软件开发 – ABSTRACT SERVER模式、ADAPTER模式和BRIDGE模式

设计运行在简易台灯中的软件.台灯由一个开关和一盏灯组成.可以询问开关是开着还是关着,也可以让灯打开或者关闭. 下面设计了一个简易的模型.Switch对象可以轮询实际开关的状态,并且可以发送相应的turnOn和turnOff消息给Light. 这个设计违反了两个设计原则:依赖倒置(DIP)和开放-封闭(OCP).对DIP的违反是明显的,Switch依赖了具体类Light.DIP告诉我们要优先依赖于抽象类.对OCP的违反虽然没有那么明显,但是更加切中要害.我们之所以不喜欢这个设计是因为它迫使我们在任

敏捷软件开发:原则、模式与实践——第16章 对象图、第17章 用例、第18章 顺序图

第16章 对象图 有时,呈现出系统在某个特定时刻的状态是非常有用的.和一个正在运行系统的快照类似.UML对象图展示了在一个给定时刻获取到的对象.关系和属性值. 不过,你应该对花太多的对象图保持警惕.在大部分的情况下,它们都可以从相应的类图中直接推导出来,因此没有多少用处. 第17章 用例 在所有的UML图中,用例图是最令人迷惑也是最没有用处的.我建议出来系统边界外,忽略掉所有其他的图.系统边界图示例如下: 大矩形是系统边界.矩形内的所有东西都是将要开发的系统的组成部分.矩形外面是操作系统的参与者

敏捷软件开发:原则、模式与实践——第15章 状态图

第15章 状态图 在描述有限状态机(FSM)方面,UML提供个丰富的符合. 15.1 基础知识 下图是一个简单的状态迁移图(STD),该图描述了控制用户登录到系统的FSM.圆角矩形表状态.上层格间放置每个状态的名字.下层格间中放置的是一些特定动作,表示当进入或退出该状态时要做什么. 图中左上角的实心圆称为初始伪状态.FSM从这个伪状态开始,根据变迁规则进行转移. 15.1.1 特定事件 状态图的下层格间含有事件/动作对. 15.1.2 超状态 当许多状态以同样的方式响应某些同样的事件时,使用超状

敏捷软件开发:原则、模式与实践——第20章 咖啡的启示

第20章 咖啡的启示 这个例子对于教学有很多好处.它短小.易于理解并且展示了如何应用面向对象设计原则去管理依赖和分类关注点.但从另一方面来说,它的短小也意味着这种分离带来的好处可能抵不过其成本.就当做一个设计思路来看吧. 20.1 Mark IV型专用咖啡机20.1.1 规格说明书 Mark IV型专用咖啡机一次可以产出12杯咖啡.使用者把过滤器放置在支架上,在其中装入研磨好的咖啡,然后把支架推入其容器中.接着,使用者向滤水器中倒入12杯水并按下冲煮(Brew)按钮.水一直加热到沸腾.不断产生的