Мы должны изолировать Одиночные элементы? Мы должны попытаться наследоваться Одиночным элементам во-первых?
Singleton-классу нужно позволить иметь детей? Мы должны изолировать его? Каково за и против?
Чтобы способность наследовалась Singleton-классу, мы должны были бы сделать конструктора защищенным вместо частного. Теперь, это будет прекрасно в c#, но защищенное слово в Java дает и дочерние классы и доступ классов пакета конструктору. То, что означает не только классы, которые наследовались нашей Singleton, может получить доступ к конструктору, но другие классы в том же пакете могут сделать это.
Я немного смущен всем этим факты. Возможно, я делаю большую суету ни о чем для волнения о слишком много? До сих пор у меня никогда не было необходимости попытки наследоваться Singleton, поэтому возможно, это - просто академический вопрос!
Спасибо
5 ответов
Да, синглтоны должны быть опечатаны. Нет, они не должны передаваться по наследству.
Причина в том, что основным (на самом деле только ) поведением синглтона является создание своего экземпляра в заранее определенное время. Поскольку эта функция статична, ее нельзя переопределить, поэтому ее придется дублировать. Как только вы начнете дублировать, у вас будет несколько экземпляров синглтона, что на самом деле не имеет смысла.
Либо это, либо вы закончите с условиями гонки или другими конфликтами, поскольку «производные» синглтоны борются за контроль над глобальным экземпляром, что не только не имеет смысла, но и опасно.
Есть несколько хакерских обходных путей для проблемы наследования синглтонов, но это то, чем они являются - хаки. Паттерн Синглтон не совсем подходит для наследования.
Лучшее решение - использовать инфраструктуру контейнера IoC для обработки аспекта «синглтона» (времени жизни) класса. На этом этапе вы можете использовать POJO и просто наследовать от него.
РЕДАКТИРОВАТЬ: Некоторые ссылки, которые могут помочь:
- Список контейнеров для внедрения зависимостей .NET (IOC)
- Инверсия управляющих контейнеров с открытым исходным кодом (Java)
- Внедрение зависимостей в .NET (книга)
- Блог Марка Симанна по .NET - категория внедрения зависимостей
Ищите те, которые занимаются управлением временем жизни. Вы хотите иметь возможность настроить контейнер (который действует как универсальная фабрика), чтобы запросы экземпляров классов «Singleton» всегда возвращали один и тот же экземпляр (по крайней мере, для одного и того же контейнера). Обычно у вас есть только один экземпляр контейнера на самом высоком уровне вашего приложения.
Если вы можете расширить синглтон, это означает, что у вас может быть несколько его экземпляров. Это противоречит всей идее синглтона. Просто сделайте его «нормальным» классом и напишите соответствующий код вокруг него, чтобы вы создавали его только один раз и использовали один и тот же экземпляр навсегда. Если вам это нужно. Внедрение зависимостей может очень помочь в этом.
Если вы хотите использовать наследование в сочетании с одноэлементным шаблоном, вы должны поместить наследуемое состояние и поведение в абстрактный базовый класс и определить синглтоны как ( final) подклассы.
Хмм, звучит как вопрос, который многие из нас задавали в школе, когда изучали синглтоны. Предлагаю прочитать следующие ссылки.
http://msmvps.com/blogs/jon_skeet/archive/2006/01/20/singleton-inheritance.aspx http://msdn.microsoft.com/en-us/library/84eaw35x.aspx
Многие категорически не одобряют наследование от синглтона, но в реальном программировании часто требуется именно такой подход. Я лично сказал бы, что не следует наследовать от синглтона, как правило, но не ограничивайте себя дизайном, который блокирует такой подход. Прагматичный подход к разработке - всегда лучший подход ...