矢量图形编辑器的设计模式
PowerPoint 或 Illustrator 等矢量图形应用程序的最佳实践设计模式/架构是什么？专门用于构建工具-用户交互以及对复杂图形对象的操作（父子关系、形状和布局的几何约束）。
对以下方面的任何想法或体验：
What are the best practice design patterns/architectures for vector graphic applications like PowerPoint or Illustrator? Specifically for structuring tool-user interaction and action on complex graphical objects (parent-child relationship, geometrical constraints on shape and layout).
Any thoughts about or experiences with the following:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
控制器的嵌套有限状态机。将视图与控制器（MVC 或类似）分离。它总是对我有用。
更新：我花了一些时间阅读您的链接。一些背景：我已经研究和研究这些类型的编辑器 25 年了。我的建议是，嵌套的 FSM 作为控制器、MVC 或类似的，可能被称为超级设计模式，因为您可以看到这些设计组件多年来在不同的设计中多次出现，每次对不同的组件使用不同的名称。微软专利的荒谬之处在于，这些想法非常古老，只是被赋予了新名称。如果您查看您提供的其他链接，您会发现有很多相似之处（EditPart == Behaviour == Finite State Machine）。
因此超级模式如下：嵌套有限状态机，如 Harel 状态图中所示。超级国家处理许多子国家的共同行为；子状态处理更具体的行为。超级状态可以实现为超类，或单独的对象实例。无论哪种情况，在整个应用程序中，抽象地讲，您都有一个当前状态，即子状态。如果子状态无法处理输入消息，它将转到超级状态（仅使用继承或将消息传递给堆栈中的另一个对象）。
状态转换由输入消息触发。输入消息可能是对装饰的用户操作（并且装饰可能被装饰为要调用的子状态的名称）。或者它可能是键盘事件。您可能会看到一条称为命令的输入消息。
每个状态都有一个进入方法，通过它执行初始化，以及一个退出方法，通过它撤销任何未提交的更改。更改通常使用事务提交，并且已提交事务的堆栈形成撤消堆栈。
Nested finite state machines for controllers. Separation of view from controllers (MVC or similar). It always worked for me.
Update: I had some time to read up on your links. Some background: I have been studying and working on these types of editors for 25 years. My advice, nested FSMs as controllers, MVC or similar, might be called a super design pattern, because you can see these design components appearing many times over the years, in different designs, each time using different names for the different components. The absurdity of the Microsoft patent is that the ideas are very old, just given new names. If you look at the other link you provided, you can see there are a lot of similarities (EditPart == Behavior == Finite State Machine).
So the super pattern is as follows: nested finite state machines, as in a Harel state chart. Super states handle common behaviors across many sub states; sub states handle more specific behaviors. A super state can be implemented as a super class, or as a separate object instance. In either case, in the overall application, abstractly you have a current state, which is the sub state. If the sub state cannot handle an input message, it goes to the super state (either just using inheritance or by passing the message to another object in a stack).
State transitions are triggered by input messages. An input message might be a user action on an adornment (and an adornment might be decorated the name of a sub state to invoke). Or it might be a keyboard event. You may see an input message called a command.
Every state will have an entry method, whereby it performs initialization, and an exit method, whereby it reverses any changes not committed. Changes are typically committed using transactions, and a stack of committed transactions forms the undo stack.