为什么单例类不能被细分

Why singleton classes cannot be sub-classed?

本文关键字：细分 不能 单例类 为什么      更新时间：2023-10-16

我正在经历singleton的负面影响。这里有一点我完全不能理解。这是链接和要点。

Singleton 的负侧

以下几点用于反对Singleton模式：

它们偏离了单一责任原则。singleton类有责任创建自己的实例承担其他业务责任。然而，这个问题可能通过将创建部分委派给工厂对象来解决。

Singleton类不能被细分。

http://www.codeproject.com/Articles/307233/Singleton-Pattern-Positive-and-Negative-Aspects

这篇文章似乎主要是关于singleton的普通Java实现的，其中构造函数是私有的；这意味着子类化是不可能的（子类需要调用构造函数，但不能）。允许对singleton进行更多的访问意味着不能再保证它只有一个实例。

这确实是一个内在的矛盾；如果你可以创建子类，那么你可以简单地创建更多的实例（只需为你想要的每个实例创建一个空的子类），这样你就不会真正有一个singleton了。

购买或借用GoF的副本

GoF的原始书籍在Singleton的实现部分中介绍了以下内容。注：Instance与Java getInstance()相同。

  1. 确保一个唯一的实例[…]
  2. Singleton类的子类主要的问题不是定义子类，而是安装其唯一的实例，以便客户端能够使用它。本质上，引用singleton实例的变量必须用子类的实例初始化。最简单的技术是确定要在singleton的Instance操作中使用哪个单例。示例代码中的一个示例显示了如何使用环境变量实现此技术

    选择Singleton子类的另一种方法是从父类中取出Instance的实现，并将其放入子类中。这允许C++程序员在链接时决定singleton的类（例如，通过链接包含不同实现的对象文件），但对singleton的客户端隐藏它

    链接方法修复了在链接时对singleton类的选择，这使得在运行时很难选择singleton类。使用条件语句来确定子类更灵活，但它会硬连接一组可能的Singleton类。这两种方法在所有情况下都不够灵活

    一种更灵活的方法使用singletons注册表。与其让Instance定义一组可能的Singleton类，Singleton类别可以在已知的注册表中按名称注册其Singleton实例

    注册表在字符串名称和singleton之间进行映射。当Instance需要一个singleton时，它会查询注册表，询问singleton的名称

GoF的书继续展示了注册表是如何工作的。

以下是使用环境变量的示例代码：

现在让我们考虑一下当存在子类时会发生什么。。。我们将通过环境变量〔…〕选择〔子类型〕

MazeFactory* MazeFactory::Instance () {
    if (_instance == 0) {
        const char* mazeStyle = getenv("MAZESTYLE");
        if (strcmp(mazeStyle, "bombed") == 0 {
            _instance = new BombedMazeFactory;
        } else if (strcmp(mazeStyle, "enchanted") == 0) }
            _instance = new EnchantedMazeFactory;
        // ... other possible subclasses
        } else {     // default
            _instance = new MazeFactory;
        }
    }
    return _instance;
}
相关文章：