※ 引述《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 能應用的地方了。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.231.49.183 ※ 編輯: qrtt1 來自: 61.231.49.183 (02/20 22:57)