: : 推 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