代码之家 › 专栏 › 技术社区 › StormianRootSolver

应用程序范围的消息传送…没有单件?

code-smell messaging design-patterns language-agnostic

1

StormianRootSolver · 技术社区 · 16 年前

所以,我想在未来进行一个更为单一的设计。然而,在一个应用程序中,似乎有很多任务没有单例就无法以有意义的方式完成。

我称它们为“应用程序范围的服务”,但它们也属于与横切关注点相同的类别,我通常通过AOP解决这些问题。

让我们举个例子:

我想要一个应用程序范围的消息队列,它将消息发送到组件,每个组件都可以在那里订阅和发布,这是一个非常好的多播事情。

消息队列和调度系统通常是一个(相当短的)单例类,很容易在C中实现。您甚至可以使用双重调度和消息类型元数据等,这一切都很容易做到,几乎是微不足道的。

然而,拥有单例并不是真正的“面向对象设计”(它引入了全局变量),这使得测试更加困难。

你有什么想法吗?我问这个问题是因为我愿意更多地了解这个话题。-)

编辑:

我感谢你们迄今为止的回答。我想我问错了问题,也许应该是“单身汉真的那么坏吗?”.

有点混乱…人们告诉你“噢,单身汉,臭气熏天!!11“在所有地方-另一方面,它们似乎是解决这些应用程序范围问题的最简单和最直接的解决方案。

这是我目前的“症结”之一。解开这个谜。

2 回复 | 直到 16 年前

1

2

alex 16 年前

如果您以应用程序代码的方式讨论单例:

MessagingClass.getInstance().doStuff()

在您的方法中,一种选择是使用“依赖注入”。这意味着,使用相同的messagingClass,但在创建时通过构造函数或setter将其提供给使用它的类。

这样,您可以在不同的情况下提供不同类型的messagingClass。

注意,你不要做到这一点,需要对任何类型的依赖注入框架。

编辑:依赖项注入的关键是,您的代码不会到处寻找它需要工作的类(依赖项),它会在创建时“注入”它们。这样,获取依赖项就不会与代码的其余部分混合在一起,这似乎非常有用。

2

1

bobah 16 年前

当以集中的方式管理所有应用程序范围服务/类的生命周期时,更容易理解软件是如何工作的。我喜欢 JNDI .

在您的案例中,我将有一个应用程序范围的队列管理器实例可用JNDI或类似的服务。管理器将根据配置提供程序通过相同机制发出的第一个请求进行初始化。

通常,当您需要构建一个企业多层次系统时, J2EE 是一个检查已经发明和使用的东西的好地方。