自定义 Actionscript 3.0 事件:为不同目的构建单独的类还是使用一个类来满足所有目的?

发布于 2024-08-11 20:24:37 字数 291 浏览 6 评论 0原文

我第一次在 Actionscript 3.0 中使用自定义事件,我不确定如何最好地设计它们。我需要一些活动。其中一些需要传输不同类型的数据,有些则不需要。现在我不知道是否应该使用单个类来实现所有这些,还是使用单独的类来实现不同的目的。 为每种数据创建自己的事件类对我来说似乎有点混乱,因为这些事件基本上仍然会做同样的事情。但我也不太喜欢单一课程的选择。这个类需要一个通用变量来存储任何类型的数据,这些数据也会经常被使用。另外,我必须对我想从中访问的所有数据进行类型转换。如果有时需要运输多个物体怎么办? 哪一种是可行的方法(风格方面)还是还有另一种我没有想到的方法?

I'm using custom Events in Actionscript 3.0 for the first time and I'm unsure about how to best design them. I need a couple of Events. Some of them need to transport different kinds of data and some don't. Now I don't know whether I should use a single class to implement them all or use separate classes for different kinds of purposes.
Creating an own event class for every kind of data seems a bit messy to me since these events would basically all still do the same thing. But I don't really like the option with a single class that much either. This class would need a generic variable to store any kind of data which would also be unused a lot of the times. Also, I would have to typecast all the data I want to access from it. And what if there are sometimes multiple objects to be transported?
Which one is the way to go (style wise) or is there another way I haven't thought of?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

黯然#的苍凉 2024-08-18 20:24:37

我认为这取决于上下文。凯恩戈姆的一般最佳实践是严格限制新活动的目的。我经常看到事件类型到事件类到命令的一对一映射。如果不明确的话,这没什么。

另一方面,FlexEvent 有多种不同的用途,(从技术上讲)这是一个自定义事件。这在其上下文中是完全合理的——它通常与 DisplayObject 的渲染事件并行运行...

如果您只是在谈论新的事件类型(并且不需要携带额外的数据),请不要重新-发明轮子——事件采用类型作为参数。将新类型存储在某个公共静态常量中,然后使用它。

如果您确实需要携带数据,我的一般建议是尽可能使用强类型变量,这样您将受益于编译时错误。如果这可以变得更通用(例如,IList 而不是 ArrayCollection),那就更好了,但是除此之外,代码越明确就越容易。

I think it depends on the context. Cairngorm's general best practices are to severely limit the purposes of new Events. I've often seen a one-to-one mapping of Event Types to Event Classes to Commands. This is nothing if not explicit.

On the other hand the FlexEvent has quite as variety of different uses, and that is (technically) a custom event. That makes perfect sence in its context -- it is generally functioning as a parallel to the rendering events of the DisplayObject...

If you're just talking about a new event TYPE (and no extra data needs to be carried) do not re-invent the wheel -- Event takes type as a parameter. Store the new type in some public static constant, and then use that.

If you do need to have data carried, my general recommendation is to err or the side of strongly-typed variables wherever possible, this way you'll have the benefit of compile-time errors. If this can be made more generic (say, IList instead of ArrayCollection), that is better, but, barring that, the more explicit that you make your code the easier.

九公里浅绿 2024-08-18 20:24:37

我怀疑找到正确的平衡就像走钢丝一样,而且很多都是个人喜好,但我一直认为事件越多越好,原因如下:

1)代码优化 - 如果你只是需要发送一个字符串,不要将其传递到一个对象中 - 这会产生比您需要的更多的复杂性。同样,如果您的数据负载必须庞大且复杂,则单个对象可能还不够。我认为,根据数据负载创建不同的事件类型是最低限度。

2) 代码可读性 - 是的,在像 Cairngorm 这样有十亿个事件的地方它会变得复杂,但你知道吗?我总是确切地知道事件的作用,并且对于它来自哪里从来没有任何疑问。如果您正在开发一个足够大的项目,A)其他人会阅读您的代码,或者 B)随着时间的推移您可能会忘记每个事件的作用,那么我绝对建议将所有事件分解为自定义类。

希望有帮助!

I suspect that finding the right balance becomes a tightrope walk and that a lot of this is personal preference, but I've always felt that it's better to have more events than fewer for a couple of reasons:

1) Code Optimization - if you just need to send a string, don't pass it in an object - that creates more complexity than you need. Likewise, if your data payload has to be huge and complex, a single object may not be enough. Creating different event types based on your data payload is, I think, a bare minimum.

2) Code Readability - yes it gets complex in something like Cairngorm with a billion events, but you know what? I always know exactly what event does, and there's never any question about where it's coming from. If you're working on a large enough project that A) other people will read your code or B) you may forget over time what each event does, then I'd definitely suggest breaking all the events into custom classes.

Hope that helps!

暮倦 2024-08-18 20:24:37

我想使用一个自定义事件类就足够了。

public class CustomEvent extends Event {
  public var data:Object;
  public function CustomEvent(type:String, cData:Object) {
    super(type, true);
    this.data = cData;
    return;
  }
}

And while dipatching any custom event pass data via data object.

dispatchEvent(new CustomEvent("eventWithData", {somedata:value, somemoredata:value}));

I guess using one custom event class is good enough.

public class CustomEvent extends Event {
  public var data:Object;
  public function CustomEvent(type:String, cData:Object) {
    super(type, true);
    this.data = cData;
    return;
  }
}

And while dipatching any custom event pass data via data object.

dispatchEvent(new CustomEvent("eventWithData", {somedata:value, somemoredata:value}));

猥琐帝 2024-08-18 20:24:37

实际上,与大多数其他代码一样,它取决于理解正在发生的事情的难易程度。如果使用一种类更容易,则使用一个类;如果使用更多特定于用例的类更容易,则使用更多类。

就 Actionscript 而言,只有一个类可以节省一些字节,但编程最佳实践始终是最有利于代码重用和最容易理解代码的做法。

您还可以根据需要在自定义事件上放置任意数量的特定于类型的公共属性,并且仅从您需要的属性中进行分配或检索,而不是使用一个通用数据属性。

Really it depends on, like most other code, how easy is it to understand whats going on. If its easier with one class, use one, if its easier with more use case specific classes, use more.

Actionscript wise, youll save a few bytes on having just one class but the programing best-practice is always what is best for code reuse and easiest for code understanding.

You can also put as many type specific public properties on your custom event as you like and only assign or retrieve from the one you need instead of having one generic data property.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文