zhuisui

倾向于用一组特别命名的私有方法去处理副作用，甚至单独封装成一个内部类，把状态对象的修改都放到里面，visitor 像调用纯函数一样调用这组方法。

在 windows 下只在睡眠模式下成功过，休眠模式失败，雷蛇笔记本。
linux 没试过 wifi ，只试过 lan 。
这个也分电脑。

你要想充分利用 git merge 的自动冲突解决能力，就不要做 squash 、fixup 、amend 、cherry-pick 这类会修改 commit 的操作，你必须在 merge 时原样保留各路 branch 。
你只要记住，如果你要 merge branch ，一定要保留 branch 原来的样子。因为 git 就是利用 branch 和 merge commit 来决定冲突解决结果的。

@netabare 我这样整体地描述该模式，看看是否命中了你的疑惑，因为我觉得可能你对这个模式的运转方式理解错了。

首先有一组固定类型的 object ，每个 object 内有多种类型的 element ，然后有多个 visitor 可以处理这组 object 。
每个 visitor 定义了一种将这组 object 输出为一种形式的业务逻辑，那么多个 visitor 分别代表可以输出不同形式的业务逻辑，visitor 之间是互相独立的。每种 element 需要对应一个 visitor 的 visitXXXElement 方法的实现。该方法的调用通过 element.accept 来做 dispatch ，这样就避免了业务侧用 switch case 做模式匹配，仅需 iterate elements 的 accept 方法即可完成调用。
其中关于 accept 的返回值，如果对这组 object 进行 visit 的结果是顺序的列表，自然可以直接将返回值简单地 map 为顺序列表。但如果 visit 的结果是其他复杂的类型，这部分业务逻辑必须由 visitor 在内部暂留状态，在整体 visit 结束后通过注入 end 的方法返回。这完全取决于要处理的业务，这部分不是该模式的核心。
其中关于 iterate elements ，这部分甚至也可以做到 visitor 的基类中，取决于 elements 的顺序如何产生，是统一的还是无关的。这部分不是该模式的核心。

举个例子，把一种 tree 输出为 json 、xml 、table 不同格式的业务。这里 tree 就是 object ，各种 tree node 就是 element ，json xml table 各需要一种 visitor. 其中对于 xml 如果选择用 element 嵌套的格式来表示输出形式，那么自然不可能直接由 accept 返回，因为整体结果是个 xml root element.

再补充一些各类现实情况：
- 什么情况下不能用开关控制：各定制功能客户要求不能将自己分支的源代码或功能泄漏给第三方。
- 什么情况下不适合用开关控制：定制功能基本没有共性，但代码同时存在，存在被互相引用的风险（当然这个可以用 lint 或 review 来控制）
- 多个定制方都需要相同的功能：1. 尽量从一开始设计好 2. 开发时，应从 base 分支创建分支，然后将该分支合并到各定制业务分支上
- 什么情况下不要用分支管理，而是分 repo：业务的技术实现会完全分叉，不管是基础库，还是业务框架，都会变得迥异，那么就没必要使用分支来确保同一个 base 代码了

我想说，大概就是因为你搞错了翻译，使得你理解错了这个模式。
visitor 不是观察者，visitor 是访问者。
visitor 模式用来解决的业务问题是——将访问图等各类对象数据结构的算法和其具体的业务逻辑分离，这里面 visitor 指的是 visit objects 。

至于该模式的具体实现，是否 accept 有返回值，不是首要重点，但也很重要，符合了最广泛的一种业务模式。
像 https://refactoring.guru/design-patterns/visitor 中的实现，无返回值。试想，如果 client 调用各类 ele 的 accept 返回各种 node 的处理结果，那么这些结果就需要由 client 自己集合为最终结果，但这部分是具体业务逻辑，应该由具体的 visitor 实现来负责。

对于 git 来说，你这两种模式没区别，都是 branch.
你说 fork 的时候是不是指 github 上的 repo 。这时候这两者的区别在于 repo 层面的管理，包括 org 、member 、permission 什么的。

你这种需求——拆出去、合回来，用 branch 管理是最合适的，设计好各种条件下如何建分支就好了。不要用什么 cherry-pick 甚至多项目。

大概是运行时生成的代码吧

能流畅使用基本的编辑功能就够了。
其他 IDE 能覆盖的也不需要费劲折腾 vim

可以从日常开发找痛点和提效出发