Структурность vs Простота

← →
Piter © (2007-07-26 18:30) [80]

Bless © (26.07.07 18:26) [79]
Я никоим образом не хотел твою версию принизить или опровергнуть

дык я об этом и не говорил. Просто два разных подхода

Bless © (26.07.07 18:26) [79]
Просто показал, что наличие/отсутствие медиатора никак не усложняет повторное использование формы

не. В указанных до этого версиях медиатора как раз без него не обойтись, там все жестко.

А с регистрацией источника события и "клиентов" - это уже чуть другое.

← →
Kolan © (2007-07-26 18:36) [81]

> по-моему, любой класс должен быть как можно более самодостаточек
> (как раз с вашими минимальными числами связи).

И да и нет все зависит от конкретике. Если класс будет делать слишком много у него буде низкий уровень зацепления. ОО система это всегда система вз. меж собой классов.

> Ну и где тут модульность?

Каждый паттерн решает конкретную проблемму и создает другие. Например синглетон хз кто должен удалять.
Медиатор должен знать о коллегах. Тут ничего не сделать. так они устроены&#133

Можно пойти дальше и сделать обозревателя. Тогда и тебя получится оюъект пр. области «Состояние вкл/выкл» и кто хочет от него зависеть юудут подключаться.

> Этот диспетчер тогда получится ядром программы в сложных
> проектах.

Именно, я так и сделал:
http://delphimaster.net/view/1-1183471965/

Имхо хороший вариант&#133

← →
Bless © (2007-07-26 18:52) [82]

> не. В указанных до этого версиях медиатора как раз без него
> не обойтись, там все жестко.

да вроде нет. Без медиатора не обойтись приложению. А сами формы без него прекрасно обходятся и могут быть использованы повторно без изменений.

← →
Piter © (2007-07-26 19:13) [83]

Bless © (26.07.07 18:52) [82]
да вроде нет. Без медиатора не обойтись приложению. А сами формы без него прекрасно обходятся

ну что ты такое говоришь. Был ясно указан пример:

На закрытие формы: Mediator.Show(False);

Форма обращается к Mediator, нетрудно догадаться что это экземпляр класса TMediator, поэтому форма зависит от модуля, где объявлен этот класс. Никакой автономии формы для переноса.

Автономна она как раз будет в моем варианте, когда К НЕЙ обращаются с просьбой сделать вызов при наступлении того или иного события.

← →
Bless © (2007-07-26 19:24) [84]

> Piter © (26.07.07 19:13) [83]

Ты прав. Я ветку просмотрел бегло, обратил внимание на [26], а [18] пропустил. От предложенно в [18] медиатора толку, имхо, немного.

← →
Kolan © (2007-07-26 22:26) [85]

> Никакой автономии формы для переноса.

Видишь, то была просто галка и форма, то вот уже тебе надо решить задачу автономности. Ты определись что ты хочешь. Решения вытекаю из задач&#133

← →
_Mike_ (2007-07-27 01:05) [86]

Ужас. А ответ был дан аж

>>Псалтырь (26.07.07 02:10) [16]
>>TAction?

TAction OnUpdate + F1

← →
Sandman29 © (2007-07-27 09:59) [87]

Piter © (26.07.07 17:58) [74]

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

Значит, будет :)
К тому же можно анализировать, присвоен ли медиатор. Аналогично тому как события обрабатываются - если есть обработчик, то вызывается, иначе - нет.

← →
Sandman29 © (2007-07-27 10:11) [88]

Piter © (26.07.07 18:06) [75]

Медиатор не использует никаких главных форм! Он с интерфейсами работает (или с абстрактными классами).
В одном модуле описан интерфейс слушателя, в другом описан абстрактный медиатор. В идеальном случае слушатели ссылаются только на эти 2 модуля, используя фабрики для получения конкретных медиаторов.
В общем, почитай наконец теорию, на пальцах всё равно долго объяснять.

← →
Sandman29 © (2007-07-27 10:19) [89]

Игорь Шевченко © (26.07.07 18:10) [77]

А с чего Вы взяли, что "главная" форма, обсуждаемая в данной ветке, именно главная? Она вполне может оказаться пятнадцатой по счету модальной формой :)
Главная она лишь по отношению к "дочерней", которую показывает.

← →
Игорь Шевченко © (2007-07-27 10:20) [90]

Sandman29 © (27.07.07 10:19) [89]

> А с чего Вы взяли, что "главная" форма, обсуждаемая в данной
> ветке, именно главная?

Я этого не брал

← →
Sandman29 © (2007-07-27 10:22) [91]

Kolan © (26.07.07 18:36) [81]

Медиатор должен знать о коллегах. Тут ничего не сделать. так они устроены…

Вовсе нет. Я уже писал:

with TFormCloseMediator.Create(ChildForm) do
AddListener(MainForm).

Медиатор знает только то, что он должен подписаться на событие экземпляра TForm из конструктора и вызвать метод Listen всех подписавшихся слушателей.

← →
exactly2 (2007-07-27 10:29) [92]

p.s.
киньте линки на книги Фаулерв в электронном виде

← →
b z (2007-07-27 11:04) [93]

> exactly2

http://www.martinfowler.com/
это конечно не книги, но всетаки электронное :)

> киньте линки на книги Фаулерв в электронном виде

http://www.uml2.ru./index.php
Тут куча книг по ОО. И все бесплатно.

> Вовсе нет.

Нет, тот что в GoF должен.

> что он должен подписаться на событие экземпляра

Это уже более продвинутые решения. От медиатора в них остается только идея.
Для ядра системы я пользуюсь чем-то таким:
TSystemMediator = class strict private FColleagues: TColleaguesList; FCommandList: TCommandList; class var FInstance: TSystemMediator; constructor Create; strict protected procedure ProcessSavedCommands(CommandList: TCommandList; Colleague: TCustomColleague); procedure ProcessMediatorCommand(Command: TCustomCommand); public class function GetInstance: TSystemMediator; class procedure DestroyInstance; class function IsInstanceAssigned: Boolean; destructor Destroy; override; procedure SendMessage(Command: TCustomCommand); procedure Attach(Colleague: TCustomColleague; First: Boolean = False); procedure Detach(Colleague: TCustomColleague); end;

а я когда посмотрел ту ветку еще, стало интересно, что такое TCustomCommand?

Я думаю логичнее просто обозначать константы, начиная с нуля и далее.

В Miranda эти комманды являются строками, тоже свои преимущества, особенно для plugin системы.

> особенно для plugin системы.

Для плагин системы эта архитектура просто супер. По суту вся программа-набор плагинов. Причем плагины могут делать все что угодно&#133

> В Miranda эти комманды являются строками

Дык это команданая строка какаято :).

> стало интересно, что такое TCustomCommand?

TCustomCommand = class strict private FAutoDestroy: Boolean; FProcessed: Boolean; public function CommandName: string; virtual; constructor Create; function This: TCustomCommand; property AutoDestroy: Boolean read FAutoDestroy write FAutoDestroy; property Processed: Boolean read FProcessed write FProcessed; end;

Это просо объект.

Структурность vs Простота Найти похожие ветки