現(xiàn)在，我們面對的一個問題是：如何實(shí)現(xiàn)add、remove方法，一般組合模式會在父類中添加這些方法，這確保了所有衍生類共享同一個接口，但同時表示：系統(tǒng)設(shè)計者將容忍冗余。

這是默認(rèn)實(shí)現(xiàn)方法：

class UnitException extends Exception {}

abstract class Unit {
    abstract function addUnit( Unit $unit );
    abstract function removeUnit( Unit $unit );
    abstract function bombardStrength();
}

class Archer extends Unit {
    function addUnit( Unit $unit ) {
        throw new UnitException( get_class($this) . " 屬于最小單位。");
    }

    function removeUnit( Unit $unit ) {
        throw new UnitException( get_class($this) . " 屬于最小單位。");
    }

    function bombardStrength()
    {
        return 3;
    }
}

class Army extends Unit {
    private $units = array();

    function addUnit( Unit $unit ) {
        if ( in_array( $unit, $this->units ,true)) {
            return;
        }
        $this->units[] = $unit;
    }

    function removeUnit( Unit $unit ) {
        $this->units = array_udiff(
            $this->units,
            array( $unit ),
            function( $a, $b ) { return ($a === $b) ? 0 : 1; }
        );
    }

    function bombardStrength() {
        $ret = 0;
        foreach ($this->units as $unit) {
            $ret += $unit->bombardStrength();
        }

        return $ret;
    }
}

我們可以做一些小改進(jìn)：將add、remove的拋出異常代碼挪入父類：

abstract class Unit {
    function addUnit( Unit $unit ) {
        throw new UnitException( get_class($this) . " 屬于最小單位。");
    }

    function removeUnit( Unit $unit ) {
        throw new UnitException( get_class($this) . " 屬于最小單位。");
    }

    abstract function bombardStrength();
}

class Archer extends Unit {
    function bombardStrength()
    {
        return 3;
    }
}

靈活：組合模式中的所有類都共享了同一個父類型，所以可以輕松的在設(shè)計中添加新的組合對象或局部對象，而無需大范圍修改代碼。

簡單：使用組合模式，客戶端代碼只需設(shè)計簡單的接口。對客戶端來說，調(diào)用需要的接口即可，不會出現(xiàn)任何“調(diào)用不存在接口”的情況，最少，它也會反饋一個異常。

隱式到達(dá)：對象通過樹形結(jié)構(gòu)組織，每個組合對象都保存著對子對象的引用，因此，書中某部分的一個小操作，可能會產(chǎn)生很大影響，卻不為人知——譬如：我們將軍隊(duì)1名下的一支軍隊(duì)(a)，挪動到軍隊(duì)2，實(shí)際上挪動的是軍隊(duì)(a)中所有的軍隊(duì)個體。

顯示到達(dá)：樹形結(jié)構(gòu)可以輕松遍歷，可以快捷的通過迭代樹形結(jié)構(gòu)，來獲取包含對象的信息。

最后，我們做一個Small Test吧。

// 創(chuàng)建番號
$myArmy = new Army();
// 添加士兵
$myArmy->addUnit( new Archer() );
$myArmy->addUnit( new Archer() );
$myArmy->addUnit( new Archer() );

// 創(chuàng)建番號
$subArmy = new Army();
// 添加士兵
$subArmy->addUnit( new Archer() );
$subArmy->addUnit( new Archer() );

$myArmy->addUnit( $subArmy );

echo "MyArmy的合計傷害為：" . $myArmy->bombardStrength(); // MyArmy的合計傷害為：15

來讓我解釋一下：為何addUnit之類的方法，必須出現(xiàn)在局部類中，因?yàn)槲覀円３?b>Unit的透明性——客戶端在進(jìn)行任何訪問時，都清楚的知道：目標(biāo)類中肯定有addUnit或其他方法，而不需要去猜疑。

現(xiàn)在，我們將Unit類解析出一個抽象子類CompositeUnit，并將組合對象具備的方法挪到它身上，加入監(jiān)測機(jī)制：getComposite。

現(xiàn)在，我們解決了“冗余方法”，只是我們每次調(diào)用，都必須通過getComposite確認(rèn)是否為組合對象，并且按照這種邏輯，我們可以寫一段測試代碼。

