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

2019年2月28日 293次阅读 来源: 算法小白

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

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

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

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

Decorator pattern

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

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

直接用代码来说明。

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

class Dish: CustomStringConvertible {

    var name: String
    var price: Int

    init(name: String, price: Int) {
        self.name = name
        self.price = price
    }

    var description: String {
        get {
            return "\(name): \(price)元"
        }
    }
}复制代码

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

class DishOrder {

    func append(dish: Dish) {

    }

    func total() -> Int {

    }
}复制代码

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

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

// 加盐的装饰器
class SaltDishDecorator: Dish {

    init(dish: Dish) {
        super.init(name:"加糖 \(dish.name)", price: dish.price + 1)
    }

}

// 外带打包的装饰器
class PackageDishDecorator: Dish {

    init(dish: Dish) {
        super.init(name:"打包 \(dish.name)", price: dish.price + 2)
    }

}复制代码

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

let dish = PackageDishDecorator(dish: SaltDishDecorator(dish: Dish(name: "松鼠桂鱼", price: 15)))复制代码

《thinking in Swift：重新审视装饰器模式》

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

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

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

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

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

利用Swift中的Extension

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


extension Dish {

    func salted() -> Dish {
        return Dish(name:"加盐 \(name)", price: price + 1)
    }

    func packaged() -> Dish {
        return Dish(name:"打包 \(name)", price: price + 2)
    }
}复制代码

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

let extenedDish = Dish(name: "松鼠桂鱼", price: 15).salted().packaged()复制代码

更进一步：protocol extension

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

protocol Product {
    var name: String { get set }
    var price: Int { get set }
}

protocol Salteable: Product {
     func salted() -> Self
}复制代码

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

extension Salteable {
  func salted() -> Self {
        var newProduct = self
        newProduct.name = "加盐 \(name)"
        newProduct.price = price + 1
        return newProduct
    }
}复制代码

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

struct Snack: CustomStringConvertible {

    var name: String
    var price: Int

    init(name: String, price: Int) {
        self.name = name
        self.price = price
    }

    var description: String {
        get {
            return "\(name): \(price)元"
        }
    }
}复制代码

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

extension Snack: Salteable {

}复制代码

这样就够啦！ 看下输出：

《thinking in Swift：重新审视装饰器模式》

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

    原文作者：算法小白
    原文地址: https://juejin.im/post/57f253f00bd1d0005891af7b
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