我想讨论这个问题，不过，我不太想在这里把讨论的层级拉太高 所以，就拿一个我自己过去所接过的案件当作实际案例来当作一个小小 case study 就以 Visitor pattern 而言，在 GoF 那本书中已经讲得很清楚 我就不用再赘述 不过，在我多次的案件实作过程中，在使用 Visitor pattern 时 会遇上一个让我觉得不太算是麻烦的小问题 * * * * * * * * * * 就以我过去的经验而言，使用 Visitor pattern 的时机 有七八成以上是用於不同型态 node tree 的 traversal （通常会另外配合 Iterator pattern 实作） 而在 visit 每一个节点时，有许多时机，会需要其它资讯 比如，该 visitor 倒底位於 tree 中的哪个位置 或者该 visitor 过去的足迹等。 当有这类的需求时，这意味着，必须额外准备一个变数 记载该位 visitor 在此次的 tree traversal 中，访问到某个节点时的暂时性状态。 而这个状态数变就在这次 traversal 的过程中才会用到 当 tree traversal 结束後，这个状态变数就不再使用 * * * * * * * * * * 如果完全依 GoF 的 Visitor pattern 的实作法则而言 像上述 tree traversal 所使用的状态变数 可以 hacking 在 visitor class 的 property 中 但，这样做可能会有些问题，同一 visitor 由於可能进行不同的任务 在进行各种类型的各别任务时，所使用的状态变数型别都不一样 如果把这些不一样的状态变数，都一一列为 visitor 的 property 时 这时，就完全破坏了 visitor class 的封装性 （试想，如果要进行一两百项任务，visitor 要列出对应的一两百个 property 再准备对应的一堆 accessor methods，那 visitor class 倒底长成什麽得性） 所以，在我真正的实作中，就没有完全按照 GoF 所列的那个 Visitor pattern 而是稍加变形，把 traversal 状态变数从 visitor class 中抽离出 再将此状态变数当作 accept() 的参数丢入对应的 method implementation 处理 * * * * * * * * * * 就以这个在我过去的实际经验中所经常遇见的状况而言 GoF 中的 Visitor pattern 是给我一个方向上的指引 但在实际的应用中，仍得根据实际的状况，做某种程度的调整修改 * * * * * * * * * * 要我说什麽心得，我倒没有什麽特殊意见 毕竟这篇文章的着手处是从单一的 case 下手 而不是以站在高空往下看的角度来看问题 不过，多多讨论在真实案例中，对於各种 design pattern 的实际实作情形的讨论 也可以作为一个讨论主轴，实际检讨落实 design pattern 所遇到的种种问题 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 210.208.46.43 ※ 编辑: mgtsai 来自: 210.208.46.43 (02/10 06:25)