《Head First设计模式》 读书笔记08 适配器模式与外观模式 The Adapter and Façade Patterns

 

《Head First设计模式》 读书笔记08 适配器模式与外观模式

The Adapter and Façade Patterns

 

面向对象适配器

　　假设已有一个软件系统，你希望它能和一个新的厂商类库搭配使用，但是这个新的厂商所设计出来的接口不同于旧厂商的接口。

　　你不想改变现有的代码，解决这个问题，你可以写一个类，将厂商接口转换成你所期望的接口。

 

客户使用适配器的过程如下：

　　1.客户通过目标接口调用适配器的方法对适配器发出请求。

　　2.适配器使用被适配者接口把请求转换成被适配者的一个或多个调用接口。

　　3.客户接收到调用的结果，但并未察觉这一切是适配器在起转换作用。

 

适配器模式定义

　　适配器模式将一个类的接口，转换成客户期望的另一个接口。

　　适配器让原本接口不兼容的类可以合作无间。

 

适配器模式类图

 

　　使用对象组合，以修改的接口包装被适配者，被适配者的任何子类，都可以搭配着适配器使用。

　　把客户和接口绑定起来，而不是和实现绑定起来。

　　我们可以使用数个适配器，每一个都负责转换不同的后台类。

　　或者，也可以加上新的实现，只要它们遵守目标接口就可以。

 

对象和类的适配器

　　实际上有两种适配器：对象适配器和类适配器。

　　上面一个图是对象适配器的图。

　　类适配器，你需要多重继承才能实现它，这在Java和C#中是不可能的。但是当你使用多重继承语言的时候，还是可能遇到这样的需求。

　　类适配器的类图：

 

　　对象适配器和类适配器使用两种不同的适配方法，分别是组合与继承。

 

装饰者模式和适配器模式的比较

　　装饰者模式用来添加一些新的功能，而维持接口不变。

　　适配器模式关注于接口的转换。

 

外观模式

　　外观模式（Façade Pattern）是另一个改变接口的模式，它改变接口的原因是为了简化接口。

　　它将一个或数个类的复杂的一切都隐藏在背后，只显露出一个干净美好的外观。

 

　　书中例子：构造了一个复杂的家庭影院，但是每次看电影都要进行很多繁琐的操作。

　　使用一个外观类，将家庭影院的诸多组件视为一个子系统，通过调用这个子系统中的一系列方法，来完成外观类中的看电影操作。

　　这样，客户代码可以只调用外观所提供的一个方法，就完成各种操作。

 

　　外观没有封装子系统的类，外观只是提供简化的接口。

　　外观只是提供你更直接的操作，并未将原来的子系统阻隔起来，如果你需要子系统类的更高层功能，还是可以使用原来的子系统。

　　可以为一个子系统创建许多个外观。

 

　　外观模式不只是简化了接口，也将客户从组件的子系统中解耦。

　　比如，你想升级你的子系统（你的家庭影院），如果当初你的客户代码是针对外观而不是针对子系统编写的，现在你就不需要改变客户代码，只需要修改外观代码。

 

外观模式和适配器模式

　　外观模式和适配器模式的差异，在于它们的意图。

　　适配器模式的意图是，改变接口以符合客户的期望。

　　而外观模式的意图是，提供子系统的一个简化接口。

 

外观模式定义

　　外观模式提供了一个统一的接口，用来访问子系统中的一群接口。

　　外观定义了一个高层接口，让子系统更容易使用。

 

“最少知识”原则

　　最少知识（Least Knowledge）原则告诉我们要减少对象之间的交互，只留下几个“密友”。

　　这个原则通常是这么说的：

　　设计原则：

　　最少知识原则：只和你的密友谈话。

　　这个原则提供了一些方针：就任何对象而言，在该对象的方法内，我们只应该调用属于以下范围的方法：

　　　　该对象本身

　　　　被当作方法的参数而传递进来的对象

　　　　此方法所创建或实例化的任何对象

　　　　对象的任何组件