thinking in Swift:重新审视装饰器模式

11225849-31f73c10d057d35d

如果在swift中按部就班的谈Gof设计模式,这在一开始就是错误的命题。原因主要有两个:

  • 设计模式是基于面向对象的编程范式
  • 实现基于当时的主流编程语言:C++ 和 Java

如今的swift的推荐编程范式并不是面向对象,很多人都大谈面向协议、函数式编程我就不展开了;现代的swift中有一些语法特性是当时的语言所不具备的,比如protocol extension,高阶函数等。

所以本文将利用swift的语法来谈下装饰器模式在swift下的解决思路。

Decorator pattern

有人翻作装饰器模式,也有翻成装饰者模式,英文的名称就是Decorator pattern

装饰器模式能够实现动态的为对象添加功能,是从一个对象外部来给对象添加功能。装饰器模式就是基于对象组合的方式,可以很灵活的给对象添加所需要的功能。

直接用代码来说明。

用Dish表示菜肴,一道菜有两个属性,名称和价格。然后为了方便测试重写了description属性,返回名称和价格。

再假设有一个菜的订单对象,接收一个Dish对象后,最后可以通过total方法返回这些菜的总价钱。具体就不实现了,大概这个逻辑。

假设在一个饭馆里,老板发现这里的客人点菜的时候喜欢让厨师多放点盐,大家都知道非典时期盐很贵,所以老板觉得很亏,决定如果一道菜多加盐就要贵一块钱。接着又来了一个需求,如果打包带走,一道菜再加两块钱。如果我们不能改变Dish的源码(在实际项目中常会遇到这种情况,可能这类定义在第三方的库里),要怎么实现这两个需求呢?

可以定义两个装饰器,注意这两个装饰器都要继承Dish:

现在我们要表示一道打包带走的松鼠桂鱼就这样表示了:

12225849-bc603d5afe57bec9

这样我们就可以给任意一道菜增加一些装饰性的功能。也有人用咖啡举例子,一杯咖啡可能要加糖,加奶,加巧克力等等。一层包一层。如果取名字的是中国人可能就叫洋葱模式了。最后使用的时候行为和Dish是一样的。因为这些Decorator是继承自Dish的。只是在初始化过程中改变了原有的一些属性。

缺陷:继承不是一个优秀的解决方案

编程时常常提到的一个指导思想就是组合优于继承。

继承最大的问题就在于你只能有一个爹。一个爹的结果就是能力有限,不够灵活。所以最后还得认一些干爹。

就拿上面的例子来讲,现在是给Dish做了几个装饰功能,如果有一天说店里的点心也要支持这两个功能(给我来一个加盐的馒头!),是不是有要继承点心类写两个装饰器呢?

利用Swift中的Extension

我们可以这么理解这个需求,需要有这么一个方法,接受一个Dish类型的参数,经过处理后返回一个Dish。我们完全可以把这个方法通过extension写在Dish身上。

然后我们就可以链式调用:

更进一步:protocol extension

如果为了将来的扩展灵活,也可以把这个装饰写到protocol的extension里。

上面先定义了一个产品的协议,有名称和价格两个属性。
接着再定义了一个继承Product的Salteable的协议。里面有一个返回自身的salted方法。接着给这个protocol增加扩展实现:

然后我们再定义一个表示小吃的Snack,和菜一样也有两个属性。

如果我们要给这个Snack增加加盐的效果,只要声明他实现Salteable协议就可以了。

这样就够啦!
看下输出:

13225849-8c400c2dd49fc914

欢迎关注我的微博:@没故事的卓同学

1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部