扩展单例类是错误的吗？答案

【问题标题】：Is extending a singleton class wrong?扩展单例类是错误的吗？
【发布时间】：2012-03-26 17:26:20
【问题描述】：

我正在为应用程序创建记录器。我正在使用第三方记录器库。其中记录器被实现为单例。

我扩展了该记录器类，因为我想添加更多静态函数。在这些静态函数中，我在内部使用 Logger（我继承的）的实例（单个）。

我既没有创建 MyLogger 的实例，也没有重新实现超类的 getInstance() 方法。但是我仍然收到警告，例如无法创建 MyLogger 的析构函数，因为父类 (Loggger) 析构函数不可访问。

我想知道，我做错了什么？继承单例是错误的还是应该避免？？

【问题讨论】：

标签： design-patterns logging singleton extending

【解决方案1】：

撇开单例模式的优点不谈（有一个学派将其描述为反模式），不必子类化它来简单地添加static em> 功能。以下是我希望将单例子类化的特定于语言的方法：

使用包含在 C++ 命名空间中的独立函数
在 C# 中使用扩展类
在 Java 中使用帮助类
在 Objective-C 中使用类别

【讨论】：

我正在使用 c++ 语言，我正在考虑创建一个仅包含不会从单例 Logger 类继承的静态方法的包装类。如何？？请您详细说明您在上面描述的 C++ 方法。谢谢..
@AnwarShaikh 这也行得通——这就是我在 Java 中要做的，因为那里没有独立的函数。我也会在 C++ 中走这条路，但前提是我需要在我添加的函数之间共享状态或其他实现细节。
谢谢！！我会尝试在它上面写一个包装器。

【解决方案2】：

我会使用非单例并在需要时将调用委托给单例。每当你有机会摆脱单例时，就去争取吧。

【讨论】：

是的，当然需要避免使用单例，但是当用于 Logger 之类的东西时，它是很好的。如果我需要一些额外的方法以及那些在单例中的方法，我应该继承它还是在内部使用单例的单例上编写包装器（只有静态方法的类）。
去包装。这就是我所说的“代表电话”的意思。

【解决方案3】：

我同意 Garret Hall 的观点，如果可能的话，你应该避免使用 Singleton。也就是说，我不认为这是错误的原因之一。实现 Singleton 的人允许您扩展它。如果 api 开发人员不希望扩展单例类 Logger，他们会将构造函数设为私有，例如在 C++ 中，或者任何适合您使用的语言的方法。

【讨论】：

【解决方案4】：

我认为在类上编写包装器不是正确的解决方案，因为您需要为单例所需的每个方法编写包装器。你最终会编写几十个函数。

您还限制自己使用单例中可用的所有功能。

不是个好主意！！！

【讨论】：