【问题标题】:singleton / static classes for services服务的单例/静态类
【发布时间】:2011-08-23 12:57:23
【问题描述】:

我有一个应用程序,它有一些处理某些特定功能的类,具有与应用程序本身相同的生命周期,并且可以在程序的许多部分中使用。出于这最后一个原因,我称它们为服务。 例如,音频服务播放音频文件并执行许多其他与音频相关的事情。

这些类仅在应用程序启动时实例化一次,并且每种类型拥有多个类没有任何意义。

由于我在 SO 上阅读了许多关于单例的答案,因此不鼓励使用它们,因此我继续在需要时传递对这些服务的引用。 随着项目的发展,我发现自己有许多类需要在其构造函数上提供服务引用,在某些情况下甚至需要对这些服务进行外观以避免添加所有服务引用。

我认为我做错了。我认为这应该是静态/单例类的一个很好的用途。

这是一个正确的方法吗?

【问题讨论】:

    标签: service singleton


    【解决方案1】:

    您似乎需要一个具有一些自动装配功能的依赖注入容器。如果您使用的是 Java,请考虑使用 Spring。

    【讨论】:

      【解决方案2】:

      我看到一个答案建议引入 Spring。在幕后,Spring 仍然在需要它的地方传递该引用。

      与其在应用程序中引入新框架,为什么不直接使用单例?如果它完成了工作并且比传递服务引用更容易维护,我说使用它。

      如果您担心单例是因为它们对可测试性的影响,请使用Dependency Injection(模式,而不是框架)来减少与实现的耦合。

      【讨论】:

        【解决方案3】:

        Singleton 实际上代表只应在应用程序生命周期内仅创建一次的对象。这些对象实际上包含一些固定设置。假设您有一个仅用于解析 html 的解析器类。 HTML的根应该是“”标签。此外,您不希望从此解析器类创建大量实例,因为类的每个实例都会做同样的事情。 Instance 会得到一串 html 并且会返回 X。 如果您认为您的课程一次只做一件事,您可以选择单例。但是,如果您说,例如,您的音频服务应该一次播放不同的音频,我认为创建一个类的实例比使其成为单例更好。

        【讨论】:

          【解决方案4】:

          我同意 MikeG 的观点。使用单例。既然你说这些类大多是面向服务的,我不认为它会引起任何问题。

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 2011-08-30
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2012-11-26
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多