设计模式中的delegation总结


前言

复习了一遍软件构造,感觉设计模式那一块特别有意思,特别是其中对delegation的使用,很精妙,所以总结一下几个我觉得比较值得一提的模式中的delegation。


1. 工厂方法模式

在这种模式下,可以看做有两棵树,一棵为产品树,一棵为工厂树。在创建产品这件事上,客户端面对的完全是工厂树的实现类,不会接触到产品树。创建具体产品被委托给了具体的工厂的某些类似于createProduct的方法。
在新加入产品时,对已有的代码不用做任何修改,只要新建一个产品以及对应工厂即可,符合开闭原则。

2. 适配器模式

在适配器模式中,适配器类将客户端的请求委托给适配的类,以实现接口的兼容性。这种委托关系使得适配器模式能够在不改变现有类的情况下,通过引入一个新的适配器类来实现不同接口之间的协作。
在适配器类中的对应函数中,new了一个原有类的对象,把经过处理的参数传给这个原有类的对象,实现了delegation。适配器类可以当成是一个兼容的原有类使用,它的地位和原有类本应在继承树中的地位应该是一模一样的。

3. 装饰器模式

在这里插入图片描述

以这张图片举例,装饰器的委托的最大头,就是在于除了最基础的功能实现类ConcreteComponent之外,所有的装饰类都保有一个最抽象接口类Component的字段引用,并在其构造函数中选择实现类对象被这个引用指向
由于保有的是接口类,所以全部都是父类引用指向子类对象的关系,它可以被传入最抽象接口的所有实现类,并在当前类的构造中,把部分功能委派给这个成员,再添加自己的额外行为。所有实现类的共同接口保证了组合的自由性,装饰类的继承实现了功能的叠加
通过这种方式,装饰器模式动态地为对象添加职责(功能)。这种模式为对象的功能扩展提供了一种灵活的机制,同时保持了对象设计的开放封闭原则。

4. 策略模式

在策略模式中,delegation起到了核心作用。

首先有一棵功能实现的继承树,比如说支付功能:
在这里插入图片描述
creditCardStrategyPaypalStrategy是实现了PaymentStrategy的两种方式,客户端需要delegation给他们实现自己的不同支付方式,这里应用了松散的delegation即association,通过传参建立委派关系。
在客户端中,面对某个功能有多种实现的情况,该功能的参数列表中的是所有实现的抽象接口,这样就可以通过传入不同的实现类对象,对功能进行不同的实现。
在这里插入图片描述

传入不同的参数,就按不同的方式实现接口规定的那个功能;在扩展方式时,也只需要再实现一个PaymentStrategy的子类,客户端传这个子类就行,符合开闭原则。

5. 观察者模式

Visitor模式包括以下主要角色:

元素接口(Element):定义一个accept方法,接受访问者对象。
具体元素(Concrete Element):实现元素接口,定义accept方法的实现。
访问者接口(Visitor):定义访问不同元素的方法。
具体访问者(Concrete Visitor):实现访问者接口,实现对不同元素的操作。

在Visitor模式中,元素对象将自身的处理逻辑委托给访问者对象。具体来说,元素对象在accept方法中调用访问者对象的对应方法,将处理逻辑委托给visitor的实现类。


对element的很多操作不在element中定义,而是通过它的accept方法delegate给visitor
accept方法的形参列表中,是visitor树中的最大接口,便于接受每一个visitor实现类实例,在visitor树中,最大接口决定了要对哪些element进行操作,每个实现类代表对最大接口决定的要操作的一系列element类的具体操作,要切换操作算法,只要传入不同visitor子类对象。
所以在扩展中,添加操作很容易,只要在visitor接口下实现一个新的子类
而添加element很麻烦,因为要从接口开始添加一个要操作的element,所有visitor的实现类都要修改。

  • 54
    点赞
  • 30
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值