我花了最后几个小时阅读单身人士模式以及为什么不使用它，其中包括那些非常好的网站：
我猜你们中有很多人已经知道了这些。
看完我的代码之后，我显然是95％的程序员误解和误用了单例模式.21 在某些情况下，我可以清楚地删除模式，但有些情况下我不确定该怎么做：
我知道接受日志记录的单例是可接受的，其中一个原因是信息只会流入它们但不会返回到应用程序中（当然只是进入日志文件或控制台等）。
那些不符合标准但很多课程需要的课程呢？
例如，我有一个很多类都需要的设置对象。很多，我的意思是200多。
我已经阅读了其他一些SO问题，例如"Singletons: good design or a crutch?"，所有这些问题都指出了为什么不鼓励使用单身人士。
我理解其中的原因，但我还有一个主要问题：
如果不使用Singleton模式，如何设计一个需要单个实例的类，可以从任何地方访问？
我能想到的选择是：
答案 0 :(得分：2)
这是否已经被广泛讨论并且令人筋疲力尽？
没有滥用模式。如果您的软件按预期工作（包括可维护性和可测试性），那么您就是单身人士。
人们抱怨的是，单例模式比仅限制一个类有一个实例的影响更大。
如果这一切对您来说都不是问题：在整个地方使用单身人士。模式讨论是学术和发型。
并且 - 回答你的问题 - 检查monostate vs singleton线程：Monostate vs. Singleton
答案 1 :(得分：2)
这取决于您对设置对象的确切含义。
所有200个课程都需要所有设置;如果没有，为什么他们可以访问未使用的设置？ 设置来自哪里，并且有充分的理由说明为什么每个类都无法在需要时加载其设置？
但最重要的是，不要仅因为代码使用不受欢迎的模式而对工作代码进行更改。我只使用过一次单身模式，但我会再次使用它。
编辑： 我不知道你的约束，但我不担心文件的多次访问，直到它被证明是一个问题。我会将配置拆分为不同类/类组的不同文件，或者最好使用DB而不是具有不同表的文件，为每个类提供数据。
顺便说一句，我注意到，一旦你将数据放入数据库，人们似乎不再担心多次访问它，即使你最后还是要进入文件系统。
PS：如果其他选项不合适，我会使用单例...你希望数据全局可用，你不愿意使用依赖注入，你只希望文件被读取一次;你已经限制了你的选择，而单身人士并没有那么糟糕。