Здравствуйте,
 Еще вопрос по проектированию…

Допустим у нас есть два объекта А и Б. И есть интерфейс И.

Пусть Б реализует И (
)

А классу А нужен посетитель реализующий интерфейс И. Раз он ему нужен, то хорошо бы запросить его при создании:




Вопрос кто должен передать классу а посетителя.

Вариант первый — тут все прозрачно:

Допустим сам Б инстанцирует А. Тогда

 MyА := А.Create(Self)

Вариант второй, сам вопрос:

А что если А и Б синглетоны? Кто и как тогда должен связать А и Б?

1. Не обязательно передавать И через конструктор, можно через свойство.

2. Тот, кто обеспечивает "синглтонность". То есть, фабрика класса A или метод A.NewInstance.

> 1. Не обязательно передавать И через конструктор, можно
> через свойство.

Ну смысл от этого не меняется.
Просто будет в 1 варианте:



Проблемма не исчезает.

То есть, фабрика класса A или метод A.NewInstance.
А если нет фабрики? Синглетон создается по требованию.

или метод A.NewInstance.
Хм. Но ведь тогда А будет знать о конкретном Б. Это убьет весь смысл использования посетителя.

> Kolan ©   (27.01.08 11:51) [2]

> Но ведь тогда А будет знать о конкретном Б. Это убьет весь смысл
> использования посетителя.

Убъет, но не это. Вы же сами сказали, что Б - синглтон. Вот что убивает смысл конкретного посетителя - его единственность.

> Вот что убивает смысл конкретного посетителя — его единственность.

Да наверно пример не корректный, синглетон это только А Б — не обязательно. Как тогда?

А тогда не вижу проблемы. Тот, кто запрашивает А, должен знать посетителя И и в запросе передать ссылку на него. Если это первый запрос А, то произойдет реальное создание А и инициализация его поля (ссылки на И), а если не первый - произойдет переключение А на другого посетителя.

> А тогда не вижу проблемы. Тот, кто запрашивает А, должен
> знать посетителя

Ан нет…

Ток кто запрашивает А не знает (в некоторых случиях) о том, что а нужен посетитель.

Вызывающий А говорит ему:



И все, а то что для выполнения работы А нужно еще что-то он может незнать.

Единственный вариант, который у меня есть — это использование класса, который как-бы инициализирует систему. Он то и назначит нужные посетители… Только не очень мне нравится это вариант.

> Kolan ©   (27.01.08 12:37) [6]

> А.ДелайСвоюРаботу.

И тогда A либо использует своего текущего посетителя, либо запрашивает еще кого-то (менеджера, очередь посетителей и т.п.) - "дай мне посетителя".

Вообще, для более предметного разговора надо бы лучше знать задачу. Судя по слову "посетитель" и по тому, что А - синглтон, моделируется что-то вроде процесса обслуживания посететелей одним продавцом. Тогда уместно ввести именно очередь посетителей - она и будет тем менеджером, который назначает продавцу текущего посетителя.

> И тогда A либо использует своего текущего посетителя

Так откуда он его возмет этого текущего?


> Судя по слову «посетитель»

Под словом посетитель подразумевается Visitor из GoF.

> Kolan ©   (27.01.08 13:07) [8]

Значит, нужен менеджер посетителей.

> Значит, нужен менеджер посетителей.

Это решение и используется…  может еще че-нить можно придумать…?

> Kolan ©   (27.01.08 13:26) [10]

Наверное, можно. Но зачем? Просто так, из любви к искусству, или существующее решение чем-то устраивает? Если второе, то чем?

> может еще че-нить можно придумать…?


Может. Рассказать задачу и не мудрствовать сверх необходимости.

Многие переболели паттернами, универсализацией, повторным использованием кода и так далее.
У кого-то выработался стойкий иммунитет:)

> У кого-то выработался стойкий иммунитет:)

Вырабатываю его у себя :).


> Может. Рассказать задачу и не мудрствовать сверх необходимости.

Задачи нет. Есть проблемма.

Так и есть синглетон А, которому для работы нуже кто-то поддерживающий интерфейс.
Сейчас я ему этого кого-то даю при старте приложения. То есть у меня есть StartUpConterller, ктороый знает о А, о Б и о интерфейсе.

А проблемма в том, что мне ненравится такой метод связывания.

> Задачи нет. Есть проблемма.


Любую проблему можно решить. Причем несколькими способами.

Но возникает другая проблема -  какой из способов выбрать?

> Причем несколькими способами.

Ну какими? Я вижу только вариант с внешнем классом… ненравится он тем, что этот класс нужен только для связи и не для чего больше…

> Kolan ©   (27.01.08 15:48) [13]

> А проблемма в том, что мне ненравится такой метод связывания.

Не нравится на уровне эстетики вообще, или не нравится чем-то конкретным?

Если первое, то никакой проблемы на самом деле нет, она высосана из пальца. А если второе, то начинать надо с точной формулировки того, "чем конкретно мне это решение не нравится". Это будет уже половина решения.

> Kolan ©   (27.01.08 16:15) [15]


Я честно говоря не могу понять, что у тебя за задача и почему посетителю нужно реализовывать интерфейс.
Ты ничего не напутал?

Опиши словестно задачу. И чего ты хочешь добиться в итоге.
А то я честно не могу понять задачи.

> с точной формулировки

Постараюсь уточнить…

При использовании посетителя получается что у нас еть два слоя, разделенных интерфейсом:




Дупустим что таких слоев не да, а хотябы три:




В этом случае если использовать менеджер, то он будет знать о всех. То есть он все эти слои нарушает…

> Kolan ©   (27.01.08 16:25) [18]


О каких слоях идет речь?