完整代碼：

class UnitException extends Exception {}

abstract class Unit {
    function getComposite() {
        return null;
    }

    abstract function bombardStrength();
}

abstract class CompositeUnit extends Unit {
    private $units = array();

    function getComposite() {
        return $this;
    }

    protected function units() {
        return $this->units;
    }

    function addUnit( Unit $unit ) {
        if ( in_array( $unit, $this->units ,true)) {
            return;
        }
        $this->units[] = $unit;
    }

    function removeUnit( Unit $unit ) {
        $this->units = array_udiff(
            $this->units,
            array( $unit ),
            function( $a, $b ) { return ($a === $b) ? 0 : 1; }
        );
    }
}

class UnitScript {
    static function joinExisting( Unit $newUnit, Unit $occupyingUnit ) {
        if ( !is_null( $comp = $occupyingUnit->getComposite() ) ) {
            $comp->addUnit( $newUnit );
        } else {
            $comp = new Army();
            $comp->addUnit( $occupyingUnit );
            $comp->addUnit( $newUnit );
        }

        return $comp;
    }
}

當(dāng)我們需要在某個子類，實(shí)現(xiàn)個性化的業(yè)務(wù)邏輯時，組合模式的缺陷之一正在顯現(xiàn)出來：簡化的前提是所有的類都繼承同一個基類，簡化優(yōu)點(diǎn)有時是以降低對象安全為代價。為了彌補(bǔ)損失的安全，我們需要進(jìn)行類型檢查，直到有一天你會發(fā)現(xiàn)：我們做了太多的檢查工作——甚至已經(jīng)開始顯著影響到代碼效率。

class TroopCarrier {
    function addUnit(Unit $unit) {
        if ($unit instanceof Cavalry) {
            throw new UnitException("不能將馬放置于船上");
            super::addUnit($unit);
        }
    }

    function bombardStrength() {
        return 0;
    }
}

組合模式的優(yōu)點(diǎn)正在不斷被數(shù)量越來越多的特殊對象所沖抵，只有在大部分局部對象可互換的情況下，組合模式才最適用。

另一個揪心的問題是：組合對象的操作成本，如果你玩過最高指揮官或者橫掃千軍，就會明白這個問題的嚴(yán)重性，當(dāng)你擁有了上千個戰(zhàn)斗單位，并且這些單位本身還分別屬于不同的番號，你每次計算某個軍隊(duì)數(shù)值，都會帶來龐大的軍隊(duì)開銷，甚至是系統(tǒng)崩潰。

我相信我們都能想到：在父級或最高級對象中，保存一個緩存，這樣的解決方法，但實(shí)際上除非你用精度極高的浮點(diǎn)數(shù)，否則要小心緩存的有效性（尤其是像JS一類的語言，為了做一系列的游戲數(shù)值緩存，我曾忽略了它的數(shù)值換算誤差）。

最后，對象持久化上需要注意：1. 雖然組合模式是一個優(yōu)雅的模式，但它并不能將自身輕松的存儲到關(guān)系型數(shù)據(jù)庫中，你需要通過多個昂貴的查詢，來將整個結(jié)構(gòu)保存在數(shù)據(jù)庫中；2. 我們可以通過賦予ID來解決 1. 的問題，可仍需要在獲取對象后，重建父子引用關(guān)系，這會讓它變得略顯混亂。

如果你想“如同操作一個對象般的隨心所欲”，那么組合模式的是你所需要的。

但，組合模式依賴于組成部分的簡單性，隨著我們引入復(fù)雜規(guī)則，代碼會變得越來越難以維護(hù)。

額外的：組合模式不能很好地保存在關(guān)系數(shù)據(jù)庫，但卻非常適合使用XML進(jìn)行持久化。

（持久化 = 保存）
（父類 = 超類，因?yàn)橛⑽亩际荢uperClass，額外的，你可能喜歡“直接繼承”、“間接繼承”的概念）

我發(fā)現(xiàn)，外國人往往采用實(shí)際應(yīng)用來教學(xué)，尤其是游戲之類的非常有趣的應(yīng)用，不知這是國外教學(xué)的傳統(tǒng)，還是我錯位的理解。