服务的单例/静态类
我有一个应用程序，其中有一些处理某些特定功能的类，其生命周期与应用程序本身相同，并且旨在用于程序的许多部分。由于最后一个原因，我将它们称为服务。 例如，音频服务播放音频文件并执行许多与音频相关的其他操作。
这些类仅在应用程序启动时实例化一次，并且每种类型拥有多个类没有任何意义。
由于我在这里阅读了许多关于单例的答案，其中不鼓励使用单例，所以我继续在需要时传递对 thoose 服务的引用。 随着项目的不断发展，我发现自己有许多类需要在其构造函数上提供服务引用，在某些情况下甚至需要这些服务的外观以避免添加所有服务引用。
我想我做错了。我认为这对于静态/单例类来说应该是一个很好的用途。
这是正确的做法吗？
I have an application which has some classes that handle some specific functions, have a lifetime equal to the application itself, and are meant to be used in many parts of the program. For this last reason i call them Services.
For example, the Audio Service plays audio files and does many other things related to audio.
Theese classes are instantiated only once at applications startup and it does not make any sense to have more than one per type.
Since i've read many answers about singletons here on SO where their usage is discouraged, i went on by passing a reference to thoose services when needed.
As the project is growing i find myself with many classes which need a service reference on their constructor and in some cases even a facade to those services to avoid adding all the services references.
I think i'm doing it wrong. I think this should be a good use for static/singleton classes.
Is this a correct approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
看来您需要一个具有一些自动装配功能的依赖注入容器。如果您使用 Java，请考虑 Spring。
It seems like you need a dependency injection container with some autowiring capabilities. In case you are using Java, consider Spring for example.
我看到一个答案建议引入 Spring。在幕后，Spring 仍在需要的地方传递该引用。
与其在应用程序中引入新的框架，为什么不直接使用单例呢？如果它能完成工作并且比传递服务引用更容易维护，我会说使用它。
如果您担心单例是因为它们对可测试性的影响，请使用依赖注入（该模式，而不是框架）以减少与实现的耦合。
I see one answer suggests introducing Spring. Under the covers, Spring is still passing that reference around where it is needed.
Rather than introducing a new framework into the app, why not just use a Singleton? If it does the job and is easier to maintain than passing a service reference around, I say use it.
If your concern about Singletons is because of their impact on testability, use Dependency Injection (the pattern, not a framework) to decrease coupling to an implementation.
Singleton 实际上代表在应用程序生命周期内只应创建一次的对象。这些对象实际上包含一些固定的设置。假设您有一个仅用于解析 html 的解析器类。 HTML 的根应该是“”标签。此外，您不想从此解析器类创建大量实例，因为类的每个实例都会执行相同的操作。实例将获取一串 html 并返回 X。
如果您认为您的类一次只做一件事，那么您可以选择单例。但是，如果您说，例如，您的音频服务应该一次播放不同的音频，我认为创建类的实例比使其成为单例更好。
Singleton actually stands for objects that should be created just only one time only during the application life cycle. These objects actually contain some of the fixed settings. Let's say you got a parser class that is for parsing just only html. The root of HTML should be "" tag. In addition, you don't want to create loads of instances from this parser class because every instance of class will do the same thing. Instance will get a string of html and will give you back X.
If you think that your classes will do just only one thing at a time, you can go for singleton. However, if you say that, for instance, your Audio Service should play different audios at a time, I THINK creating instance of a class is better than making it singleton.
我同意麦克格的观点。使用单例。既然你说这些类主要是面向服务的，我不认为它会引起任何问题。
I agree with MikeG. Use a singleton. Since you say these classes are mostly service oriented I wouldn't expect it to cause any problems.