迪米特法则(最少知识原则)
- 一个软件实体应当尽可能少的与其他实体发生相互作用。
外观模式核心
-
为子系统提供统一的入口,封装子系统的复杂性,便于客户端调用。
外观模式
package facade;
// 四个子系统类
class SubSystemOne{
public void methodOne(){
System.out.println("子系统方法一");
}
}
class SubSystemTwo{
public void methodTwo(){
System.out.println("子系统方法二");
}
}
class SubSystemThree{
public void methodThree(){
System.out.println("子系统方法三");
}
}
class SubSystemFour{
public void methodFour(){
System.out.println("子系统方法四");
}
}
// 外观类
public class Facade {
private SubSystemOne one;
private SubSystemTwo two;
private SubSystemThree three;
private SubSystemFour four;
public Facade() {
this.one = new SubSystemOne();
this.two = new SubSystemTwo();
this.three = new SubSystemThree();
this.four = new SubSystemFour();
}
public void methodA(){
one.methodOne();
two.methodTwo();
four.methodFour();
}
public void methodB(){
two.methodTwo();
three.methodThree();
}
}
package facade;
public class Client {
public static void main(String[] args) {
Facade facade = new Facade();
facade.methodA();
facade.methodB();
}
}
开发中常见的场景
频率很高。哪里都会遇到。各种技术和框架,都有外观模式的使用。
何时使用外观模式
- 再设计初期阶段,应该有意识的将不同的两个层分离,比如经典的三层架构,就需要考虑在数据访问层和业务逻辑层、业务逻辑层和表示层的层与层之间建立外观Facade，这样可以为复杂的子系统提供一个简单的接口，使得耦合大大降低。
- 再开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，大多数的模式使用时也都会产生很多很小的类，这本是好事，但也给外部调用它们的用户程序带来了使用上的困难，增加外观Facade可以提供一个简单的接口，减少它们之间的依赖。
- 在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，但因为它包含非常重要的功能，新的需求开发必须依赖于它。此时用外观模式Facade也是非常合适的。你可以为新系统开发一个外观Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统于Facade对象交互，Facade于遗留代码交互所有复杂的工作。
