接口模式

文章目录

门面模式（Facade）背景定义case 代理模式（proxy）背景定义 适配器模式(Adapter)背景定义 中介者模式（Mediator）背景定义case

门面模式（Facade）

背景

如果一个系统中组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合会面临着很多变化的挑战。 如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦？

定义

为子系统中的一组接口提供一个一致（稳定）的界面，Facade（法语）模式定义了一个高层接口，这个接口使得这一子系统更加容易使用（复用）。 《设计模式》GoF

case

Facade更多的是表示一种软件设计的思想，没有相对固定的代码结构。可能代码结构相差很大的的代码都能体现Facade思想。其实，其他的设计模式也讲究接口分离，但这几个设计模式更强调这一点。接口分离其实很好的体现了“高内聚，低耦合”的设计思想。单个子系统尽量负责单个模块功能，这个子系统内部可能是高度耦合的，但对外只用一个统一的接口。

代理模式（proxy）

背景

在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者，或者系统结构带来很多麻烦。 如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式。

定义

为其他对象提供一种代理以控制（隔离，使用接口）对这个对象访问。 《设计模式》GoF

适配器模式(Adapter)

背景

在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。 如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？

定义

将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原来由于接口不兼容而不能一起工作的那些类可以一起工作。 《设计模式》 GoF

中介者模式（Mediator）

背景

在软件构建过程中，经常会出现多个对象相互关联交互的情况，对象之间经常会维持一种复杂的引用关系，如果遇到一些需求这种直接的引用关系将面临不断的变化。 在这种情况下，我们使用一个“中介对象”来管理对象间的关联关系，避免互相交互的对象之间的紧耦合引用关系，从而更好地抵御变化。

定义

用一个中介对象来封装（封装变化）一系列的对象交互。中介者是各对象不需要显示的相互引用（编译时依赖->运行时依赖），从而使其耦合松散（管理变化），而且可以独立地改变它们之间的交互。 《设计模式》 GoF

case

加入一个子系统中有N个对象（Colleague）, 这N个对象之间存在错综复杂的依赖，这样带来的一个问题就是，其中一个对象的修改后，可能引起系统中其他对象进行连锁的修改。为了避免这种爆炸式的修改，现将依赖关系转成这样：建立一个新对象Mediator，这N个Colleague和Mediator建立互相依赖的关系，Colleague之间不直接建立依赖关系，而是通过Mediator建立互相调用。