跳转到主内容
趣航编程网 - 趣学编程,启航技术之路!

怎样用Golang实现中介者模式 减少对象间直接依赖关系

中介者模式通过引入中间人协调对象间通信,降低耦合度,适用于多个对象存在复杂且易变交互的场景,如聊天室、ui控件协同、工作流引擎等;其优点包括解耦同事对象、集中控制交互逻辑、简化对象职责,缺点是中介者可能变得复杂庞大,增加系统抽象层级并带来性能开销;为避免中介者过度复杂,应进行职责分离、使用组合、结合观察者模式或选用其他设计模式,实际应用中需权衡利弊,避免过度设计。 中介者模式,简单来说,就是让一堆对象不用直接互相说话,而是找个“中间人”来传话。用 Golang 实现,能有效降低对象间的耦合度,让系统更灵活。 解决方案 实现中介者模式,核心在于定义一个中介者接口,以及让各个“同事”对象持有该中介者的引用。同事对象间的通信,都通过中介者进行。 立即学习 “ go语言免费学习笔记(深入) ”; 定义中介者接口:
type Mediator interface { Register(name string, colleague Colleague) Send(from string, to string, message string) }
定义同事接口:
type Colleague interface { Receive(from string, message string) Send(to string, message string) SetName(name string) }
实现具体的中介者:
type ConcreteMediator struct { colleagues map[string]Colleague } func NewConcreteMediator() *ConcreteMediator { return &ConcreteMediator{ colleagues: make(map[string]Colleague), } } func (m *ConcreteMediator) Register(name string, colleague Colleague) { m.colleagues[name] = colleague colleague.SetName(name) } func (m *ConcreteMediator) Send(from string, to string, message string) { colleague, ok := m.colleagues[to] if !ok { fmt.Println("找不到接收者:", to) return } colleague.Receive(from, message) }
实现具体的同事类:
type ConcreteColleague struct { mediator Mediator name string } func NewConcreteColleague(mediator Mediator) *ConcreteColleague { return &ConcreteColleague{ mediator: mediator, } } func (c *ConcreteColleague) Receive(from string, message string) { fmt.Printf("%s 收到来自 %s 的消息: %s\n", c.name, from, message) } func (c *ConcreteColleague) Send(to string, message string) { fmt.Printf("%s 发送消息给 %s: %s\n", c.name, to, message) c.mediator.Send(c.name, to, message) } func (c *ConcreteColleague) SetName(name string) { c.name = name }
使用示例:
func main() { mediator := NewConcreteMediator() colleague1 := NewConcreteColleague(mediator) colleague2 := NewConcreteColleague(mediator) mediator.Register("Alice", colleague1) mediator.Register("Bob", colleague2) colleague1.Send("Bob", "你好,Bob!") colleague2.Send("Alice", "Alice你好,我是Bob!") }
Golang 中介者模式在实际项目中的应用场景有哪些? 中介者模式并非银弹,滥用反而会增加系统的复杂性。比较适合的场景是: 多个对象之间存在复杂的交互关系,且这些关系容易变化。 例如,一个在线聊天室,用户之间可以互相发送消息,管理员可以禁言用户等。 需要避免对象之间的直接依赖,降低耦合度。 例如,一个 UI 系统,多个控件之间需要协同工作,但又不希望它们直接互相调用。 需要集中控制对象之间的交互行为。 例如,一个工作流引擎,需要根据不同的条件触发不同的任务。 在这些场景下,使用中介者模式可以使系统结构更清晰、更易于维护。当然,如果对象之间的交互关系非常简单,或者变化的可能性很小,那么直接让对象互相调用可能更简单直接。 如何避免中介者模式中中介者对象过于复杂? 中介者对象承担了协调各个同事对象的职责,很容易变得过于庞大和复杂,成为一个“上帝对象”。避免这种情况,可以考虑以下几点: 职责分离: 将中介者对象的职责进行分解,例如,可以将消息路由、权限控制、状态管理等职责分别交给不同的组件来处理。 使用组合: 将多个简单的中介者对象组合成一个更复杂的中介者对象。 引入观察者模式: 让同事对象订阅中介者对象的状态变化,从而减少中介者对象需要直接控制的同事对象的数量。 考虑使用其他设计模式: 有时候,中介者模式并不是解决问题的最佳方案,可以考虑使用其他的模式,例如命令模式、责任链模式等。 总而言之,要根据实际情况,灵活运用设计模式,避免过度设计。 除了集中管理对象间的交互,中介者模式还有哪些优点和缺点? 优点: 降低耦合度: 这是中介者模式最核心的优点。同事对象之间不再直接依赖,而是通过中介者进行通信,从而降低了耦合度,提高了系统的灵活性和可维护性。 集中控制: 中介者对象可以集中控制对象之间的交互行为,方便进行统一的管理和控制。例如,可以添加权限控制、日志记录等功能。 简化对象: 同事对象只需要关注自身的职责,不需要关心与其他对象的交互细节,从而简化了对象的设计。 缺点: 中介者对象可能变得过于复杂: 如果同事对象之间的交互关系非常复杂,那么中介者对象可能会变得非常庞大和复杂,难以维护。 增加了系统的复杂性: 引入中介者模式会增加系统的复杂性,需要仔细权衡是否值得。 性能问题: 所有对象之间的通信都需要通过中介者进行转发,可能会带来一定的性能损失。 在决定是否使用中介者模式时,需要综合考虑其优缺点,并根据实际情况进行选择。

相关文章