Синглтон - Защищенный против частного конструктора

При проектировании одиночных чисел, почему конструктор сделал protected, а не private? Это основано на том, что я видел в Интернете.

Мы хотим контролировать количество экземпляров, сделанных из этого класса, достаточно справедливо, но почему protected? Разве не мог бы сделать трюк private?

Ответ 1

Использование синглтонов плохое. Период.

Тем не менее, конструктор может быть закрытым, без проблем. Но что, если вы хотите вывести еще один синглтон из вашего синглтона (как если бы один синглтон был недостаточно плохим)? В этом случае производному классу нужен доступ к базовому одноэлементному конструктору.

Ответ 2

Во-первых, синглтоны в большинстве случаев огромные - плохая идея (Why?). Используйте их даже меньше глобальных переменных.

Это так, что подклассы могут инициализировать базовый класс Singleton, возвращая его как часть себя в своей собственной функции GetInstance() -type. Именно по этой причине это делается в Design Patterns. Поэтому он действительно релевантен, если вы планируете наследовать от Singleton.

GoF говорит: (стр. 130, Подкласс класса Singleton);

Более гибкий подход использует реестр синглетов . Вместо того, чтобы Instance определить набор возможных одноэлементных классов, singleton-классы могут регистрировать свой экземпляр singleton по имени в хорошо известном реестре.

При использовании реестров синглтонов конструктор protected в базовом синглтоне все еще требуется (согласно предоставленной реализации)

Короче говоря; Сделайте это protected, если вы планируете наследовать от Singleton. В противном случае перейдите к private.

Ответ 3

Все о наследовании. class lazy_singleton: public singleton {}; будет одним и тем же синглтоном с одноэлементным конструктором