在建立前端几何编辑器时开发者常面临的痛点包括：多库兼容性差导致频繁改动代码；事件处理混乱让功能 和单元测试变得困难；撤销/重做实现笨重导致性能下降；还有模块耦合度高使得维护成本飙升。下面以“模式与原则”为主要。对这些痛点进行针对性拆解，并给出可落地的设计方案。

本篇简述

本篇，讲述用到的设计模式和设计原则。

规律可循。

模式一览

外观模式

用在哪儿:

宿主只面对一个门面装配、输入注入、事件出口、双入口全部收敛在门后。按理说，换地图库 = 换适配器，宿主代码不动。

策略模式

用在哪儿: IDrawStrategy / IModifyStrategy

绘制 / 变更能力可插拔。新增一种几何，只写一个新策略实现接口，其它控制器保持不动。把“行为”从“容器”里抽出来是 性的第一来源。

状态模式

用在哪儿: 策略内部 idle / placing / dragging

"同一个 onLeftDown 在不同状态下做不同事" 状态自管迁移。让事件处理规则从“一长串 if”变成“清晰子状态”，提高可测试性与可读性。

适配器模式

用在哪儿: MapAdapter / CoordinateAdapter

"库无关边界"。core 不认识任何地图库，适配器负责把 core 翻译成具体库渲染与拾取。把库事件翻译回 core 指令。换库只需改适配器即可，

观察者 / 事件

用在哪儿: 事件程序 + /EditorEvents/目录

"阶段对外通信、UI 联动、组件解耦，全靠事件"。说起来，目录先登记再实现，防止事件名漂移。

备忘录 / 快照

用在哪儿**:* getState/setState*

• "撤销/重做不靠命令栈，而是数据快照回放——这是备忘录模式"。

状态机 / 仲裁

用在哪儿**:* StateArbiter*

• "竞态仲裁这方面，一个时刻只有一个活动使用者"。所有输入先问仲裁器，拿到允许才继续。

flowchart TB
subgraph 模式
P1 --> P2
P2 --> P3
P1 --> P4
P1 --> P5
P3 --> P7
P2 --> P6
end

原则一览

• 接口优先，组合比更好继承。  用 Hoverable/Editable 标记接口约束“能力”。 类通过实现+组合获得能力，而不是继承膨胀基类；组合由外观类管理，怎么说呢。
• 依赖单向，分层收敛。说起来，  宿主 → 外观类 → 控制器 → core → 适配器。core 永远不知道地图库存在；适配器是“库无关”的边界；改动总在一层内发生，
• 单一职责，角色分明.  鼠标管家只管分发；拾取器只出命中不裁决，辅助图形不感知几何算法等。每个角色职责边界即“能否被替换”的度量。
• 状态即数据，历史归宿主.  库不维护历史；元素无交互状态，快照是数据层与行为层之间契约，使撤销/重做更轻量、性能更好。其实，
• 点显式化.  自定义取点模式、着色器、变换器样式等都显式留口。而非让调用方改类库，从而降低集成难度和维护成本。不过，

说到反模式。不这么设计会怎样，

常见做法 痛点产生原因	后果 影响	本系列替代方案 解决思路
业务判断写进鼠标回调 导致膨胀、不易维护 无法测试 无法替换 仅在鼠标管家里持久化选中/悬停状态 深拷贝 & 撤销全失效 元素静态化 行为归交互层 所有控制器各自监听鼠标并打架 输入收口 + 仲裁缺失 手柄/变换堆进编辑策略里加一种几何 直接 import 地图库到处，用导致切图失败 守住库无关边界缺失 & 换库需重写适配器

难以定位错误源头

使用外观+策略+观察者+仲裁+快照+适配子程序框架：

• 把所有入口集中到统一门面；
• 把业务逻辑拆成独立插件，可随时切换或升级；
• 统一发布订阅机制，实现 UI 与业务分离；
• 统一仲裁输入流，在多模态竞争下保持唯一消费权利；
• 撤销/重做完全基于快照。不依赖命令栈，使数据恢复更直观且性能友好；
• 抽象渲染与拾取交互，让项目可以无缝切换底层地图 SDK 而无需改动主要原因。此框架消除了上述痛点，使团队能够快速迭代并保证代码质量。
  示例配置文件请参见官方文档.

一条主线——清晰职责 & 单向依赖的精髓：

• 输入被收口到事件管家，使用者被仲裁决定；

元素是静止的数据对象——快照让撤销/重做归宿主；怎么说呢，

外观对象是唯一门面——适配守住库无关边界；

辅助图形与变换成为可插拔角色层—— 性由结构提供支持。

---