wordpress建站教程 贴吧,备案域名多少钱,不会网站维护可以做吗,怎么注册公司需要多少钱1、简介
1.1、概述
在软件开发中#xff0c;有时候为了完成一项较为复杂的功能#xff0c;一个类需要和多个其他业务类交互#xff0c;而这些需要交互的业务类经常会作为一个完整的整体出现#xff0c;由于涉及的类比较多#xff0c;导致使用时代码较为复杂。此时#…1、简介
1.1、概述
在软件开发中有时候为了完成一项较为复杂的功能一个类需要和多个其他业务类交互而这些需要交互的业务类经常会作为一个完整的整体出现由于涉及的类比较多导致使用时代码较为复杂。此时特别需要一个类似服务员一样的角色由它来负责和多个业务类进行交互而使用这些业务类的类只需和该类交互即可。外观模式通过引入一个新的外观类来实现该功能。外观类充当了软件系统中的“服务员”它为多个业务类的调用提供了一个统一的入口简化了类与类之间的交互。
根据单一职责原则在软件中将一个系统划分为若干个子系统Subsystem有利于降低整个系统的复杂性。一个常见的设计目标是使客户类与子系统之间的通信和相互依赖关系达到最小而达到该目标的途径之一就是引入一个外观Facade角色它为子系统的访问提供了一个简单而单一的入口。外观模式也是迪米特法则的体现通过引入一个新的外观角色可以降低原有系统的复杂度同时降低客户类与子系统类的耦合度。
注在外观模式中所指的子系统是一个广义的概念它可以是一个类、一个功能模块、系统的一个组成部分或者一个完整的系统。
1.2、定义
外部与一个子系统的通信通过一个统一的外观角色进行为子系统中的一组接口提供一个一致的入口。外观模式定义了一个高层接口这个接口使得子系统更加容易使用。外观模式又称为门面模式它是一种对象结构型模式。
2、解析
外观模式没有一个一般化的类图描述通常使用示意图来表示外观模式。
2.1、结构图 可以看出在外观模式结构图中包含以下两个角色。
Facade外观角色在客户端可以调用这个角色的方法在外观角色中可以知道相关的一个或者多个子系统的功能和责任。在正常情况下它将所有从客户端发来的请求委派到相应的子系统中去传递给相应的子系统对象处理。SubSystem子系统角色在软件系统中可以有一个或者多个子系统角色。每个子系统可以不是一个单独的类而是一个类的集合它实现子系统的功能。每个子系统都可以被客户端直接调用或者被外观角色调用它处理由外观类传过来的请求。子系统并不知道外观的存在对于子系统而言外观角色仅仅是另外一个客户端而已。
外观模式的主要目的在于降低系统的复杂程度。在面向对象软件系统中类与类之间的关系越多并不能表示系统设计得越好反而表示系统中类之间的耦合度太大这样的系统在维护和修改时都缺乏灵活性因为一个类的改动会导致多个类发生变化。而外观模式的引入很大程度上降低了类之间的通信和关系。引入外观模式之后增加新的子系统或者移除子系统都非常方便客户端类无须进行修改或者极少的修改只需要在外观类中增加或移除对子系统的引用即可。从这一点来说外观模式在一定程度上并不符合开闭原则增加新的子系统需要对原有系统进行一定的修改虽然这个修改工作量不大。
2.2、代码示例
外观模式的另一个特点是给客户端的使用带来极大方便在外观角色中存在如下典型代码
class Facade{private SystemA obj1new SystemA;private SystemB obj2new SystemB;private SystemC obj3new SystemC;public void method(){obj1.methodA();obj2.methodB();obj3.methodC();}
}在外观角色中维持了对子系统对象的引用客户端可以通过外观角色来间接调用子系统对象的业务方法而无须与子系统对象直接交互。
2.3、抽象外观类的引入
在标准的外观模式结构图中如果需要增加、删除或更换与外观类交互的子系统类必须修改外观类或客户端的源代码这将违背开闭原则。因此可以通过引入抽象外观类来对系统进行改进在一定程度上解决该问题。在引入抽象外观类之后客户端可以针对抽象外观类进行编程对于新的业务需求不需要修改原有外观类而对应增加一个新的具体外观类。由新的具体外观类来关联新的子系统对象同时通过修改配置文件来达到不修改任何源代码并更换外观类的目的。
2.4、外观角色设计补充说明
在实际应用中具体使用外观模式时可以参考以下3条关于外观角色设计的补充说明。
在很多情况下为了节约系统资源系统中只需要一个外观类的实例。换言之外观类可以是一个单例类。因此可以通过单例模式来设计外观类从而确保系统中只有唯一一个访问子系统的入口并降低对系统资源的消耗。引入单例模式的外观模式结构如下图所示。 Facade类被设计为单例类。在其中定义了一个静态的Facade类型的成员变量instance其构造函数为私有private且通过一个静态的公有工厂方法getInstance返回自己的唯一实例。当然能够设计为单例类的外观类一定是具体外观类而不是抽象外观类。在一个系统中可以设计多个外观类每个外观类都负责和一些特定的子系统交互向客户端提供相应的业务功能。试图通过外观类为子系统增加新行为的做法是错误的。外观模式的用意是为子系统提供一个集中化和简化的沟通渠道而不是向子系统加入新行为。新行为的增加应该通过修改原有子系统类或增加新的子系统类来实现不能通过外观类来实现。
3、外观模式总结
外观模式是一种使用频率非常高的设计模式它通过引入一个外观角色来简化客户端与子系统之间的交互为复杂的子系统调用提供一个统一的入口使子系统与客户端的耦合度降低且客户端调用非常方便。外观模式并不给系统增加任何新功能它仅仅是简化调用接口。在几乎所有的软件中都能够找到外观模式的应用例如绝大多数B/S系统都有一个首页或者导航页面大部分C/S系统都提供了菜单或者工具栏。在这里首页和导航页面就是B/S系统的外观角色而菜单和工具栏就是C/S系统的外观角色通过它们用户可以快速访问子系统降低了系统的复杂程度。此外所有涉及与多个业务对象交互的场景都可以考虑使用外观模式进行重构例如Java EE中的Session外观模式。
3.1、主要优点
对客户端屏蔽了子系统组件减少了客户端所需处理的对象数目并使得子系统使用起来更加容易。通过引入外观模式客户端代码将变得很简单与之关联的对象也很少。实现了子系统与客户端之间的松耦合关系这使得子系统的变化不会影响到调用它的客户端只需要调整外观类即可。一个子系统的修改对其他子系统没有任何影响而且子系统内部变化也不会影响到外观对象。只是提供了一个访问子系统的统一入口并不影响客户端直接使用子系统类。
3.2、主要缺点
不能很好地限制客户端直接使用子系统类如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性。如果设计不当增加新的子系统可能需要修改外观类的源代码这违背了开闭原则。
3.3、适用场景
当要为访问一系列复杂的子系统提供一个简单入口时可以使用外观模式。客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦从而提高子系统的独立性和可移植性。在层次化结构中可以使用外观模式定义系统中每一层的入口层与层之间不直接产生联系而通过外观类建立联系降低层之间的耦合度。
