Время от времени я использую шаблон, но я не совсем уверен, как он называется. Я надеялся, что SO-сообщество сможет мне помочь.
Шаблон довольно прост и состоит из двух частей:
Метод фабрики, который создает объекты на основе переданных аргументов.
Объекты, созданные на фабрике.
Пока это просто стандартный «фабричный» шаблон.
Однако проблема, о которой я спрашиваю, заключается в том, что родительский объект в этом случае поддерживает набор ссылок на каждый дочерний объект, который он когда-либо создает, и хранится в словаре. Эти ссылки иногда могут быть сильными ссылками, а иногда и слабыми ссылками, но они всегда могут ссылаться на любой объект, который он когда-либо создавал.
При получении запроса на «новый» объект родительский узел сначала просматривает словарь, чтобы узнать, существует ли уже объект с требуемыми аргументами. Если это так, он возвращает этот объект, если нет, он возвращает новый объект, а также сохраняет ссылку на новый объект в словаре.
Этот шаблон предотвращает дублирование объектов, представляющих одну и ту же базовую "вещь". Это полезно, когда созданные объекты относительно дороги. Также может быть полезно, когда эти объекты выполняют обработку событий или обмен сообщениями - наличие одного объекта на каждый представляемый элемент может предотвратить несколько сообщений / событий для одного базового источника.
Возможно, есть другие причины использовать этот шаблон, но именно здесь я нашел это полезным.
Мой вопрос: как это назвать?
В некотором смысле, каждый объект является одиночным, по крайней мере, в отношении данных, которые он содержит. Каждый уникален. Но есть несколько экземпляров этого класса, так что это вовсе не настоящий синглтон.
В своей личной терминологии я склонен называть родительский класс «глобальным синглтоном». Затем я называю созданные объекты "местными синглетонами". Иногда я также говорю, что созданные объекты имеют «равенство ссылок», что означает, что если две переменные ссылаются на одни и те же данные (один и тот же базовый элемент), то ссылка, которую они содержат, должна быть на один и тот же точный объект, следовательно, «равенство ссылок».
Но это мои собственные придуманные термины, и я не уверен, что они хорошие.
Существует ли стандартная терминология для этого понятия? А если нет, то можно ли сделать несколько предложений по именованию?
Заранее спасибо ...
Обновление № 1:
В ответе Марка Симэнса ниже он высказывает мнение, что "Структура, которую вы описываете, по сути является контейнером DI, используемым в качестве статического локатора службы (который я считаю анти-паттерном)."
Хотя я согласен с тем, что есть некоторые сходства, и Статья Марка действительно превосходна, я думаю, что этот паттерн Dependency Injection Container / Static Service Locator на самом деле является более узкой реализацией общего шаблона, который я описываю .
В паттерне, описанном в статье, сервис (класс «Локатор») является статическим и поэтому требует внедрения для изменения его функциональности. В шаблоне, который я описываю, класс обслуживания вовсе не обязательно должен быть статическим. Можно предоставить статическую оболочку, если хотите, но статический класс вообще не требуется, и без статического класса внедрение зависимостей не требуется (и, в моем случае, не используется).
В моем случае «Сервис» - это либо интерфейс, либо абстрактный класс, но я не думаю, что классы «Сервис» и «Клиент» даже должны быть определены для шаблона, который я описываю.Это удобно, но если весь код является внутренним, класс Server может быть просто «родительским» классом, который контролирует создание всех дочерних элементов с помощью фабричного метода и сохраняет слабые (или, возможно, сильные) ссылки на все своидети.Никаких инъекций, ничего статического и даже не требуется наличие определенных интерфейсов или абстрактных классов.
Так что мой шаблон на самом деле не является «статическим локатором службы» и не является «контейнером внедрения зависимостей».
Я думаю, что шаблон, который я описываю, гораздо более широк, чем этот.Таким образом, остается вопрос: может ли кто-нибудь определить название для этого подхода?Если нет, тогда любые идеи о том, как это назвать, приветствуются!
Обновление № 2:
Хорошо, похоже, Габриэль Шербак получилэто с шаблоном дизайна GoF "Flyweight".Вот несколько статей об этом:
Подход «фабрика Flyweight» (сервер) и «объекты Flyweight» (клиент) с использованием интерфейсов или абстрактных классов хорошообъясненный в статье dofactory.com - это именно то, что я пытался объяснить здесь.
Пример Java, приведенный в статье Википедии , - это подход, который я использую, когдавнутренняя реализация этого подхода.
Шаблон Flyweight также, по-видимому, очень похож на концепцию , содержащую хэш и Multiton pattern .
Немногоболее отдаленно связанным был бы пул объектов , который отличается тем, что он имеет тенденцию предварительно создавать и / или удерживать созданные объекты даже вне их использования, чтобы избежать времени создания и настройки.
спасибо всем очень мюch, и особенно спасибо Габриэлю.
Однако, если у кого-то есть мысли о том, как называть эти дочерние объекты, я открыт для предложений."Внутренне сопоставленные дети"?«Перерабатываемые объекты»?Все предложения приветствуются!
Обновление № 3:
Это ответ TrueWill, который написал:
Причина в том, чтоанти-паттерн заключается в том, что вы не используете DI.Любой класс, который использует фабрику Singleton (он же сервисный локатор), тесно связан с реализацией фабрики.Как и в случае с новым ключевым словом, зависимости класса потребителя от сервисов, предоставляемых фабрикой, не являются явными (не могут быть определены из открытого интерфейса).Боль возникает, когда вы пытаетесь выполнить модульное тестирование классов потребителей изолированно и имитировать / фальсифицировать / заглушки реализации служб.Еще одна проблема, если вам нужно несколько кэшей (скажем, по одному на сеанс или поток)
Хорошо, поэтому Марк ниже сказал, что я использовал DI / IoC.Марк назвал это анти-паттерном.
TrueWill согласился с оценкой Марка о том, что я использовал DI / IoC в его комментарии в ответе Марка: "Большой +1. Я думал то же самое - ОП бросил свой собственный контейнер DI / IoC. "
Но в своем комментарии здесь TrueWill заявляет, что я не использую DI, и именно по этой причине, что это анти-паттерн.
Это может означать, что это анти-паттерн, использующий DI или нет ...
Я думаю, что происходит некоторая путаница, за которую я должен извиниться.Для начала мой вопрос начинается с разговора об использовании синглтона.Это само по себе является анти-паттерном.Это привело к путанице в вопросе относительно модели, которую я пытаюсь достичь, намекая на ложное требование.Родитель-одиночка не требуется, поэтому я прошу прощения за это.
См. Мой раздел «Обновление № 1» выше для пояснения. См. Также раздел «Обновление № 2», в котором обсуждается шаблон Flyweight, который представляет шаблон, который я пытался описать.
Теперь шаблон Flyweight может быть анти-шаблоном. Я не думаю, что это так, но это можно обсудить. Но, Марк и TrueWill, я обещаю вам, что ни в коем случае не использую DI / IoC, честно говоря, и при этом я не пытался подразумевать, что DI / IoC является требованием для этого шаблона.
Очень жаль за путаницу.