О шаблоне проектирования Gang of Four Singleton уже было сказано немало гадостей.
Вы можете прочитать о различных принципах, которые нарушает Синглтон, например: Здесь .
И, похоже, мне есть что добавить.
Первопричина всех бед с GoF Singleton в том, что для подавляющего большинства классов «синглтонность» — это деталь их реализации.
Просто эти классы удобнее реализовать, если вся система работает с одним-единственным объектом каждого.
GoF рекомендует внедрить эту деталь реализации для всех синглтонов в форме метода getInstance().
Что, если вам нужно реализовать класс по-другому? Начнутся проблемы.
Если новая реализация перестанет быть синглтоном, то придется менять не только сам класс, но и всех его клиентов, убирая все вызовы getInstance() и продумывая стратегию создания экземпляров для каждого случая заново.
Можно ли как-нибудь скрыть от клиентов это «синглтоновское» свойство класса вместе со всеми проблемами и нарушенными принципами? Существует. Это можно сделать с помощью архитектурного шаблона внедрения зависимостей/инверсии управления (IoC).
Контейнер IoC (IoCC) скрывает функцию Singleton класса от своих клиентов и берет на себя полную ответственность за управление зависимостями, освобождая Singleton от: «.
и обеспечивает глобальную точку доступа к нему.
» из определения банды из четырех человек.
Глобальная точка доступа больше не нужна; Клиенты-одиночки больше не знают точно, сколько экземпляров класса зависимостей создает для них IoCC. Например, мой любимый IoCC Гугл Гуйс позволяет пометить класс аннотацией Синглтон , но самое главное: он позволяет удалить эту аннотацию в любой момент без необходимости менять клиентов класса.
Под контролем IoCC «одиночность» всегда остается деталью реализации класса, помеченного как Синглтон .
Существуют также исключения, когда «синглтонность» действительно должна быть свойством интерфейса класса, а не деталью реализации.
Одно из таких исключений: Синглтон в наилегчайшем весе.
Например, мы пишем классы для абстрактного синтаксического дерева языка SQL, и одним из этих классов будет SqlNull. Желательно, чтобы в этом классе был один единственный объект, чтобы о нем знали все, и сравнивали этот объект с остальными только по ссылке.
В данном случае GoF Singleton нам подходит идеально.
Так.
Для классов обслуживания, т.е.
для большинства случаев, «Синглтон» — это деталь реализации и IoCC позволяет ее скрыть; для синглтонов-легковесов это часть интерфейса, и вы можете открыть ее снаружи, как предлагает GoF, используя getInstance().
Теги: #паттерны #шаблоны проектирования #дизайн и рефакторинг
-
Лазерный Принтер Samung — Тихая Революция
19 Oct, 24 -
Плохая И Хорошая Кириллица
19 Oct, 24 -
Заглушка Sendmail Для Linux
19 Oct, 24 -
Привет, Мир
19 Oct, 24 -
Особенности Тестирования Мобильной Mmo
19 Oct, 24 -
Радиоуправляемые Машинки: Введение
19 Oct, 24
