Альтернатива шаблону синглтона? - PullRequest
Новая
       18

Альтернатива шаблону синглтона?

4 голосов
/ 23 ноября 2011

Я пытаюсь разработать более гибкую форму синглтона.

Проблемы, которые я пытаюсь решить, следующие:

  • Синглтоны не могут быть проверены легко.
  • Они злоупотребляют объектно-ориентированным подходом, поскольку не разрешают наследование , код становится линейным, и многие разработчики склонны его чрезмерно использовать.
  • Они ограничены одним экземпляром , в смысле дублирования одного и того же механизма без дублирования самого класса (например, способ, которым ThreadPool работает как единое целое для каждого приложения, но каждое приложение имеет свой собственный экземпляр ).

Итак, решение, которое я нашел, заключается в следующем:

  • Сделать класс Singleton обычным общедоступным классом с внутренним конструктор (доступен только классам одного пакета).
  • Как и для каждого класса, ориентированного на продукт, все статические свойства и статические константы были перемещены во внутренний класс SingletonShared, который будет передан в качестве параметра конструктору Singleton. Те два спрятаны за публичной SingletonFactory, которая имеет статический метод getInstance(key).
  • В случае, если мы имеем дело с более сложной системой, где каждая Singleton требует свой собственный уникальный набор параметров, я добавил статический метод от setAdapter(adapter) до SingletonFactory. С помощью метод getShared(key), класс, который реализует ISingletonAdapter должен вернуть значение SingletonShared этого экземпляра (например, SingletonXmlAdapter передается XML-файл в конструктор, и десериализует определенный узел на основе ключа, который ему был дан).

Все вышеперечисленное упаковано в пакет Singleton.

Теперь для целей тестирования есть возможность пометить Singleton как внутренний класс и заставить его реализовать открытый интерфейс ISingleton.

Вопросы:

  1. Приемлемо ли это решение?
  2. Есть ли лучший / чище / короче способ достижения того же эффекта?
  3. Какая версия лучше (Singleton как внутренний или конструктор как внутренний)?

Спасибо!

1 Ответ

5 голосов
/ 23 ноября 2011

Я думаю, что решение, которое вы описываете как SingletonFactory, является шаблоном ServiceLocator , а ваши Singletons являются сервисами.

Является ли это решение приемлемым?

Это зависит от , как и , где вы используете Singletons.Синглтоны сами по себе неплохие, если вы изолируете код, который от них зависит.В противном случае вы в конечном итоге будете вводить несколько сложных синглетонов каждый раз, когда вам понадобится тестовое приспособление.

Если вы создаете экземпляры Singletons, а не используете статические методы получения / установки, будет сложнее вводить зависимости без использования DI-фреймворка, если только вы не передадите свои синглеты, но тогда вы можете получить длинный список параметров..

Есть ли лучший / чище / более короткий способ достижения того же эффекта?

Контейнеры IoC и Каркасы DI (различная тонкость) часто используются для управления зависимостями, которые иначе были бы синглетонами.Однако даже если вы устраните зло синглетонов, все же рекомендуется попытаться изолировать области зависимости от конкретных служб.

...