※ 引述《tyc5116 (累人啊....)》之銘言：
: 如題,這是我看書想到的一個問題
: 我拿書上的題目來說,有四個class,分別是採購(Purchase),庫存(Stock),銷售(Sale)
: 以及一個中介者(Mediator)(不把虛擬的算進去的話)
: 彼此是有關聯性的,哪一天突然發現有bug,或想重構,或要修改功能,該怎麼下手呢?
: 我的問題點在於,以debug來說,假設我覺得Sale部份可能有問題
: 有辦法在過程中,先將Sale和其它class的關聯性切開,再除錯嗎?
各別的物件不管有幾個，只會與 Mediator 有關聯。
Mediator 就是為了避免讓個別的 instance 互相產生關聯而想出來的做法。
個別的 instance 都只會與 Mediator 建立關係(實際持有 reference)
不同的 instance 要互動，都是透過 Mediator 間接產生關係。
所以，邏輯上，不會出現：
『有辦法在過程中,先將Sale和其它class的關聯性切開,再除錯嗎?』
因為 Sale 在這個 Pattern 扮演的角色就只能與 Mediator 有實質的關係。
而 Mediator 的精要就是：
你已經有許多定義良好(責任明確且實作完整)的可獨立運作類別。
為了組裝他們成一個新的功能，土法煉鋼的方法之一就是：
繼承原先的類別，讓他們互相持有 instance。
(我相信正常人不太會這麼寫，這僅是一種 worst case 的例子)
這樣你去產生物件關聯圖就看到一堆線指來指去。
你也能用一些量測軟體測出一些指標，簡而言之，『亂寫』
當 Mediator 由過去的經驗中，被指名為一個 pattern 後，
你依這著這概念實作，對於這個 Pattern 有 sense 的會知道，
若是想理解這組東西的關係，可以直接看 Mediator 本身就好。
在『實作者良心』的驅使下，
我想它會盡力保持個別物件與 Mediator 有關係，
與其他物件保持一個 Mediator 的距離。
: 又或者哪天我覺得Mediator很亂了,要進行重構,可是有關聯性的class很多
: 有辦法將Stock和Purchase切開,對Mediator與Sale相關的程式碼重構
: 再依此類推,連接Sale,切開Stock,Purchase,重構
: 連接Purchase,切開Sale,Stock,重構.....
: 若這個觀念是不對的,麻煩請指正,若這觀念可行,麻煩請說明一下實作的方向
: 謝謝
如果你聽懂我的解說，我又沒有誤會您想表答的意思。
那就是你想錯了。
我將描述改變一下：
『如果我發現 Mediator 運作起來的連動效果，
不是合乎我的預期。我該如何做呢？』
『如果我發現 Mediator 運作起來的連動效果，
合乎我的預期，但它的實作真的很亂。我該如何做呢？』
情況一。
先檢查個別物件的邏輯是否正確，若有 TestCase 最好。
當個別物件都正確後，再來檢查 Mediator 的邏輯本身。
這時你需要能模仿個別物件狀態的工具，
不是你土炮 mock object，就是使用 library。
因為這步是測試 control flow 了，所以順序就變得重要了。
但通常會因執行次序而有不同結果的，有些常見的情況是：
*. static 造成狀態『遺跡』、『殘渣』，讓下一次結果不對
*. 多執行序產生的 race condition 等問題
*. 物件具有需要額外處理的狀態，
例如：交易管理，或其它需要 alloc/destroy 生命週期管理的物件
如果你無法 reproduce，我想可以請教一下有經驗的 QA，
他們對次序操作很在行的。
情況二。
所有東西都動得跟你想得一樣，但你就是不滿意現狀。
首先，你得完成為了測試情況一的所有 TestCase，與 bug 排除。
重構的事，我想這值得另外深入地學習，但有個小技巧。
你可以利用一下 sequence diagram，
先看一下整個圖的執行順序是不是易懂，
試著以 sequence diagram 調整到易懂為主。
除了排程式碼的順序，
那就是 rename/extract method 能應用的地方了。