IronMan之外观

接着上篇观察者内容的“剧情”，没看过的朋友也没关系，篇幅之间有衔接的关系但是影响不大。

需求:

为"兵工厂"提供各种支持,生产了各式各样的"IronMan",因为"IronMan"是智能的，它有一个"总控中心"，用来使用各个部件的功能，以及其它功能的使用。"总控中心"也是用户在穿戴时显示在用户眼前的UI。

现在遇到一个问题，大家都来看一下，"IronMan"在穿戴好启动的时候，"总控"会让"IronMan"各个部件自动自检，自检完成后要在UI那显示出自检的结果，当然自检的顺序可以是固定的也可以是不固定的，随便怎么检查，最终是要返回所有的部件自检结果。

假设的基础结构情况：


1publicclassComponent12{3publicvoidComponent1Inspection()4{5//部件1自检6}7}8publicclassComponent29{10publicvoidComponent2Inspection()11{12//部件2自检13}14}15publicclassComponent316{17publicvoidComponent3Inspection()18{19//部件3自检20}21}


假设还有若干个部件，按照平常的状态它们都要一一的自检。在这样的情况下使用的代码则是这样的:


1///<summary>2///控制中心3///</summary>4publicclassCenterController5{6///<summary>7///启动时的行为8///</summary>9publicvoidStartBef()10{11Component1com1=newComponent1();12com1.Component1Inspection();13Component2com2=newComponent2();14com2.Component2Inspection();15Component3com3=newComponent3();16com3.Component3Inspection();17}18}


这样做下去的话是不是很费事，而且控制中心和部件的耦合度也比较大，如果部件个数自检的修改也会牵扯到控制中心内部的修改，这样的行为是违反设计原则的。

外观模式（Facade）的定义:为子系统中的一组接口提供一个一致的界面，用来访问子系统中的一群接口。

根据设计模式的中心思想来做修改,把部件自检的操作都封装在单独的一层中,让控制中心和部件解耦,我们来看一下修改后的代码:


1publicclassFacade2{3//自检4publicvoidInspection()5{6Component1com1=newComponent1();7com1.Component1Inspection();8Component2com2=newComponent2();9com2.Component2Inspection();10Component3com3=newComponent3();11com3.Component3Inspection();12}13}


这样定义了外观类过后，再来看一下控制中心的调用修改：

1///<summary>2///控制中心3///</summary>4publicclassCenterController5{6///<summary>7///启动时的行为8///</summary>9publicvoidStartBef()10{11Facadefacade=newFacade();12facade.Inspection();13}14}


在两层中间加入了Facade这一层，耦合的问题就迎刃而解，好像好多解耦的方式都是这样的。

END下一篇是关于命令模式的说明。