包装接口--模块化起步

今天看到一段代码，思考了一下以为挺精妙的，围绕的是一个接口包装的问题，下面举个小栗子。

场景：

一般咱们会利用接口来观测具备相同行为的对象，从而进行具体行为的派发，目的是为了解除调用方和行为对象的耦合，咱们能够很方便的再次变换行为对象；可是咱们每每会忽略，在调用方处理接口时造成的耦合。

设想一个常见的场景，客户端调用服务端发送指令

简单处理：

服务端

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时，咱们不但愿再对客户端进行修改

这个时候能够预留出一个分发空间的缓冲区，在子层中作处理，作更完善的封装，提供外层调用