06_接口隔离模式

2023-10-24 16:12
文章标签 模式 06 接口隔离

本文主要是介绍06_接口隔离模式,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

接口隔离模式

在组件构建过程中,某些接口之间直接的依赖常常会带来很多问题、甚至根本无法实现。采用添加一层间接(稳定)接口,来隔离本来互相紧密关联的接口是一种常见的解决方案。

典型模式:

  • Facede
  • Proxy
  • Adapter
  • Mediator

Facade 门面模式

为子系统中的一组接口提供一个一致(稳定)的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用(复用)

系统间耦合的复杂度

在这里插入图片描述

使用Facede接口隔离。

动机

  • 上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合,随着外部客户程序和各子系统的演化,这种过多的耦合面临很多变化的挑战。
  • 如何简化外部客户程序和系统间的交互接口?如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦?

体现的是一种思想。

总结

  • 从客户程序的角度来看,Facade模式简化了整个组件系统的接口,对于组件内部与外部客户程序来说,达到了一种“解耦”的效果内部子系统的任何变化不会影响到Facade接口的变化。
  • Facade设计模式更注重从架构的层次去看整个系统,而不是单个类的层次。Facade很多时候更是一种架构设计模式。
  • Facade设计模式并非一个集装箱,可以任意地放进任何多个对象。Facade模式中组件的内部应该是“相互耦合关系比较大的一系列组件”,而不是一个简单的功能集合。

接口-思想。

代理模式

为其他对象提供一种代理以控制(隔离,使用接口)对这个对象的访问

动机

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

例子

由于某些原因不能获取到RealSubject

package proxyimport "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() {//间接的访问,Subjectfmt.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 adapterimport "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 adapterimport "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

这样,MediatorColleague相互依赖,ColleagueMediatorColeague不相互依赖。依赖解耦。

具体例子:计算机网络中的交换机。

原本m个计算机相互 通信需要 m ( m − 1 ) / 2 m(m-1)/2 m(m1)/2个连接,现在通过一个交换机和m条连接即可实现互通。

实例

聊天室,作为中介者

package midiatorimport "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     stringMediator 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 midiatorimport "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模式是解耦系统内各个对象之间(双向)的关联关系。

这篇关于06_接口隔离模式的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/276335

相关文章

06 C++Lambda表达式

lambda表达式的定义 没有显式模版形参的lambda表达式 [捕获] 前属性 (形参列表) 说明符 异常 后属性 尾随类型 约束 {函数体} 有显式模版形参的lambda表达式 [捕获] <模版形参> 模版约束 前属性 (形参列表) 说明符 异常 后属性 尾随类型 约束 {函数体} 含义 捕获:包含零个或者多个捕获符的逗号分隔列表 模板形参:用于泛型lambda提供个模板形参的名

在JS中的设计模式的单例模式、策略模式、代理模式、原型模式浅讲

1. 单例模式(Singleton Pattern) 确保一个类只有一个实例,并提供一个全局访问点。 示例代码: class Singleton {constructor() {if (Singleton.instance) {return Singleton.instance;}Singleton.instance = this;this.data = [];}addData(value)

模版方法模式template method

学习笔记,原文链接 https://refactoringguru.cn/design-patterns/template-method 超类中定义了一个算法的框架, 允许子类在不修改结构的情况下重写算法的特定步骤。 上层接口有默认实现的方法和子类需要自己实现的方法

【iOS】MVC模式

MVC模式 MVC模式MVC模式demo MVC模式 MVC模式全称为model(模型)view(视图)controller(控制器),他分为三个不同的层分别负责不同的职责。 View:该层用于存放视图,该层中我们可以对页面及控件进行布局。Model:模型一般都拥有很好的可复用性,在该层中,我们可以统一管理一些数据。Controlller:该层充当一个CPU的功能,即该应用程序

迭代器模式iterator

学习笔记,原文链接 https://refactoringguru.cn/design-patterns/iterator 不暴露集合底层表现形式 (列表、 栈和树等) 的情况下遍历集合中所有的元素

《x86汇编语言:从实模式到保护模式》视频来了

《x86汇编语言:从实模式到保护模式》视频来了 很多朋友留言,说我的专栏《x86汇编语言:从实模式到保护模式》写得很详细,还有的朋友希望我能写得更细,最好是覆盖全书的所有章节。 毕竟我不是作者,只有作者的解读才是最权威的。 当初我学习这本书的时候,只能靠自己摸索,网上搜不到什么好资源。 如果你正在学这本书或者汇编语言,那你有福气了。 本书作者李忠老师,以此书为蓝本,录制了全套视频。 试

利用命令模式构建高效的手游后端架构

在现代手游开发中,后端架构的设计对于支持高并发、快速迭代和复杂游戏逻辑至关重要。命令模式作为一种行为设计模式,可以有效地解耦请求的发起者与接收者,提升系统的可维护性和扩展性。本文将深入探讨如何利用命令模式构建一个强大且灵活的手游后端架构。 1. 命令模式的概念与优势 命令模式通过将请求封装为对象,使得请求的发起者和接收者之间的耦合度降低。这种模式的主要优势包括: 解耦请求发起者与处理者

springboot实战学习(1)(开发模式与环境)

目录 一、实战学习的引言 (1)前后端的大致学习模块 (2)后端 (3)前端 二、开发模式 一、实战学习的引言 (1)前后端的大致学习模块 (2)后端 Validation:做参数校验Mybatis:做数据库的操作Redis:做缓存Junit:单元测试项目部署:springboot项目部署相关的知识 (3)前端 Vite:Vue项目的脚手架Router:路由Pina:状态管理Eleme

状态模式state

学习笔记,原文链接 https://refactoringguru.cn/design-patterns/state 在一个对象的内部状态变化时改变其行为, 使其看上去就像改变了自身所属的类一样。 在状态模式中,player.getState()获取的是player的当前状态,通常是一个实现了状态接口的对象。 onPlay()是状态模式中定义的一个方法,不同状态下(例如“正在播放”、“暂停

软件架构模式:5 分钟阅读

原文: https://orkhanscience.medium.com/software-architecture-patterns-5-mins-read-e9e3c8eb47d2 软件架构模式:5 分钟阅读 当有人潜入软件工程世界时,有一天他需要学习软件架构模式的基础知识。当我刚接触编码时,我不知道从哪里获得简要介绍现有架构模式的资源,这样它就不会太详细和混乱,而是非常抽象和易