※ 引述《mgtsai (战车引擎保修官)》之铭言： : 标题: Re: [问题] 反design pattern的见解 : 时间: Sat Feb 10 06:23:20 2007 : 我想讨论这个问题，不过，我不太想在这里把讨论的层级拉太高 : 所以，就拿一个我自己过去所接过的案件当作实际案例来当作一个小小 case study : -- : 推 tinlans:我有点好奇，你是不是让 visitor 做太多事情了，并不一定 02/10 16:14 : → tinlans:所有的事情都要给 Accept() 转呼叫的东西通通做完吧， 02/10 16:15 : → tinlans:反正会选用 visitor 的时候，已经决定破坏被 visit 对象 02/10 16:15 : → tinlans:的封装性了，你可以把相关的资讯记录在这两者之外的地方。 02/10 16:16 : → tinlans:包括需要这些资讯才能完成的动作，也一并抽出 visitor。 02/10 16:17 我自己对 Visitor 的定位，是以比较望文生义的方式来看待 既然是　 举个例子，就以 binary tree traversal 就至少有 pre-order, post-order, in-order 三种 而在进行每项任务时，会使用哪种 traversal 则是依状况而定 如果把整件事加以区分，我会指定以下机制： * Iterator 负责 tree traversal 方式 * 实际的任务执行，则於 Visitor 的 implementation class 中实作 (Visitor 本身则为 generic interface) 或者，在 Visitor 中弄个 delegation 把该执行的任务 delegate 到另一个 class hierarchy 里处理 * Visitor 则纯化为：它负责逛节点，藉由 accept() 对手中的任务进行 "分派" 至於逛节点的方式则由 Iterator 定义 至於执行什麽任务则由 implementation/delegation class 中处理 * 至於封装性的问题，则定义统一的使用介面，弄一个 Facade 供其它模组使用 就如同大家所述，使用 Visitor 时会碰到不少麻烦 甚至要完全依 GoF 的定义结构会碰上钉子 换句话说，虽然我们可以依照 pattern 的大方向进行 但面对实际的应用时，还是得牵就现实状况，作某种程度的调整 : 推 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 这个问题，我会在所对应的 Iterator 中加以处理相关的机制 而 Visitor 与其相关的界面，我会尽量固定住而不去动它 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 210.201.190.206