外观模式.docx
《外观模式.docx》由会员分享，可在线阅读，更多相关《外观模式.docx（14页珍藏版）》请在冰豆网上搜索。
外观模式
开闭原则
就是说模块应对扩展开放，而对修改关闭。
模块应尽量在不修改原（是“原”，指原来的代码）代码的情况下进行扩展。
迪米特法则（LawofDemeter）又叫作最少知识原则（LeastKnowledgePrinciple简写LKP），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。
依赖倒置原则
A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。
B.抽象不应该依赖于具体，具体应该依赖于抽象。
php
/**
*外观模式示例
*为子系统中的一组接口提供一个一致的界面,定义一个高层接口,使得这一子系统更加的容易使用
*/
classSubSytem1
{
publicfunctionMethod1（）
{
echo"subsystem1method1
";
}
}
classSubSytem2
{
publicfunctionMethod2（）
{
echo"subsystem2method2
";
}
}
classSubSytem3
{
publicfunctionMethod3（）
{
echo"subsystem3method3
";
}
}
classFacade
{
private$_object1=null;
private$_object2=null;
private$_object3=null;
publicfunction__construct（）
{
$this->_object1=newSubSytem1（）;
$this->_object2=newSubSytem2（）;
$this->_object3=newSubSytem3（）;
}
publicfunctionMethodA（）{
echo"FacadeMethodA
";
$this->_object1->Method1（）;
$this->_object2->Method2（）;
}
publicfunctionMethodB（）{
echo"FacadeMethodB
";
$this->_object2->Method2（）;
$this->_object3->Method3（）;
}
}
//实例化
$objFacade=newFacade（）;
$objFacade->MethodA（）;
$objFacade->MethodB（）;
10.4外观模式
可能你曾经有过在项目中集成第三方代码的经历。
无论第三方代码是否面向对象，集成通常
都是巨大而且复杂的工作，很容易让人畏缩。
而对一个客户程序员来说，你的代码也可能是一个挑战，即使他可能仅需要访问很小一部分特性。
外观模式可以为复杂系统创建一个简单、清晰的接口。
10.4.1问题
在系统中总会逐渐形成大量仅在系统自身内部有用的代码。
系统也应该像类那样，提供定义
清晰的公共接口，并对外隐藏内部结构。
但是，系统中哪部分应该设置为公开，哪部分设置为隐藏并不容易决定。
当使用子系统（如Web论坛或者图库）的代码时，你也许会发现自己过于深入地调用子系统
的逻辑代码。
如果子系统代码总是在不断变化，而你的代码却又在许多不同地方与子系统代码交互，那么随着子系统的发展，你也许会发现维护代码变得非常困难。
类似地，当你创建自己的系统时，将不同的部分分层是很好的做法。
例如，你可能会把系统
分为应用逻辑层、数据库交互层和表现层等。
你应该尽可能地使这些分层互相独立，以便项目中某一部分的修改尽量不影响到其他地方。
如果某层中的代码与另一层的代码存在藕合的话，那么这个目标就很难达成了。
下面是一些故意让人混淆的不着边际的程序代码，其功能只是从文件中获取log信息并将它
转换为对象数据:
functiongetProductFileLines（$life）{
returnfile（$file）;
}
functiongetProductObjectFromId（$id,$productname）{
//一些数据库查询
returnnewProduct（$id,$productname）;
}
functiongetNameFromLine（$line）{
if（prep_match（“/.*-（.*）\s\d+/”，$line,$array））{
returnstr_replace（‘_’,’‘,$array[1]）;
}
return‘‘;
}
functiongetIDFromLine（$line）{
if（preg_match（“./^（\d{1,3}）-/”,$line,$array））{
return$array[1];
}
return-1;
}
classProduct{
public$id;
public$name;
function__construct（$id,$name）{
$this->id=$id;
$this->name=$name;
}
}
假设上面代码的内部其实是更复杂的，这样我们可以继续使用它们而非从头开始重写。
我们
的目的是将包含类似下面数据的文件转换为一个对象数组:
234-ladies_jumper55
532-gentshat44
而我们必须调用所有这些方法（注意为了简单起见，我们并不计算出价格的最终数字）:
$lines=getProductFileLines（‘test.txt’）;
$objects=array（）;
foreach（$linesas$line）{
$id=getIDFromLine（$line）;
$name=getNameFromLine（$line）;
$objects[$id]=getProductObjectFromID（$id,$name）;
}
如果在项目中像这样直接调用这些方法，那么我们的代码会和子系统紧紧地祸合在一起。
当
子系统变化时，或者我们决定将其与子系统完全断开时，代码就会出问题。
可见，我们需要在这些子系统和代码中引入一个入口。
10.4.2实现
下面这个简单的类为上面的过程式代码提供了一个接口:
classProductFacade{
private$products=array（）;
function__construct（$file）{
$this->file=$file;
$this->compile（）;
}
privatefunctioncompile（）{
$lines=getProductFileLines（$this->file）;
foreach（$linesas$line）{
$id=getIDFromLine（$line）:
$name=getNameFromLine（$line）;
$this->products[$id]=getProduetObjectFromID（$id,$name）;
}
}
functiongetProducts（）{
return$this->products;
}
functiongetProduct（$id）{
return$this->products[$id];
}
从客户端代码的角度来看，现在从一个log文件访问Product对象简单多了:
$facade=newProductFacade（‘test.txt’）;
$facade->getProduct（‘234’）;//id=’234’的$name
10.4.3效果
外观模式是一个十分简单的概念，它只是为一个分层或一个子系统创建一个单一的入口。
这会带来许多好处。
首先，有助于分离项目中的不同部分。
其次，对于客户端开发者来说，访问代码变得简洁，非常方便。
另外，由于只在一个地方调用子系统，减少了出错的可能性，并因此可以预估子系统修改带来的问题所在。
Facade类还能使客户端代码避免不正确地使用子系统中复杂的内部方法，从而减少错误的发生。
外观模式：
为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
它完美的体现了依赖倒转原则和迪米特法则的思想，所以是非常常用的模式之一。
首先，在设计初期阶段，应该要有意识的将不同的两个层分离，例如经典三层架构，数据访问层、业务逻辑层、表示层，他们层与层之间建立外观Facade，这样可以为复杂的子系统提供一个简单的接口，使得耦合大大降低。
增加外观Facade可以提供一个简单的接口，减少它们之间的依赖。
概述
外观模式，我们通过外观的包装，使应用程序只能看到外观对象，而不会看到具体的细节对象，这样无疑会降低应用程序的复杂度，并且提高了程序的可维护性。
例子1：
一个电源总开关可以控制四盏灯、一个风扇、一台空调和一台电视机的启动和关闭。
该电源总开关可以同时控制上述所有电器设备，电源总开关即为该系统的外观模式设计。
2.问题
为了降低复杂性，常常将系统划分为若干个子系统。
但是如何做到各个系统之间的通信和相互依赖关系达到最小呢？
3.解决方案
外观模式：
为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
引入外观角色之后，用户只需要直接与外观角色交互，用户与子系统之间的复杂关系由外观角色来实现，从而降低了系统的耦合度。
4.适用性
在遇到以下情况使用facade模式：
1）当你要为一个复杂子系统提供一个简单接口时。
子系统往往因为不断演化而变得越来越复杂。
大多数模式使用时都会产生更多更小的类。
这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。
facade可以提供一个简单的缺省视图，
这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过facade层。
2）客户程序与抽象类的实现部分之间存在着很大的依赖性。
引入facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
3）当你需要构建一个层次结构的子系统时，使用facade模式定义子系统中每层的入口点。
如果子系统之间是相互依赖的，你可以让它们仅通过facade进行通讯，从而简化了它们之间的依赖关系。
5.结构
6.构建模式的组成
外观角色（Facade）：
是模式的核心，他被客户client角色调用，知道各个子系统的功能。
同时根据客户角色已有的需求预订了几种功能组合\
子系统角色（Subsystemclasses）：
实现子系统的功能，并处理由Facade对象指派的任务。
对子系统而言，facade和client角色是未知的，没有Facade的任何相关信息；即没有指向Facade的实例。
客户角色（client）：
调用facade角色获得完成相应的功能。
7.效果
Facade模式有下面一些优点：
1）对客户屏蔽子系统组件，减少了客户处理的对象数目并使得子系统使用起来更加容易。
通过引入外观模式，客户代码将变得很简单，与之关联的对象也很少。
2）实现了子系统与客户之间的松耦合关系，这使得子系统的组件变化不会影响到调用它的客户类，只需要调整外观类即可。
3）降低了大型软件系统中的编译依赖性，并简化了系统在不同平台之间的移植过程，因为编译一个子系统一般不需要编译所有其他的子系统。
一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。
4）只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类。
Facade模式的缺点
1）不能很好地限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
2）在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。
8.实现
我们使用开关的例子;
php
/**
*外观模式
*
*/
classSwitchFacade
{
private$_light=null;//电灯
private$_ac=null;//空调
private$_fan=null;//电扇
private$_tv=null;//电视
publicfunction__construct（）
{
$this->_light=newLight（）;
$this->_fan=newFan（）;
$this->_ac=newAirConditioner（）;
$this->_tv=newTelevision（）;
}
/**
*晚上开电灯
*
*/
publicfunctionmethod1（$isOpen=1）{
if（$isOpen==1）{
$this->_light->on（）;
$this->_fan->on（）;
$this->_ac->on（）;
$this->_tv->on（）;
}else{
$this->_light->off（）;
$this->_fan->off（）;
$this->_ac->off（）;
$this->_tv->off（）;
}
}
/**
*白天不需要电灯
*
*/
publicfunctionmethod2（）{
if（$isOpen==1）{
$this->_fan->on（）;
$this->_ac->on（）;
$this->_tv->on（）;
}else{
$this->_fan->off（）;
$this->_ac->off（）;
$this->_tv->off（）;
}
}
}
/******************************************子系统类************/
/**
*
*/
classLight
{
private$_isOpen=0;
publicfunctionon（）{
echo'Lightisopen','
';
$this->_isOpen=1;
}
publicfunctionoff（）{
echo'Lightisoff','
';
$this->_isOpen=0;
}
}
classFan
{
private$_isOpen=0;
publicfunctionon（）{
echo'Fanisopen','
';
$this->_isOpen=1;
}
publicfunctionoff（）{
echo'Fanisoff','
';
$this->_isOpen=0;
}
}
classAirConditioner
{
private$_isOpen=0;
publicfunctionon（）{
echo'AirConditionerisopen','
';
$this->_isOpen=1;
}
publicfunctionoff（）{
echo'AirConditionerisoff','
';
$this->_isOpen=0;
}
}
classTelevision
{
private$_isOpen=0;
publicfunctionon（）{
echo'Televisionisopen','
';
$this->_isOpen=1;
}
publicfunctionoff（）{
echo'Televisionisoff','
';
$this->_isOpen=0;
}
}
/**
*客户类
*
*/
classclient{
staticfunctionopen（）{
$f=newSwitchFacade（）;
$f->method1
（1）;
}
staticfunctionclose（）{
$f=newSwitchFacade（）;
$f->method1（0）;
}
}
client:
:
open（）;
11.与其他相关模式
1）抽象工厂模式：
AbstractFactory式可以与Facade模式一起使用以提供一个接口，这一接口可用来以一种子系统独立的方式创建子系统对象。
AbstractFactory也可以代替Facade模式隐藏那些与平台相关的类。
2）中介模式：
Mediator模式与Facade模式的相似之处是，它抽象了一些已有的类的功能。
然而，Mediator的目的是对同事之间的任意通讯进行抽象，通常集中不属于任何单个对象的功能。
Mediator的同事对象知道中介者并与它通信，而不是直接与其他同类对象通信。
相对而言，Facade模式仅对子系统对象的接口进行抽象，从而使它们更容易使用；它并不定义新功能，子系统也不知道Facade的存在。
通常来讲，仅需要一个Facade对象，因此Facade对象通常属于Singleton模式。
3）Adapter模式：
适配器模式是将一个接口通过适配来间接转换为另一个接口。
外观模式的话，其主要是提供一个整洁的一致的接口给客户端。
12.总结
1）根据“单一职责原则”，在软件中将一个系统划分为若干个子系统有利于降低整个系统的复杂性，一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小，而达到该目标的途径之一就是引入一个外观对象，它为子系统的访问提供了一个简单而单一的入口。
2）外观模式也是“迪米特法则”的体现，通过引入一个新的外观类可以降低原有系统的复杂度，外观类充当了客户类与子系统类之间的“第三者”，同时降低客户类与子系统类的耦合度。
外观模式就是实现代码重构以便达到“迪米特法则”要求的一个强有力的武器。
3）外观模式要求一个子系统的外部与其内部的通信通过一个统一的外观对象进行，外观类将客户端与子系统的内部复杂性分隔开，使得客户端只需要与外观对象打交道，而不需要与子系统内部的很多对象打交道。
4）外观模式从很大程度上提高了客户端使用的便捷性，使得客户端无须关心子系统的工作细节，通过外观角色即可调用相关功能。
5）不要试图通过外观类为子系统增加新行为，不要通过继承一个外观类在子系统中加入新的行为，这种做法是错误的。
外观模式的用意是为子系统提供一个集中化和简化的沟通渠道，而不是向子系统加入新的行为，新的行为的增加应该通过修改原有子系统类或增加新的子系统类来实现，不能通过外观类来实现。
何时选用外观模式
如果希望为一个复杂的子系统提供一个简单接口的时候，从而简化客户端的应用
如果希望客户端程序和抽象类实现松散耦合，可以考虑使用外观模式
如果构建多层结构的系统，可以松散各层结构之间的依赖关系。
升级会员 