设计模式专题-策略模式

很久没写文章了，今天看到了一个感觉很棒的设计模式，所以想把它记录下来，一起分享给大家。这个模式叫 策略模式 。 ####废话就不多说了，我们先看看它的定义：

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

####应用场景：

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

• 替代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中情况？而且，所有代码都杂在一个类里面了？

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

策略模式我们有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")
复制代码

结果：

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