设计模式之外观模式

/*迪米特法则:如果两个类不必彼此直接同行,那么这两个内就不应当发生直接的相互作用,如果其中一个类需要调用另外一个类

* 的 某一个方法的话,可以通过第三者转发这个调用.

* 根本思想:强调类之间的松耦合.

* 程序设计中类之间的耦合越弱,越有利于复用,一个处在弱耦合的类被修改,不会队友关系的类造成波及,信息的隐藏

* 有利于类的复用.

* */

/*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();
}
}