image.png

很久没写文章了，今天看到了一个感觉很棒的设计模式，所以想把它记录下来，一起分享给大家。这个模式叫策略模式。

废话就不多说了，我们先看看它的定义：

策略模式作为一种软件设计模式指对象有某个行为，但是在不同的场景中，该行为有不同的实现算法。比如每个人都要“交个人所得税”，但是“在美国交个人所得税”和“在中国交个人所得税”就有不同的算税方法。（以上是百度百科给出的定义）

应用场景：

• 做同样的事情，但是又不同的方法
  当你需要通过不同的方式在代码中做同样的事情时，你就可以使用这种设计模式了。（最常用）

• 替代if/else代码块
  如果你觉得你的类有很多的if/else，这就表明这个类的职责太臃肿，可以使用这种模式来进行拆分。

例子：

这里我举出一个例子来说明一下这个模式：
比如你有个需求，需要打印文案，打印他的大写、小写、首字母大写。可能一般的人就会这样写：

struct Logger {

    enum LogStyle {
        case lowercase
        case uppercase
        case capitalized
    }

    let style: LogStyle

    func log(_ message: String) {
        switch style {
        case .lowercase:
            print(message.lowercased())
        case .uppercase:
            print(message.uppercased())
        case .capitalized:
            print(message.capitalized)
        }
    }
}

这样写，看起来也没啥问题，好像也很简洁是吧？
但是，这个时候，如果我让你再增加10中打印类型呢？50种呢？100种呢？你是不是要一直case100中情况？而且，所有代码都杂在一个类里面了？

那么，策略模式就可以很好的解决这个问题了。

image.png

策略模式我们有3块：

• WAHT： 定义我们要封装的操作协议。
• WHO：包含符合策略的对象的对象。
• HOW ：战略的具体实施。每种实施都不同。

///WHAT
protocol LoggerStrategy {
    
    func log(message: String)
}

///WHO
struct Logger {
    let strategy:LoggerStrategy
    
    init(_strategy:LoggerStrategy) {
        strategy = _strategy
    }
    
    func log(message: String) {
        
        strategy.log(message: message)
    }
    
}

///HOW
struct LowercaseStrategy:LoggerStrategy {
    func log(message: String) {
        print(message.lowercased())
    }
}

struct UppercaseStrategy:LoggerStrategy {
    func log(message: String) {
        print(message.uppercased())
    }
}

struct CapitalizedStrategy:LoggerStrategy {
    func log(message: String) {
        print(message.capitalized)
    }
}

///use
var logger = Logger(_strategy: CapitalizedStrategy())
        logger.log(message: "my first strategy")
        
        logger = Logger(_strategy: LowercaseStrategy())
        logger.log(message: "my first strategy")
        
        logger = Logger(_strategy: UppercaseStrategy())
        logger.log(message: "my first strategy")

结果：

image.png

这样，无论我们的需求情况如何增加，你增加100种，我们都应付，而且，代码不需要杂在一起了，而且，可扩展性也很高，需要用加用，不需要的，直接删除，增加也行。