敏捷开发笔记(第15章节)--FACADE模式和MEDIATOR模式

 1：PDF上传链接

【免费】敏捷软件开发(原则模式与实践)资源-CSDN文库

 尊贵的符号外表下，隐藏着卑劣的梦想。
                                                                                                                        -Mason Cooley

        本章中论述的两个模式有着共同的目的。它们都把某种策略(pocy)施加到另外一组对象上。
FACADE模式从上面施加策略，而MEDIATOR模式则从下面施加策略。FACADE模式的使用是明显且受限的，而MEDIATOR模式的使用则是不明显且不受限制的。

15.1 FACADE模式

        当想要为一组具有复杂且全面的接口的对象提供一个简单且特定的接口时，可以使用FACADE模式。例如，考虑程序26.9中的DB.java。该类为java.sql包中复杂且全面的类接口提供了一个非常简单的、特定于ProductData的接口。图15.1展示了这个结构。

图15.1DB FACADE 

        请注意，DB类使得Application类不需要了解java.sql包的内部细节。它把java.sq包的所有全面性和复杂性隐藏在一个非常简单且特定的接口后面。
        像DB这样的FACADE类对java.sql包的使用施加了许多策略。它知道如何去初始化和关闭数据库连接。它知道如何将ProductData的成员变量转换成数据库字段，或反之。它知道如何去构建合适的查询和命令去操纵数据库。它对用户隐藏了所有的复杂性。在Application看来，java.sql包是不存在的：它隐藏在FACADE后面。
        使用FACADE模式意味着开发人员已经接受了所有数据库调用都要通过DB类的约定。如果Applilcation的任意一部分代码越过该FACADE直接去访问java.sql,那么就违反了该约定。像这样，该FACADE对application施加了它的策略。基于约定，DB类成为了java.sql包的惟一代理(broker)。

15.2 MEDIATOR模式

        MEDIATOR模式同样也施加策略。不过，FACADE模式是以明显且受限的方式来施加它的策略，而MEDIATOR模式则是以隐藏且不受限的方式来施加它的策略。

15.3 结论

        如果策略涉及范围广泛并且可见，那么可以使用FACACE模式从上面施加该策略。另一方面，如果策略隐蔽并且有针对性，那么MEDIATOR模式是更好的选择。Facades通常是约定的关注点。每个人都同意去使用该facade而不是隐藏于其下的对象。另一方面，Mediator则对用户是隐藏的。它的策略是既成事实的而不是一项约定事务。