: : 推 YuYuHo:vistor visit house,我覺得vistor最大的缺點 02/10 16:18 : : → YuYuHo:是帶給house太大的負擔 02/10 16:21 : : → YuYuHo:打錯字了,是visitor,剛打完麻將回來,win~~ya~~ 02/10 22:52 : : → YuYuHo:假如說house的內部節點其實是不穩定的型態,結果會造成 02/10 22:54 : : → YuYuHo:visitor的介面也變得很不穩定,很容易就搞得一團亂 02/10 22:55 : : → YuYuHo:通常採用visitor時,house本身的結構可能就很複雜了, 02/10 22:57 : : → YuYuHo:這時候還要管理節點的分派策略,還要維持節點穩定, 02/10 23:01 : : → YuYuHo:這表示house做好後就不能隨便更動,很容易牽一髮動全身. 02/10 23:02 : 請問不穩定的型態是什麼意義 : 是指需求改變？還是設計的失誤？ : 為什麼house做好後就不能更動，這和visitor有什麼直接的關係呢 : 如果不採用visitor的話，那麼原本要加在繼承樹上面的功能又該怎麼處理？ : 牽一髮動全身我同意 : 但是使用visitor pattern之後 : 動到的「全身」應該會比不用visitor pattern來得少吧？ : 抱歉，我實在是不懂YuYuHo的這段推文 : 照他的說法，visitor pattern看似限制住了house擴充或修改的彈性 : 但是我不這麼認為.... : 不採用visitor的話，當初用visitor在繼承樹上面加入的功能又該怎麼辦？ : 還有什麼更好的主意嗎？ 抱歉ㄚ~其實我都是在胡扯,被大大發現了.(都是因為打麻將的關係) 請容許我再胡扯一下. 首先先把場景定義清楚. 在場景中有房子(house),房間(room),與訪客(visitor). room就是內部節點,house是節點管理員,visitor就是節點操作者. house擁有很多型態不一的room,並且接受visitor的來訪. 在一個房子之中有很多種房間,有客廳,臥室,浴室,廚房,等等... 來訪者也有很多種,有女傭,女朋友,廚師,水電工,等等... 如果房間髒了,就打電話請女傭來打掃,肚子餓了,就請廚師來煮飯, 水管漏水,就請水電工來修理,想睡覺的時候...就去睡覺. 這樣說起來好像還滿合理的,這就是我最初的設計想法. house,room,visitor三者的認知關係. room與visitor是互相認識的. house則同時認識room與visitor. 女傭掌管客廳,廚師掌管廚房,水電工掌管浴室. 我當初覺得,既然room與visitor是一對一的映射關係(在種類上). 為什麼不乾脆把分派的事交給house來作就好了. 這樣還可以讓不相干的room與visitor各自獨立. 於是當女傭來的時候,我就直接把客廳丟給她, 廚師來的時候,就直接把廚房丟給他,水電工來的時候,就直接把浴室丟給他 這樣似乎也還算合理ㄅ. 在我實際實作的情況中,room這個角色是經常更動的, 廚房仍舊是廚房,可是三不五時就會新增方法, 每增加一次我就要再實作一個visitor,太麻煩了. 於是我又用了一個大絕招,我把方法呼叫改成需求命令, 就是說用事件訊息傳遞的方式來操控物件, 於是room只需要有一個方法. 虛擬碼: result room::HandleWhat( command cmd ) = 0; 一但把這個變動因子抽出來後,我發現room與visitor可以完全抽象化. 我甚至可以把能力動態附加到visitor身上,讓女傭會修水管. 情況越來越抽象,我開始飄到大氣層了. 最後我發現一個事實是,room是一個複雜物件,house也是一個複雜物件, 事實上除了house之外,沒有人知道如何管理room與visitor. 所以所有的visitor都會在house的私有層被實作. 我還把操作方法抽成命令需求,變成一堆不易理解command物件. 複雜度太高了,載入大腦要耗費太多的查克拉. 我真的上天堂了. 最後我了解到,我做的一切都是在畫蛇添足. 在我完成程式,並且穩定的運作後. 我看著我寫的程式碼,不經要讚嘆,哇~這是哪個天才寫的呀! 這真是太玄了!一般人大概寫不出如此深遂又富有詩意的偉大程式吧! 在我對我的程式讚嘆不已後,我決定還是回到地球比較好. 我知道錯了. 以上純屬虎爛,如有虛構,既不負責.感恩ㄚ~ --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.113.133.56