包裝接口--模塊化起步

今天看到一段代碼，思考了一下以爲挺精妙的，圍繞的是一個接口包裝的問題，下面舉個小栗子。

場景：

一般咱們會利用接口來觀測具備相同行爲的對象，從而進行具體行爲的派發，目的是爲了解除調用方和行爲對象的耦合，咱們能夠很方便的再次變換行爲對象；可是咱們每每會忽略，在調用方處理接口時造成的耦合。

設想一個常見的場景，客戶端調用服務端發送指令

簡單處理：

服務端

trait Trigger {
    def strategy(): String
}

object ZhouYuTrigger extends Trigger{
    override def startegy(): String = {
        return "火燒赤壁"
    }
}

object KongMingTrigger extends Trigger{
    override def startegy(): String = {
        return "草船借箭"
    }
}

客戶端

class ClientFirst(trigger: Trigger) {
    def main(): Unit = {
        println("發動技能：")
        println(trigger.strategy)
    }
}

class ClientSecond(trigger: Trigger) {
    def main(): Unit = {
        println("發動技能：")
        println(trigger.strategy)
    }
}

優化處理：

服務端

trait Trigger {
    protected def strategy(): String

    def process(): Boolean = {
        println("發動技能：")
        println(strategy)
        return true
    }
}

object ZhouYuTrigger extends Trigger {
    override protected def startegy(): String = {
        return "火燒赤壁"
    }
}

object KongMingTrigger extends Trigger {
    override protected def startegy(): String = {
        return "草船借箭"
    }
}

客戶端

class ClientFirst(trigger: Trigger) {
    def main(): Unit = {
        trigger.process
    }
}

class ClientSecond(trigger: Trigger) {
    def main(): Unit = {
        trigger.process
    }
}

在服務端或是子模塊中，咱們可能須要在服務分發前，或者聚合以後進行統一處理，好比打印日誌等；或者接口發送改動，好比這裏使用技能時，咱們不發送String指令了，改成發送JSONObject時，咱們不但願再對客戶端進行修改

這個時候能夠預留出一個分發空間的緩衝區，在子層中作處理，作更完善的封裝，提供外層調用