Синглтон - защищенный против частного конструктора - PullRequest
11 голосов
/ 31 августа 2011

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

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

Ответы [ 3 ]

8 голосов
/ 31 августа 2011

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

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

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

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

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

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

4 голосов
/ 31 августа 2011

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

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

0 голосов
/ 31 августа 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...