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

看板OOAD作者 (lonely)時間12年前 (2012/02/20 22:57), 編輯推噓0(001)
留言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)

02/20 22:58, , 1F
PS. 我手邊只有 design patterns 這本參考書
02/20 22:58, 1F
文章代碼(AID): #1FGbzEpf (OOAD)
討論串 (同標題文章)
文章代碼(AID): #1FGbzEpf (OOAD)