Facade 设计模式

目的

  • 在一个子系统的一组接口上提供一个统一的接口。Facade 设计模式定义了一个更高级别的接口,使子系统更容易使用。
  • 通过一个更加简洁的接口来包装一个复杂的子系统。

解决的问题

  客户端需要一个简化的接口来覆盖复杂的子系统的总体功能。

讨论

  Facade 设计模式通过一个单一的接口对象来封装一个复杂的子系统。这样减少了学习子系统复杂的学习曲线。它也实现了不同潜在客户端的低依赖性和解耦。换句话说,如果Facade 是唯一访问子系统的入口,那么它将限制一些特性何灵活性,那样则可能需要所谓的高级用户。

  Facade对象应该是一个相当简单的倡导者或是服务商。它不应该成为一个无所不知的圣人或“上帝”对象。

架构

  Facade 采取了一种"被神秘的事物遮蔽起来的东西"的策略, 然后插入了一个包装器来驯服无形的神秘的一团软件.

  SubsystemOne 与 SubsystemThree 并不与内部组件SubsytemTwo进行交互,而是通过 SubsystemTwoWrapper 这个 Facade(例如,更高层次的抽象)。

  

举例

  Facade 定义了统一的,高层次的接口以便于非常容易地使用子系统。举例,顾客经常会遇到这样的问题,如从商品目录中订购产品。当用户拨打电话并向客户前台沟通时,这时客户前台便充当Facade的角色,她提供了一个接口去查询订单执行部门,账单部门和商品运送部门。

总结

  1. 为子系统或组件确定一个简单,统一的接口。
  2. 设计一个"wrapper"类来封装子系统。
  3. Facade或wapper封装了组件的协作何复杂性,并委托合适的方法。
  4. 客户端只能通过Facade访问子系统。
  5. 考虑额外的Facade是否会增加价值。

规则

  Facade 定义了一个全新的接口,而适配器模式使用已存在的接口,适配器的目的是使两个存在的接口在一起工作而不是定义一个全新的接口。

  享元模式用来展示多个小的对象,而Facade用单一对象来呈现整个子系统。

  中介者模式与Facade类似,它是存在的class的一种抽象,抽象和集中任意同事对象之间的通信。它千篇一律的添加功能,并被同事对象所知和引用。相反,Facade 为子系统定义了一个简单的接口,它并不添加新的功能,并且不被子系统的类所知。

  抽象工厂模式可以作为Facade的一种替代来隐藏平台指定的类。

  Facade通常设计成单例模式因为只需要一个Facade对象。

  适配器模式和Facade都使用了封装器,但他们属于不同的封装。Facade的目的是产生一个简单的接口,而适配器的目的是设计一个存在的接口。Facade通常用来封装多个对象而适配器模式封装一个对象。Facade可以设计一个从前台到后台一个单一复杂的对象而适配器模式封装系统存在的对象。

时间: 2024-10-18 23:49:17

Facade 设计模式的相关文章

23种设计模式(1)-Facade设计模式

前记 曾经我遇见的一个需求是这样的,接口A有个方法void methodA(),类B需要实现接口A的methodA()方法,并且在类B中需要把methodA()方法内部处理逻辑获得的结果利用C类实例的某个方法进行持久化操作.由于技术功力尚浅,开始我左思右想就是不能实现这个需求.开始纠结于两个难题:1,methodA()方法返回值为void,我无法获得methodA()内部逻辑获得的数据,无法获得这些数据,也就无法利用持久化类C进行处理:2,methodA()方法入参又为空,我的持久化类C也无法注

Facade设计模式

Facade模式 Facade模式要求一个子系统的外部与其内部的通信必须通过一个统一的Facade对象进行.Facade模式提供一个高层次的接口,使得子系统更易于使用. 就如同医院的接待员一样,Facade模式的Facade类将客户端与子系统的内部复杂性分隔开,使得客户端只需要与Facade对象打交道,而不需要与子系统内部的很多对象打交道. 观察者模式的结构 Facade的几个要点 从客户程序的角度来看,Facade模式不仅简化了整个组件系统的接口,同时对于组件内部与外部客户程序来说,从某种程度

C++设计模式 之 “接口隔离” 模式:Facade、Proxy、Mediator、Adapter

