LINUX.ORG.RU

Подскажите правильный термин

 , , , ,


0

0

У нас существует шаблон проектирования Singleton, который создает объект, только при необходимости. Чаще всего этот шаблон используется таким образом, что на всю систему у нас создается только один единственный инстанс класса, и вместо создания нового, возвращается уже существующий.

Допустим, у меня есть класс, который должен создавать по одному инстансу на каждый инвариант объекта (допустим, на каждый одинаковый набор параметров конструктора, не суть). То есть, инстансов класса может быть много, но они уникальны только в том случае, если уникальны по содержанию. Например класс Email должен возвращать на каждый «some@mail.org» один и тот же объект, а на «ololo@baku.net» уже другой. По многочисленным определениями во всяких википедиях такое поведение класса уже не попадает под паттерн синглтона - ибо везде и всюду пишут - один экземпляр класса на всю программу (процесс), и нигде не упоминают инварианты.

Но с учетом того, что ничто не ново, точно должен быть правильный термин, который я просто еще не знаю. Не важно из какой области - будь то проектирование, или системы типизации может быть (есть например линейные и аффинные типы, которые регулируют количество значений определенного типа и их использование, но они все же немного о другом, о владении). Ну и алсо, здесь суть вопроса не в парадигме моделирования - будь это ООП, ФП или структуры. Не в иерархии наследовании, шаблонах, immutable world и прочем, а в самой сути - сущности типа\класса\вида создаются только если ранее не созданы. Какой термин для этого подхода есть?

Самое приближенное по тому, что на виду - это примитивные типы в различных языках. Они как раз выполняют данный контракт в той или иной мере с точки зрения поведения. Но ввиду того, что понятие примитивного типа чаще используется для указание на низкоуровневую реализацию, или разность между value\reference, не думаю, что для пользовательских множеств значений этот термин будет верен или удобен для коммуникации.

Какой термин для этого подхода есть?

Ты прекрати упарываться паттернами, а то уже «pass by value / pass by reference» в паттерны записал. Определись с мутабельностью, передай и пиши уже че-нибудь, сессия на носу.

t184256 ★★★★★ ()
  • фабрика может решать как создавать в простейшем случае
  • одиночка не обязательно только строго одна инстанция
  • в первоисточнике допускаются разные стратегии инстанцирования
anonymous ()

Завязывай уже страдать шаблонизацией головного мозга.

В твоём случае у тебя тупо надо сделать фабрику EmailFactory c одним методом:

Email get(EmailConfig config)

внутри организовать потокобезопасные выборку, создание и кэширование объектов в ассоциативном массиве EmailConfig -> Email, и всё, а шаблоном одиночкой у тебя теперь должна быть фабрика и всё!

anonymous ()