Singleton может быть заменена Фабрикой?
Уже существуют некоторые сообщения о Шаблоне "одиночка" вокруг, но я хотел бы запустить другой по этой теме, так как я хотел бы знать, будет ли Шаблон "фабрика" правильным подходом для удаления этого "антишаблона".
В прошлом я использовал одиночный элемент довольно много, также сделал моих поддерживающих коллег, так как это настолько просто в использовании. Например, Eclipse IDE или лучше его модель инструментальных средств делают тяжелое использование одиночных элементов также. Это происходило из-за некоторых сообщений о E4 (следующая большая версия Eclipse), который заставил меня начать заново продумать одиночный элемент.
Нижняя строка была то, что из-за этого одиночные элементы dependecies в Eclipse 3.x сильно связываются.
Позволяет предполагают, что я хочу избавиться от всех одиночных элементов полностью и вместо этого использовать фабрики.
Мои мысли были следующие:
- скройте сложность
- меньше связи
- Я управляю, сколько экземпляров создается (просто хранят ссылку I частное поле фабрики),
- дразните фабрику за тестирование (с Внедрением зависимости), когда это будет позади интерфейса
- В некоторых случаях фабрики могут сделать больше чем один одиночный элемент устаревшим (в зависимости от бизнес-логики / состав компонента)
Это имеет смысл? В противном случае приведите серьезные причины для того, почему Вы думаете так. Альтернативное решение также ценится.
Спасибо
Marc
6 ответов
Я согласен, что иногда это имеет смысл. Однако это зависит от того, что вы создаете.
Если вы заменяете каждый синглтон на фабрику только потому, что он «лучше», вы делаете это неправильно, imho. Это должно служить определенной цели. Если вы не собираетесь издеваться, если уверены, что вам нужен только один экземпляр и т. Д., То замена - это просто «архитектурная маструбация»;)
Не поймите меня неправильно, архитектура очень важна, но не переусердствуйте. Это.
Синглтоны, описанные в шаблоне проектирования, обычно используют статические переменные, что затрудняет тестирование кода.
Я бы порекомендовал прочитать , это от Мишко Хевери и две последующие статьи 1 и 2 . Здесь он описывает, в чем разница между объектом с одним экземпляром и объектом Singleton, как в шаблоне проектирования, и что предпочтение следует отдавать первому.
Так что, на мой взгляд, ваш описанный подход будет правильным.
Синглтон, конечно же, антипаттерн. А если вы используете TDD - вам следует избегать таких решений. Любая инфраструктура IoC, такая как Windsor или Unity, может эмулировать эту функциональность без ужасных статических классов. Однако, если вы не используете TDD и ваш проект довольно прост, вы можете его использовать. Кстати, я бы рекомендовал IoC Framework, а не самодельные фабрики. Не изобретайте колесо.
В моем понимании вы не можете "заменить" Singleton на Factory, но вы можете использовать эти паттерны вместе. Factory возвращает экземпляр объекта вызывающему метод Factory. Если вы хотите убедиться, что существует только один экземпляр конкретного объекта, который возвращает фабрика, то этот объект должен быть синглтоном. Вы прячете синглтон в Factory.
Если вы храните частный экземпляр объекта в Фабрике, а не в самом объекте, то как вы можете обеспечить, чтобы в системе был только один экземпляр объекта? Как вы можете гарантировать, что этот объект будет создан только вашей фабрикой?
Вы можете заменить Singleton на IoC, и действительно, кажется, что существует много плохих чувств по отношению к Singleton как анти-паттерну, и даже Гамма сказал, что он хотел бы оставить его в книге GoF...
Factory - определенно альтернатива Синглтону, и я бы предпочел первый второму. Синглтоны очень сложно тестировать и приводят к сильной связи. Фабрики, если они реализованы правильно (с использованием чистых интерфейсов и т. Д.), Приводят к более тестируемому коду и меньшему количеству взаимосвязей.
Тем не менее, это не означает, что вы должны использовать Фабрики как кувалду для решения каждой проблемы. Существуют и другие шаблоны, которые также могут привести к меньшей связанности, чем Singleton, но являются более подходящим решением. Например: инверсия управления.
На мой взгляд, основным недостатком синглтонов является тесная связь (со всеми ее последствиями, такими как плохое тестирование и т. Д.).
Шаблон фабрики допускает гораздо более слабую степень связи, так что да: замена синглтонов фабриками кажется хорошей идеей.
Как упоминает Питер Келли , фабрики иногда также могут оказаться одиночными. Однако фабрики, по крайней мере, возвращают не свой экземпляр, а скорее экземпляр некоторой реализации интерфейса, и это огромный плюс.