太多的单身项目 - 它是一个不好的做法？ [英] Too much singletons in the project - is it a bad practice?

问题描述

在几乎每一个项目我创建一个实现Singleton模式几类。例如，数据管理器 - 如果有一个与文件系统，数据加载一些工作 - 如果一个应用程序连接到互联网，不同的资源管理器等，有时有多达5-7这样的班，我开始觉得，我做有问题。它是一个不好的做法是使用Singleton模式太多了？

In almost every project I create a few classes which implement Singleton pattern. For example, data manager - if there's some work with file system, data loader - if an application connects to the internet, different resources managers, etc. Sometimes there are up to 5-7 such classes and I start feeling that I'm doing something wrong. Is it a bad practice to use Singleton pattern too much?

推荐答案

单身没有的不一定的问题 - 有一个单一的对象，它是在其领域的专家是非常有用的 - 但明确编码单岬到对象几乎总是一个坏主意（并且经常太不好做）。事实证明，这是更好地离开应用程序的配置 - 包括哪些类具有单实例的决定 - 专门在一个单独的层，如Spring的Java。这样，管理层之后，什么是单可以看看，什么是在特定范围内一个单（例如，会话的范围内），什么总是需要被重新制造。这使得您可以专注于编写业务逻辑。

Singletons are not necessarily problems — having a single object that is an expert in its domain can be very useful — but explicitly coding the singleton-ness into the object is almost always a bad idea (and frequently is done badly too). It turns out that it is better to leave the configuration of the application — including the decision of what classes have singleton instantiations — to a separate layer that specializes in that, such as Spring for Java. Like that, the management layer can look after what is a singleton, what is a singleton within a particular context (e.g., within the scope of a session) and what always needs to be manufactured anew. That leaves you free to focus on writing the business logic.

有关为什么单身可能是问题的一个例子，为什么他们应该通过管理/配置是单身，考虑到管理一个数据库连接的类。经典案例你可能会说单身。你是对的也一样，直到，直到你找到你的应用程序已经发展到它必须连接集成到两个数据库（它发生！），然后你必须理清整个混​​乱的地步。如果你已经把的您的code不可知无论是处理单身与否，你站的是能够通过重新配置只是处理这一切一个极好的机会;有的班级将被连接到一个数据库和一些其他的，但他们就会得到它以最小的大惊小怪。 （任何需要两个......好吧，这就是为什么我说：很好的机会。）

For an example of why Singletons can be problems and why they should be singletons by management/configuration, consider a class that manages the connection to a database. Classic case for a singleton you might say. You'd be right too, right up until you find that your app has grown to the point where it has to integrate connections to two databases (it happens!) and then you've got to disentangle the whole mess. If you've kept your code agnostic of whether it is dealing with singletons or not, you stand an excellent chance of being able to handle it all by just reconfiguring; some classes will be connected to one DB and some to the other, but they'll just get on with it with minimal fuss. (Anything that needs both… well, that's why I said "excellent chance".)

为什么单身人士可问题的另一个例子，当你写你的code测试中来。 （你做的编写测试，是吗？）显式单身是很难测试，因为他们是难以配置和硬隔离开来。因为这意味着有很多人不能测试之间撕裂下来正常。如果您的应用程序只能通过配置使用单身，测试配置可以很容易地改变这一点，你可以更轻松地完成你的测试。

Another example of why Singletons can be problems comes when you're writing tests for your code. (You do write tests, yes?) Explicit singletons are very difficult to test, as they're hard to configure and hard to isolate. You can't tear them down properly between tests because that implies having many of them. If your app uses singletons only by configuration, a testing configuration can easily change that and you can do your tests far more easily.

这篇关于太多的单身项目 - 它是一个不好的做法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！