06_接口隔离模式
接口隔离模式
在组件构建过程中，某些接口之间直接的依赖常常会带来很多问题、甚至根本无法实现。采用添加一层间接（稳定）接口，来隔离本来互相紧密关联的接口是一种常见的解决方案。
典型模式：
- Facede
- Proxy
- Adapter
- Mediator
Facade 门面模式
为子系统中的一组接口提供一个一致（稳定）的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用（复用)
系统间耦合的复杂度
使用Facede接口隔离。
动机
- 上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。
- 如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦？
体现的是一种思想。
总结
- 从客户程序的角度来看，Facade模式简化了整个组件系统的接口，对于组件内部与外部客户程序来说，达到了一种“解耦”的效果内部子系统的任何变化不会影响到Facade接口的变化。
- Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。
- Facade设计模式并非一个集装箱，可以任意地放进任何多个对象。Facade模式中组件的内部应该是“相互耦合关系比较大的一系列组件”，而不是一个简单的功能集合。
接口-思想。
代理模式
为其他对象提供一种代理以控制（隔离，使用接口）对这个对象的访问
动机
- 在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等)直接访问会给使用者、或者系统结构带来很多麻烦。
- 如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式。
例子
由于某些原因不能获取到RealSubject
package proxy
import "fmt"
type ISubject interface {
process()
}
type RealSubject struct {
}
func (self *RealSubject) process() {
fmt.Println("RealSubject process")
}
type ClientApp struct {
subject ISubject
}
// 构造
func NewClientApp(subject ISubject) *ClientApp {
return &ClientApp{subject: subject} //可能不能获取到subject
}
func (self *ClientApp) DoTask() {
self.subject.process()
}
代理
type SubjectProxy struct {
ISubject
}
func (self *SubjectProxy) process() {
//间接的访问，Subject
fmt.Println("Before ISubject process")
self.ISubject.process()
fmt.Println("After ISubject process")
}
总结
- “增加一层间接层”是软件系统中对许多复杂问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会带来很多问题，作为间接层的poxy对象便是解决这一问题的常用手段。
- 具体poxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象做细粒度的控制，如copy-on-write技术，有些可能对组件模块提供抽象代理层，在架构层次对对象做poxy。
- Poy并不一定要求保持接口完整的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。
protobuf生成Go代码等。
适配器模式
将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
动机
- 在软件系统中，由于应用环境的变化，常常需要将”一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。
- 如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？
例如：电源适配器，HDMI-VGA等等
示例
package adapter
import "fmt"
// 目标接口，新接口
type ITarget interface {
Process()
}
// 倍适配者，老接口
type IAdaptee interface {
Foo()
Bar() int
}
// 老接口
type OldClass struct {
IAdaptee
}
func (self *OldClass) Foo() {
fmt.Println("OldClass Foo")
}
func (self *OldClass) Bar() int {
fmt.Println("OldClass Bar")
return 1
}
// 适配器
type Adapter struct {
ITarget //继承
adaptee IAdaptee //指针
}
func (adapter *Adapter) Process() {
adapter.adaptee.Foo()
adapter.adaptee.Bar()
fmt.Println("Adapter Process Done")
}
使用
package adapter
import "testing"
func TestAdapter_Process(t *testing.T) {
adaptee := &OldClass{}
var adapter ITarget = &Adapter{adaptee: adaptee}
adapter.Process()
}
总结
- Adapter模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁移等方面非常有用。
- GoF23定义了两种Adapter模式的实现结构：对象适配器和类适配器。但类适配器采用“多继承”的实现方式，一般不推荐使用。对象适配器采用“对象组合”的方式，更符合松耦合精神。
- Adapter模式可以实现的非常灵活，不必拘泥于Gof23中定义的两种结构。例如，完全可以将Adapter模式中的“现存对象”作为新的接口方法参数，来达到适配的目的。
中介模式
用一个中介对象来封装（封装变化）一系列的对象交互。中介者使各对象不需要显式的相互引用（编译时依赖→运行时依赖)，从而使其耦合松散（管理变化），而且可以独立地改变它们之间的交互。
动机
- 在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。
- 在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。
界面与模型的相互依赖，
Mediator，中介
Coleague，内部有指针指向Mediator,
ColleagueMediator指向具体的ConcreteColleagure1,ConcreteColleagure2
这样，Mediator与Colleague相互依赖，ColleagueMediator与Coleague不相互依赖。依赖解耦。
具体例子：计算机网络中的交换机。
原本m个计算机相互 通信需要 m ( m − 1 ) / 2 m(m-1)/2 m(m−1)/2个连接，现在通过一个交换机和m条连接即可实现互通。
实例
聊天室，作为中介者
package midiator
import "fmt"
// 中介者接口
type Mediator interface {
SendMessage(message string, user User)
}
// 具体中介者
type ChatRoom struct{}
func (c *ChatRoom) SendMessage(message string, user User) {
fmt.Printf("%s 发送消息：%s\n", user.GetName(), message)
}
// 用户类
type User struct {
Name string
Mediator Mediator
}
func NewUser(name string, mediator Mediator) *User {
return &User{
Name: name,
Mediator: mediator,
}
}
func (u *User) GetName() string {
return u.Name
}
func (u *User) SendMessage(message string) {
u.Mediator.SendMessage(message, *u)
}
使用
package midiator
import "testing"
func TestChatRoom(t *testing.T) {
// 创建聊天室作为中介者
chatRoom := &ChatRoom{}
// 创建用户并设置中介者
user1 := NewUser("User1", chatRoom)
user2 := NewUser("User2", chatRoom)
user3 := NewUser("User3", chatRoom)
// 用户发送消息
user1.SendMessage("Hello, everyone!")
user2.SendMessage("Nice to meet you!")
user3.SendMessage("Greetings!")
// 输出：
// User1 发送消息：Hello, everyone!
// User2 发送消息：Nice to meet you!
// User3 发送消息：Greetings!
}
Mediator
+SendMessage(message: string, user: User)
ChatRoom
+SendMessage(message: string, user: User)
User
- Name: string
- Mediator: Mediator
+GetName()
+SendMessage(message: string)
总结
- 将多个对象间复杂的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关联”为“多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。
- 随着控制逻辑的复杂化，Mediator.具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理。
- Facade模式是解耦系统间（单向)的对象关联关系；Mediator模式是解耦系统内各个对象之间（双向）的关联关系。