设计模式之外观模式

/*迪米特法则:如果两个类不必彼此直接同行,那么这两个内就不应当发生直接的相互作用,如果其中一个类需要调用另外一个类
 * 的 某一个方法的话,可以通过第三者转发这个调用.
 * 根本思想:强调类之间的松耦合.
 * 程序设计中类之间的耦合越弱,越有利于复用,一个处在弱耦合的类被修改,不会队友关系的类造成波及,信息的隐藏
 * 有利于类的复用.
 * */
/*Facade: 外观类,知道哪些子系统负责处理请求,见客户的请求代理给适当的子系统.(他需要了解所有的子系统的方法或属性,进行组合,以备外界调用.)
 * 外观模式: 为子系统中的一组提供一个一直的界面(facade类),此模式定义了一个高层接口,这个接口使得这一子系统
 * 更加容易使用.
 * 注:首先在设计初期阶段,应该要有意识的将不同的两个层分离,比如经典的三层架构(mvc),
 * 其次,在开发阶段子系统玩玩因为不断的重构演化而便得越来越复杂,增加外观Facade可以提供一个简单的接口减少它们之间的依赖,
 * 最后,在维护一个遗留的大型系统时,这个系统已经非常难以维护和扩展,这是要开发一个新的子系统,可以为系统卡发一个外观(facade类),来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口,
 * 让新系统与facade对象交互,facade与遗留大妈交互所有的复杂工作.
 * 跟代理模式有啥区别?
 * 个人觉得,代理模式只是为一个类进行代理,而外观模式为多个类进行代理.

 * */

package com.zwy;public class FacadeTest {public static void main(String[] args) {Facade facade = new Facade();facade.FacadeA();}}class SubSystemOne {public void MehthodOne() {System.out.println(this.getClass().getName() +"MehthodOne 执行");}}class SubSystemTwo {public void MethodTwo() {System.out.println(this.getClass().getName() + "MethodTwo 执行");}}class Facade {private  SubSystemOne one ;private SubSystemTwo two ;public Facade() {this.one = new SubSystemOne();this.two = new SubSystemTwo();}public void FacadeA() {one.MehthodOne();two.MethodTwo();}}