IronMan之外观
接着上篇观察者内容的“剧情”，没看过的朋友也没关系，篇幅之间有衔接的关系但是影响不大。
需求:
为"兵工厂"提供各种支持,生产了各式各样的"IronMan",因为"IronMan"是智能的，它有一个"总控中心"，用来使用各个部件的功能，以及 其它功能的使用。"总控中心"也是用户在穿戴时显示在用户眼前的UI。
现在遇到一个问题，大家都来看一下，"IronMan"在穿戴好启动的时候，"总控"会让"IronMan"各个部件自动自检，自检完成后要在UI那显示出 自检的结果，当然自检的顺序可以是固定的也可以是不固定的，随便怎么检查，最终是要返回所有的部件自检结果。
假设的基础结构情况：
1 public class Component1
2 {
3 public void Component1Inspection()
4 {
5 //部件1自检
6 }
7 }
8 public class Component2
9 {
10 public void Component2Inspection()
11 {
12 //部件2自检
13 }
14 }
15 public class Component3
16 {
17 public void Component3Inspection()
18 {
19 //部件3自检
20 }
21 }假设还有若干个部件，按照平常的状态它们都要一一的自检。在这样的情况下使用的代码则是这样的:
1 ///2 /// 控制中心 3 /// 4 public class CenterController 5 { 6 ///7 /// 启动时的行为 8 /// 9 public void StartBef() 10 { 11 Component1 com1 = new Component1(); 12 com1.Component1Inspection(); 13 Component2 com2 = new Component2(); 14 com2.Component2Inspection(); 15 Component3 com3 = new Component3(); 16 com3.Component3Inspection(); 17 } 18 }
这样做下去的话是不是很费事，而且控制中心和部件的耦合度也比较大，如果部件个数自检的修改也会牵扯到控制中心内部的修改，这样的行为是违反设计原则的。
外观模式（Facade）的定义:为子系统中的一组接口提供一个一致的界面，用来访问子系统中的一群接口。
根据设计模式的中心思想来做修改,把部件自检的操作都封装在单独的一层中,让控制中心和部件解耦,我们来看一下修改后的代码:
1 public class Facade
2 {
3 //自检
4 public void Inspection()
5 {
6 Component1 com1 = new Component1();
7 com1.Component1Inspection();
8 Component2 com2 = new Component2();
9 com2.Component2Inspection();
10 Component3 com3 = new Component3();
11 com3.Component3Inspection();
12 }
13 }这样定义了外观类过后，再来看一下控制中心的调用修改：
1 ///2 /// 控制中心 3 /// 4 public class CenterController 5 { 6 ///7 /// 启动时的行为 8 /// 9 public void StartBef() 10 { 11 Facade facade = new Facade(); 12 facade.Inspection(); 13 } 14 }
在两层中间加入了Facade这一层，耦合的问题就迎刃而解，好像好多解耦的方式都是这样的。
END 下一篇是关于命令模式的说明。
另外有需要云服务器可以了解下创新互联scvps.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。