外观模式及php实现

外观模式:
  外观模式(Facade Pattern):外部与一个子系统的通信必须通过一个统一的外观对象进行,为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。外观模式又称为门面模式,它是一种对象结构型模式。

目的:
  1、为一个复杂子系统提供简单的接口
  2、减少客户端和子系统的耦合

外观模式包含如下角色:
  Facade: 外观角色
  SubSystem:子系统角色

UML图:

  

模式分析:
  根据“单一职责原则”,在软件中将一个系统划分为若干个子系统有利于降低整个系统的复杂性,一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小,而达到该目标的途径之一就是引入一个外观对象,它为子系统的访问提供了一个简单而单一的入口
  外观模式也是“迪米特法则”的体现,通过引入一个新的外观类可以降低原有系统的复杂度,同时降低客户类与子系统类的耦合度。
  外观模式要求一个子系统的外部与其内部的通信通过一个统一的外观对象进行,外观类将客户端与子系统的内部复杂性分隔开,使得客户端只需要与外观对象打交道,而不需要与子系统内部的很多对象打交道。
  外观模式的目的在于降低系统的复杂程度。
  外观模式从很大程度上提高了客户端使用的便捷性,使得客户端无须关心子系统的工作细节,通过外观角色即可调用相关功能。

优点:
  对客户屏蔽子系统组件,减少了客户处理的对象数目并使得子系统使用起来更加容易。通过引入外观模式,客户代码将变得很简单,与之关联的对象也很少。
  实现了子系统与客户之间的松耦合关系,这使得子系统的组件变化不会影响到调用它的客户类,只需要调整外观类即可。
  降低了大型软件系统中的编译依赖性,并简化了系统在不同平台之间的移植过程,因为编译一个子系统一般不需要编译所有其他的子系统。一个子系统的修改对其他子系统没有任何影响,而且子系统内部变化也不会影响到外观对象。
  只是提供了一个访问子系统的统一入口,并不影响用户直接使用子系统类

缺点
  不能很好地限制客户使用子系统类,如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
  在不引入抽象外观类的情况下,增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”。

适用环境:
  当要为一个复杂子系统提供一个简单接口时可以使用外观模式。该接口可以满足大多数用户的需求,而且用户也可以越过外观类直接访问子系统。
  客户程序与多个子系统之间存在很大的依赖性。引入外观类将子系统与客户以及其他子系统解耦,可以提高子系统的独立性和可移植性。
  在层次化结构中,可以使用外观模式定义系统中每一层的入口,层与层之间不直接产生联系,而通过外观类建立联系,降低层之间的耦合度。

代码实现:

<?php

//子系统角色
class subSystemOne{
   function mothedOne(){
       echo "方法一";
   }
}
class subSystemTwo{
   function mothedTwo(){
       echo "方法二";
   }
}
class subSystemThree{
   function mothedThree(){
       echo "方法三";
   }
}

//外观角色
class Facade{
    private $subSystemOne = null;
    private $subSystemTwo = null;
    private $subSystemThree =null;

    function __construct(){
        $this->subSystemOne =new subSystemOne();
        $this->subSystemTwo =new subSystemTwo();
        $this->subSystemThree =new subSystemThree();
    }

    function mothedA(){
        $this->subSystemOne->mothedOne();
    }
    function mothedB(){
        $this->subSystemOne->mothedTwo();
    }
    function mothedC(){
        $this->subSystemOne->mothedThree();
    }
    function mothedD(){
        $this->subSystemOne->mothedOne();
        $this->subSystemOne->mothedTwo();
        $this->subSystemOne->mothedThree();
    }
}

//测试
$facade = new Facade();
$facade->mothedA();
$facade->mothedB();
$facade->mothedC();
$facade->mothedD();
?>
时间: 2024-10-11 05:45:07

外观模式及php实现的相关文章

2 结构型模式之 - 外观模式

外观模式的介绍:外观模式在开发运用中的频率非常高,尤其是现阶段各种第三方SDK充斥在我们的周边,而这些SDK很大概率会使用外观模式,通过一个外观类使得整个系统的接口只有一个统一的高层接口,这样就能够降低用户使用的复杂度,也对用户屏蔽了很多实现细节,当然 ,在我们的开发过程中,外观模式也是我们封装API的常用手段,例如网络模块,ImageLoader模块等.可能你已经在开发中运用过无数次外观模式,只是没有理论层面上认识它,本章我们就从理论与实践相结合的方式来理解外观模式 外观模式的定义: 要求一个

设计模式(九):外观模式

一.概述 外观模式提供了一个统一的接口,用来访问子系统中的一群接口.外观定义了一个高层接口,让子系统更容易使用. 二.解决问题 在上一讲中,我们学习了适配器模式,它是用来转换一个接口的,而外观模式可以理解为转换一群接口,客户只要调用一个接口,而不用调用多个接口就可以达到目的.想想现实生活中例子,我们在pc上安装软件的时候经常有默认安装或者是一键安装选项(省去选择安装目录.安装的组件等等),还有就是手机的重启功能(把关机和启动合为一个操作).总之,外观模式就是解决多个复杂接口带来的使用困难,起到简

