Swiz 强制要求弱封装

发布于 2024-08-20 15:49:59 字数 252 浏览 12 评论 0原文

我刚刚开始使用 Swiz,而且 Swiz 似乎迫使您创建封装较弱的类。 Swiz 要求所有事件处理程序都是公开的,以便调解事件。

假设组件“A”调度了一些事件,我想在组件“B”中监听这些事件。传统上,我只会在“B”中的“A”上添加事件侦听器,并且“B”中的所有事件处理程序都可以保持私有。但是,如果我使用 Swiz,我需要将所有处理程序、中介事件公开。

我在这里错过了什么吗,有没有办法绕过这个问题。我真的不想污染我的班级的公共界面。

谢谢。

I just started using Swiz, and, it seems like Swiz forces you to create classes with weak encapsulation. Swiz requires all event handlers to be public in order to mediate events.

Assume that component 'A' dispatches a few events, which I want to listen to in component 'B'. Traditionally, I'll just add event listeners on 'A' in 'B' and all the event handlers in 'B' can be kept private. However, if, I am using Swiz, I need to make all the handlers, mediating events, public.

Am I missing something here, is there a way to bypass this problem. I really, don't want to pollute the public interface of my class.

Thanks.

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

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

发布评论

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

评论(4

所谓喜欢 2024-08-27 15:49:59

正如我在邮件列表中提到的,不幸的是,没有办法解决这个问题。由于无法访问类的私有成员,B 可以使用事件的私有事件处理程序的唯一方法
from A 的情况是如果从 B 内部调用 addEventListener() 。由于 Swiz 显然不在您的类中运行,因此它无法访问这些成员。

Swiz 的目标是让您的应用程序代码尽可能不受 Swiz 类的引用(包括继承)。因此,您可以将其视为“从外部”配置您的应用程序。与 JVM 不同,Flash Player 根本不允许访问私有成员,因此 Swiz 要想与您的代码交互,它必须是公共的。

As I mentioned on the mailing list, there is no way around it, unfortunately. Since there is no way to access private members of classes, the only way B can use private event handlers for events
from A is if addEventListener() is called from within B. Since Swiz is obviously not operating within your classes, it has no way to access those members.

Swiz aims to keep your application code as free from references (including inheritance) to Swiz classes as possible. Therefore, you can think of it as configuring your app "from the outside". Unlike the JVM, Flash Player simply allows no access to private members, so for Swiz to interact with your code, it has to be public.

不…忘初心 2024-08-27 15:49:59

您还可以创建一个自定义命名空间,使它们不一定是公共的,但也不是私有的。我使用 Openflux 最初所做的:

[Mediate(event="UserEvent.LOGIN")]
metadata function loginHandler(user:User):void
{
    ... with namespace
}

[Mediate(event="UserEvent.LOGOUT")]
public function logoutHandler(user:User):void
{
    ... without namespace
}

然后您必须将 use namespacemetadata 添加到 Swiz 处理器,可能还有他们的 元数据 MediateQueue。只要在正确的类中导入命名空间,动态引用方法的东西就可以工作:

因此在 MediateProcessor 中的 setUpMetadataTag 方法(或类的顶部)中:

use namespace metadata;
// bean.source[mediateTag.host.name]
// service["loginHandler"] and service["logoutHandler"] both work
addMediatorByEventType( mediateTag, bean.source[ mediateTag.host.name ], eventType );

使代码干净,并防止事情公开。但有些人认为这工作量太大:)。

最好的,

You can also create a custom namespace that makes them not necessarily public, but not private either. I use what Openflux originally did:

[Mediate(event="UserEvent.LOGIN")]
metadata function loginHandler(user:User):void
{
    ... with namespace
}

[Mediate(event="UserEvent.LOGOUT")]
public function logoutHandler(user:User):void
{
    ... without namespace
}

You then have to add use namespace metadata into the Swiz Processors, and probably to their metadata MediateQueue. As long as the namespace is imported in the correct classes, something that's dynamically referring to a method will work:

so in the setUpMetadataTag method in MediateProcessor (or at the top of the class):

use namespace metadata;
// bean.source[mediateTag.host.name]
// service["loginHandler"] and service["logoutHandler"] both work
addMediatorByEventType( mediateTag, bean.source[ mediateTag.host.name ], eventType );

Makes the code clean, and keeps things from being public. But some people think it's too much work :).

Best,
Lance

岁月苍老的讽刺 2024-08-27 15:49:59

对于类之外且与类解耦的东西来调用处理程序,该方法不能是私有的。所以你有两个选择:将它们公开并让 Swiz 调解它们(并获得所有松散耦合),或者将它们保持私有并且不使用事件调解。如果您认为值得(大多数人都这样做),请使用它。如果你不这样做,就不要这样做。

For something outside of and decoupled from the class to invoke the handler, the method can't be private. So you have two choices: make them public and let Swiz mediate them (and reap all the loose coupling), or keep them private and don't use the event mediation. If you think it's worth it (and most do), use it. If you don't, don't.

深爱成瘾 2024-08-27 15:49:59

“Swiz 要求所有事件处理程序都是公开的,以便调解事件。”

确实如此,但 Swiz 的优势在于它不会强迫您进行任何(或多或少)设计选择,它只是提供强大的工具(依赖项注入、事件中介等),您可以选择将其应用在您认为合适的地方。

使用 Swiz 根本不需要使用 [Mediate] 标签 - 您仍然可以使用 addEventListener() 并像平常一样从私有方法中监听(我相信您很清楚)。据我所知,Swiz 事件中介主要用于系统/应用程序级别的事件。如果您在单个组件或紧密系列组件中调用事件侦听器,则通常会使用标准事件侦听器。要在各个不相关的组件之间进行通信,您可以使用 Swiz 的中介程序来处理消息。

简而言之,在任何情况下,如果您有权访问私有事件侦听器(即在封闭组件内),您可能不会使用 [Mediate] 来捕获事件,因此侦听器可以保持私有。当您使用 [Mediate] 标签时,事件处理程序通常位于应用程序中完全独立的位置(例如演示者 -> 控制器),在任何情况下它实际上都不能是私有的。

我可能有点不对劲,但这就是我的看法。在某些情况下,Swiz 可能鼓励弱封装,但对我来说,它总体上提供了更好的模块化。

"Swiz requires all event handlers to be public in order to mediate events."

That's true, but Swiz's strength is that it doesn't force any (more or less) design choices on you, it just provides powerful tools (dependency injection, event mediation, et al) that you can choose to apply where you think appropriate.

Using Swiz does not require the use of the [Mediate] tag at all - you can still use addEventListener() and listen from private methods as you normally would (as I'm sure you're well aware). As far as I can tell, the Swiz event mediation is intended primarily for use with system/application level events. If you're calling event listeners within a single component, or within close family components, you would usually use the standard event listeners. To communicate between individual, otherwise-unrelated components, you can handle the message with Swiz's mediator.

In short, in any case where you have access to private event listeners (i.e. within close components), you probably wouldn't be using [Mediate] to capture the event, and so that listener could remain private. When you're using the [Mediate] tag, the event handler is generally in a completely separate location in the application (e.g. presenter -> controller) where it couldn't practically be private in any case.

I may be slightly off, but this is how it appears to me. Swiz may encourage weak encapsulation in some situations, but to me it offers greater modularisation overall.

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