为什么事件类型通常存储在事件的类定义中？
在我遇到的所有 ActionScript 示例中，人们使用自定义事件的类定义中定义的类型来编写自定义事件。但是，根据我的经验，调度事件的对象拥有自己的该事件定义（在 ActionScript 3 中是一个字符串）更有意义。
[编辑：写完这个问题后，我发现这两个位置都有情况——在某些情况下，事件类型应该存储在事件对象上，而在其他情况下，它们应该存储在调度事件的对象上.]
请告诉我您对此有何看法以及您发现自己存储事件类型的位置。
In all the ActionScript examples I come across, people write custom events with the types defined inside the custom event's class definition. But, in my experience, it makes more sense for the object dispatching an event to own its own definition of that event (which, in ActionScript 3, is a String).
[EDIT: After writing this question, I've found there to be cases for both positions -- in some situations, event types should be stored on the event object, and, in others, they should be stored on the object dispatching the event.]
Please tell me what your take is on this and where you find yourself storing event types.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在过去的几年里，我实际上一直在使用这些技术的组合，主要是在 PureMVC 的背景下。 Flash 实例（视图组件）捕获 Flash 事件，然后分派事件，其中类型是该类中定义的静态字符串。中介器捕获视图组件事件，然后发送在中央应用程序外观类中定义的注释的通知。我还尽可能地不子类化 Event，并尽量减少在笔记正文中传递数据。
我认为这可以最大程度地灵活地重新设计接口和应用程序逻辑，并且还可以在应用程序之间提供更多代理和中介/组件的重用。
Over the last few years, I have actually been using a combination of these, mainly in the context of PureMVC. Flash instances (view components) catch Flash events, and then dispatch an Event, where the type is a static string defined in that class. The mediator catches the view components events, and then sends notifications where the notes are defined in the central application facade class. I also try as much as possible to not subclass Event, and to minimize passing data around in note bodies.
I feel that this allows the most flexibility to rework both interfaces and application logic, and also provides more reuse of proxies and mediators/components between applications.
如果事件调度程序具有与事件定义相关的代码，则调度程序可以说是内聚的。我更倾向于让事件调度程序实现一个稳定的接口，从而保护它免受事件变化的影响。这也将减少与调度程序的耦合，并在处理事件时提供更大的灵活性。
If event the dispatcher has code pertaining to the definition of the event than the dispatcher arguably is in-cohesive. I would tend more towards having the event dispatcher implement a stable interface thus protecting it from variations in the events. This will also reduce coupling to the dispatcher and allow for greater flexibility in handling events.