java/android 设计模式学习笔记(14)---外观模式

这篇博客来介绍外观模式(Facade Pattern),外观模式也称为门面模式,它在开发过程中运用频率非常高,尤其是第三方 SDK 基本很大概率都会使用外观模式.通过一个外观类使得整个子系统只有一个统一的高层的接口,这样能够降低用户的使用成本,也对用户屏蔽了很多实现细节.当然,在我们的开发过程中,外观模式也是我们封装 API 的常用手段,例如网络模块.ImageLoader 模块等.其实我们在开发过程中可能已经使用过很多次外观模式,只是没有从理论层面去了解它. 转载请注明出处:http://bl

设计模式(八):外观模式

这个模式是我觉得最好懂的模式. 外观(Facade)模式 定义: 外观模式是一种结构型模式.它为更大的代码体提供了一个方便的高层次接口,能够隐藏其底层的真实复杂性.简单说就是——小接口有大智慧. 例子: 使用jQuery的$(el).css()或$(el).animate()方法时,实际上我们是在使用Facade:一种更简单的公有接口,使我们不必手动在jQuery核心调用很多内部方法以便实现某些行为. 优点: 1. 易于使用. 2. 实现该模式时占用空间小. 3. 调用者与底层代码解耦. 缺点:

外观模式

1.定义 外观模式(Facade-Pattern):提供了一个统一的接口,用来访问子系统中的一群接口外观定义了一个高层接口,让子系统更容易使用. 2.示例:家庭影院 3.外观模式特点 要使用外观模式,需创建一个接口简化并且统一的类,用来包装系统中一个或多个复杂的类.它也是一个改变接口的类(装饰模式,适配器模式),只不过它改变接口的原因是为了简化接口,将一个或数个类的复杂的一切隐藏在背后,只显露出一个干净美好的外观. 外观模式通过实现一个提供更合理的接口的外观类,将一个复杂的子系统变得容易使用.如

java演示facade(外观)模式

实际应用中,原来的代码涉及多个子系统时,重新进行类的设计,将原来分散在源码中的类结构及方法重新组合,形成新的.统一的接口,供上层应用使用. Facade所面对的往往是多个类或其它程序单元,通过重新组合各类及程序单元,对外提供统一的接口/界面. 在遇到以下情况使用Facade模式: 1.当你要为一个复杂子系统提供一个简单接口时.子系统往往因为不断演化而变得越来越复杂.大多数模式使用时都会产生更多更小的类.这使得子系 统更具可重用性,也更容易对子系统进行定制,但这也给那些不需要定制子系统的用户带来一

C++设计模式之外观模式(三)

3.外观模式总结 引入了外观类,解除了客户类与子系统的耦合性.客户类不需要直接操作子系统,而是由外观类负责处理,对客户端而言是透明的,客户类只需要操作外观类就可以了,符合"迪迷特法则".如果多个地方需要Facade,也就是说外观可以实现功能的共享,也就是实现复用,同样的调用代码只用在Facade里面写一次就好了,不用在多个调用的地方重复写.如果某个系统模块需要修改,只需要修改这个系统模块就可以了,对客户端无影响,维护性好.还有一个潜在好处,对使用Facade的人员来说,Facade节省

设计模式之适配器模式与外观模式

适配器模式将一个类的接口,转换成客户期望的另一个接口.适配器让原本接口不兼容的类可以合作无间. 例子:火鸡变鸭子. 先定义一个鸭子接口. package cn.sp.test06; /** * 鸭子 * @author 2YSP * */ public interface Duck { //具备呱呱叫 和 飞行的能力 public void quack(); public void fly(); } package cn.sp.test06; /** * 绿头鸭是鸭子的子类 * @author

《Head First 设计模式》之适配器模式与外观模式

适配器模式(Adapter) 适配器(adapter-pattern):将一个类的接口,转换成客户期望的另一个接口.适配器让原来接口不兼容的类可以合作无间.两种形式: 对象适配器(组合) 类适配器(多重继承):在Java中不能实现 外观(facade-pattern):提供了一个统一的接口,用来访问子系统中的一群接口.外观定义了一个高层接口,让子系统更容易使用. 原则 最少知识原则:只和你的密友谈话 要点: 当需要使用一个现有的类而其接口不符合需要时,使用适配器.适配器改变接口以符合客户期望.

大话设计模式读书笔记--8.外观模式

外观模式的用意是为子系统提供一个集中化和简化的沟通渠道,而不是向子系统加入新的行为 生活中的例子: 一个电源总开关可以控制四盏灯.一个风扇.一台空调和一台电视机的启动和关闭.该电源总开关可以同时控制上述所有电器设备,电源总开关即为该系统的外观模式设计 定义 定义: 为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这一接口使得这一子系统更加容易使用 结构图 Facade: 是模式的核心,指导所有子系统的功能, 可根据客户端的需求定制功能组合 SubSystemOne: 实现子系统