Re: [概念] 中介者模式的疑問

看板OOAD作者qrtt1 (lonely)時間12年前 (2012/02/20 22:57)推噓0(0推 0噓 1→)

留言1則, 1人參與討論串2/3 (看更多)

※ 引述《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)