“接口隔离”模式 在组建构建过程中,某些接口之间之间的依赖常常会带来很多问题.甚至根本无法实现.采用添加一层间接(稳定)接口,来隔离本来相互紧密关联的接口是一种常见的解决方案. 典型模式 #Facade #Proxy #Adapter #Mediator Part 1 Facade 门面模式(外观模式) 动机 #上述A方案的问题在于组件中各种复杂的子系统有了过多的耦合,随着外部客户程序和子系统的演化,这种过多的耦合面临很多变化的挑战. #如何简化外部客户程序和系统间的相互接口?如何将外部客户程序

Design Pattern Facade 门面设计模式

Facade设计模式主要作用是因为有个很难使用的类,然后要设计一个新类,整理好这个类,使得其更好使用. 比如有类如此: class MessyClass { char *name; public: MessyClass() : name(new char[3]) { for (int i = 0; i < 3; i++) { name[i] = ' '; } } ~MessyClass() { delete [] name; } void setFirstName(char a) { name[

C#设计模式之十外观模式(Facade Pattern)【结构型】

原文:C#设计模式之十外观模式(Facade Pattern)[结构型] 一.引言 快12点半了,要开始今天的写作了.很快,转眼设计模式已经写了十个了,今天我们要讲[结构型]设计模式的第五个模式,该模式是[外观模式],英文名称是:Facade Pattern.我们先从名字上来理解一下"外观模式".我看到了"外观"这个词语,就想到了"外表"这个词语,两者有着很相近的意思.就拿谈恋爱来说,"外表"很重要,如果第一眼看着很舒服.有眼

c#设计模式之:外观模式(Facade)

一.引言 在软件开发过程中,客户端程序经常会与复杂系统的内部子系统进行耦合,从而导致客户端程序随着子系统的变化而变化,然而为了将复杂系统的内部子系统与客户端之间的依赖解耦,从而就有了外观模式,也称作 "门面"模式.下面就具体介绍下外观模式. 二.外观模式的详细介绍 2.1定义 外观模式提供了一个统一的接口,用来访问子系统中的一群接口.外观定义了一个高层接口,让子系统更容易使用.使用外观模式时,我们创建了一个统一的类,用来包装子系统中一个或多个复杂的类,客户端可以直接通过外观类来调用内部

转23种设计模式

1.FACTORY 追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说"来四个鸡翅"就行了.麦当劳和肯德基就是生产鸡翅的Factory 工厂模式:客户类和工厂类分开.消费者任何时候需要某种产品,只需向工厂请求即可.消费者无须修改就可以接纳新产品.缺点是当产品修改时,工厂类也要做相应的修改.如:如何创建及如何向客户端提供. 2.BUILDER MM最爱听的就是"我爱你"这句话了,见到不同

自己用:23种设计模式+UML入门

学习设计模式之前,总是需要UML来辅助 UML的入门 设计模式的灵魂在于:灵活地多态,继承,封装. 把你所描述的类,抽象出一个关键词,形成父类,再把他继承.实现接口 但是继承还是不太好,因为增加了很多冗余成分,所以产生了组合. 运用组合实现了多态里面的东西 对话的形式来写技术可能会更好啊. 老板:小朱啊,今天给我讲一下责任链设计模式吧 我:责任链设计模式啊,我昨天试着写着写着也不知道哪里出错了,他是把策略这个关键词封装成一个数组,然后如果你想添加新的策略的时候,可以在里面直接添加一个策略元素,这

设计模式学习第一天:23种设计模式(全)

C#常见的设计模式 一.概要: 模式分为三种,设计模式.体系结构模式与惯用法.其中惯用法是一种语言紧密相关的模式,例如,定界加锁模式其实是一种惯用法. 在C#项目开发过程中,很多情况下您已经使用了某些模式,但或许您并不知道自己所使用的这种解决方案是一种已经被总结归纳的模式. 工厂.策略.桥接.模板方法.代理等等23种Gof经典模式是属于设计模式,设计模式的粒度相对较小,基本上用于提高模块内部的可扩展性和可维护性需求 三层.MVC.IoC/DI等属于体系结构模式,粒度比设计模式大,它是从项目的整体