项目中有太多的单身人士 - 这是一种不好的做法吗? [英] Too much singletons in the project - is it a bad practice?

问题描述

几乎在每个项目中，我都会创建一些实现单例模式的类.例如，数据管理器——如果有一些文件系统、数据加载器的工作——如果应用程序连接到互联网、不同的资源管理器等.有时有多达 5-7 个这样的类，我开始觉得我在做有事吗.过多地使用单例模式是不是不好的做法?

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?

推荐答案

Singleton 不是必然问题——拥有一个是其领域专家的单个对象可能非常有用——但明确编码对象中的单例性几乎总是一个坏主意(并且经常做得也很糟糕).事实证明，最好将应用程序的配置——包括决定哪些类具有单例实例化——留给专门从事该工作的单独层，例如 Java 的 Spring.像那样，管理层可以管理什么是单例，什么是特定上下文中的单例(例如，在会话范围内)以及什么总是需要重新制造.这样您就可以自由地专注于编写业务逻辑.

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.

要举例说明为什么单例会出现问题以及为什么它们应该通过管理/配置成为单例，请考虑管理与数据库连接的类.您可能会说单身人士的经典案例.你也是对的，直到你发现你的应用程序已经发展到必须将连接集成到两个数据库的地步(它发生了！)然后你必须解开整个混乱.如果您让您的代码不知道它是否正在处理单例，那么您很有可能通过重新配置来处理这一切；一些类将连接到一个数据库，一些类连接到另一个数据库，但他们会毫不费力地继续使用它.(任何两者都需要的东西……嗯，这就是我说极好的机会"的原因.)

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".)

当您为代码编写测试时，另一个说明为什么单例会成为问题的例子.(您确实编写了测试，是吗?)显式单例很难测试，因为它们很难配置且很难隔离.你不能在两次测试之间正确地拆除它们，因为这意味着有很多.如果您的应用仅通过配置使用单例，则测试配置可以轻松更改这一点，您可以更轻松地进行测试.

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屋！