thinking in Swift:重新审视装饰器模式
(点击上方公众号,可快速关注)
如果在swift中按部就班的谈Gof设计模式,这在一开始就是错误的命题。原因主要有两个:
如今的swift的推荐编程范式并不是面向对象,很多人都大谈面向协议、函数式编程我就不展开了;现代的swift中有一些语法特性是当时的语言所不具备的,比如protocol extension,高阶函数等。 所以本文将利用swift的语法来谈下装饰器模式在swift下的解决思路。 Decorator pattern 有人翻作装饰器模式,也有翻成装饰者模式,英文的名称就是Decorator pattern。
直接用代码来说明。 用Dish表示菜肴,一道菜有两个属性,名称和价格。然后为了方便测试重写了description属性,返回名称和价格。
再假设有一个菜的订单对象,接收一个Dish对象后,最后可以通过total方法返回这些菜的总价钱。具体就不实现了,大概这个逻辑。
假设在一个饭馆里,老板发现这里的客人点菜的时候喜欢让厨师多放点盐,大家都知道非典时期盐很贵,所以老板觉得很亏,决定如果一道菜多加盐就要贵一块钱。接着又来了一个需求,如果打包带走,一道菜再加两块钱。如果我们不能改变Dish的源码(在实际项目中常会遇到这种情况,可能这类定义在第三方的库里),要怎么实现这两个需求呢? 可以定义两个装饰器,注意这两个装饰器都要继承Dish:
现在我们要表示一道打包带走的松鼠桂鱼就这样表示了:
这样我们就可以给任意一道菜增加一些装饰性的功能。也有人用咖啡举例子,一杯咖啡可能要加糖,加奶,加巧克力等等。一层包一层。如果取名字的是中国人可能就叫洋葱模式了。最后使用的时候行为和Dish是一样的。因为这些Decorator是继承自Dish的。只是在初始化过程中改变了原有的一些属性。 缺陷:继承不是一个优秀的解决方案 编程时常常提到的一个指导思想就是组合优于继承。 继承最大的问题就在于你只能有一个爹。一个爹的结果就是能力有限,不够灵活。所以最后还得认一些干爹。 就拿上面的例子来讲,现在是给Dish做了几个装饰功能,如果有一天说店里的点心也要支持这两个功能(给我来一个加盐的馒头!),是不是有要继承点心类写两个装饰器呢? 利用Swift中的Extension 我们可以这么理解这个需求,需要有这么一个方法,接受一个Dish类型的参数,经过处理后返回一个Dish。我们完全可以把这个方法通过extension写在Dish身上。
然后我们就可以链式调用:
更进一步:protocol extension 如果为了将来的扩展灵活,也可以把这个装饰写到protocol的extension里。
上面先定义了一个产品的协议,有名称和价格两个属性。 接着再定义了一个继承Product的Salteable的协议。里面有一个返回自身的salted方法。接着给这个protocol增加扩展实现:
然后我们再定义一个表示小吃的Snack,和菜一样也有两个属性。
如果我们要给这个Snack增加加盐的效果,只要声明他实现Salteable协议就可以了。
这样就够啦! 看下输出: 欢迎关注我的微博:@没故事的卓同学 关注「 iOS大全 」 看更多精选 iOS 技术文章 ↓↓↓ (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |