>上一篇<中介紹了兩種類狀態行為模式，這次介紹行為模式的最後三種——中間類行為模式：中介模式|訪問者模式|直譯器模式。

>什麼是中間模式 ?

    中介模式中，存在一箇中介物件，封裝了一系列物件的互動，使得各個物件間的互動由緊密網路變成鬆散的中心耦合狀態。簡單來說，就是將下圖中系統中的UML圖變為右邊的那樣：

     中介模式的UML圖如下：

     其主要包含兩個要素：

• Mediator中介類：封裝了同事類間的互動方法；
• Colleague同事類：同事類間將可能因為自身狀態改變或其他原因發生互動。

//中介
abstract class Mediator(){
    abstract fun contact(s:String,sender:Computer)
}
class MediatorCenter(c:Computer,center:Computer):Mediator(){
    //封裝物件
    private val client = c
    private val computerCenter = center
    //封裝物件間的互動
    override fun contact(s: String,sender:Computer) {
        when(sender){
            is FamilyComputer -> computerCenter.showMessage(s)
            is Supercomputer -> client.showMessage(s)
        }
    }
}
//同事類
abstract class Computer{
    lateinit var myMediator:Mediator
    abstract fun contact(s:String)
    fun setMediator(m:Mediator){
        myMediator = m
    }
    fun showMessage(s:String){
        println("${this.javaClass} 收到: $s")
    }
}
class FamilyComputer:Computer(){
    override fun contact(s:String) {
        //資料改變時不自己去處理相關的關聯，而是交給中介的互動方法處理
        myMediator.contact(s,this)
    }
}
class Supercomputer:Computer(){
    override fun contact(s:String) {
        myMediator.contact(s,this)
    }
}
//測試
fun main(a:Array<String>){
    val client = FamilyComputer()
    val computerCenter = Supercomputer()
    val mediatorCenter = MediatorCenter(client,computerCenter)
    client.setMediator(mediatorCenter)
    computerCenter.setMediator(mediatorCenter)
    client.contact("我的資料發生了改變，請告訴超算中心") //輸出:class Supercomputer 收到: 我的資料發生了改變，請告訴超算中心
    computerCenter.contact("我的資料發生了改變，請告訴使用者機") //輸出:class FamilyComputer 收到: 我的資料發生了改變，請告訴使用者機
}
 

>什麼是訪問者模式？

     訪問者模式：針對一個相對穩定的資料結構，訪問者模式提供了一個基於該資料結構之上的的操作方法，使得訪問該資料的模式可以基於OCP進行變化。或者說，是針對不同的資料，提供可擴充套件的訪問方案。

     其UML圖如下：

    舉個例子來說明這個模式：老闆和會計對一系列賬目的關注點是不同，也就是老闆和會計是訪問者，而不同的賬目（資料結構）是UML圖中的Element。

abstract class Account{//賬單類
    abstract var myContent:String
    abstract fun accept(visitor:Visitor)
}
class AccountA:Account(){
    override var myContent: String = "賬單A"
    override fun accept(visitor:Visitor){
        visitor.visit(this)
    }
}
class AccountB:Account(){
    override var myContent: String = "賬單B"
    override fun accept(visitor:Visitor){
        visitor.visit(this)
    }
}
abstract class Visitor{//訪問者類
    abstract fun visit(account:AccountA)//利用引數不同進行過載visit函式
    abstract fun visit(account:AccountB)
}
class Boss:Visitor(){
    override fun visit(account: AccountA) {
        println("Boss 瀏覽 賬單A，感嘆道又虧了一個億.")//可以針對性地提供訪問該資料的方案，這裡從簡
    }
    override fun visit(account: AccountB) {
        println("Boss 瀏覽 賬單B，感嘆道又虧了一個億.")
    }
}
class Accountant:Visitor(){
    override fun visit(account: AccountA) {
        println("會計 瀏覽 賬單A，並計算了總盈虧.")
    }
    override fun visit(account: AccountB) {
        println("會計 瀏覽 賬單B，並計算了總盈虧.")
    }
}
//測試
fun main(a:Array<String>){
    val a = AccountA()
    val b = AccountB()
    val boss = Boss()
    val accountant = Accountant()
    a.accept(boss) //Boss 瀏覽 賬單A，感嘆道又虧了一個億.
    b.accept(boss) //Boss 瀏覽 賬單B，感嘆道又虧了一個億.
    a.accept(accountant) //會計 瀏覽 賬單A，並計算了總盈虧.
    b.accept(accountant) //會計 瀏覽 賬單B，並計算了總盈虧.
}
 

>什麼是直譯器模式？

    直譯器模式：給定一個上下文，直譯器模式提供了該Context的解釋方案。講白了跟編譯原理裡的語法樹的解析沒啥兩樣。其UML圖如下：

     但我覺得，直譯器模式最重要的核心思想，就是提供了一個interpretor，對特殊的Context進行解析並輸出系統可直接使用的結果。類似黑盒輸入。因此只要是基於此類思想，雖然不符合直譯器模式的標準定義，但其作為直譯器在使用上完全是沒問題的，這裡有一個brainfuck語言的直譯器作為參考：http://blog.csdn.net/shenpibaipao/article/details/73692164

    總的來說，直譯器模式用的地方比較少，對程式設計師的編寫能力要求也較高。