Здравствуйте, Сергей Гурин, Вы писали:
Диаграмка красивая
В данной статье мы не будем рассматривать общий случай, а ограничимся только достаточно важным частным случаем, когда отправители и получатели реализованы на одном и том же языке в рамках одной и той же платформы.
Стоило из-за этого такой велосипедище строить.
Здравствуйте, Аноним, Вы писали:
А>А>В данной статье мы не будем рассматривать общий случай, а ограничимся только достаточно важным частным случаем, когда отправители и получатели реализованы на одном и том же языке в рамках одной и той же платформы.
А>Стоило из-за этого такой велосипедище строить.
От автора: это может показаться неожиданным, но в конкретной реализации все получается довольно просто. Конечно, эту
задачу, как и любую другую, можно решить множеством способов. Я описал тот способ, который нашел и успешно
применил в одном из своих проектов.
Здравствуйте, rsdn_gurin!
Мне кажется есть более красивое решение
Надо изменить обявление получателя, в статье он был описан как:
SomeReceiver = class(BaseReceiver, IReceiver, )
public
...
изменить на
BaseReceiver = class(..., IContext)
...
SomeReceiver = class(BaseReceiver, IReceiver)
public
...
то есть вынести реализацию IContext в базовый класс, в котором они будут реализованы в виде
заглушек, то есть например
procedure BaseReceiver.ExecuteCommand1(cmd: Command1);
begin
end;
Тогда при изменении IContext меняется только базовый класс, не нужно менять
всех получателей, а конкретный получатель будет уже реализовывать(переопределяя пустую реализацию базового класса)
только те комманды которые его интересует.
А теперь по поводу того что я писал:
"Было бы удобно как в паттерне команда описанном в книге Эриха Гаммы написать
какого то конкретного получателя под конкрентную задачу".
Тут меня Вы маленько неправильно поняли, Вы написали в ответе:
Это одна из проблем — как указать получателя, если отправитель и
получатель находятся в различных адресных пространствах?
Эту проблему Вы прекрасно решили в статье, отправляя команду и задавая строкой получателя.
Объсню на примере что я хотел.
Допустим надо сделать получателя чтобы он обрабатывал только команду Command1, на остальные
не реагировал.
Тогда получатель будет выглядеть следующим образом:
SomeReceiver = class(BaseReceiver, IReceiver, IContext)
public
// интерфейс IContext
procedure ExecuteCommand1(cmd: Command1);
procedure ExecuteCommand2(cmd: Command2);
....
procedure ExecuteCommandN(cmd: CommandN);
end;
procedure SomeReceiver.ExecuteCommand1(cmd: Command1);
begin
// Что делаем ....
...
end;
procedure SomeReceiver.ExecuteCommand2(cmd: Command1);
begin
end;
...
procedure SomeReceiver.ExecuteCommandN(cmd: CommandN);
begin
end;
Получается что только один метод используется полноценно, остальные просто пустые, и при изменении IContext
он должен все время меняться, хотя функционал у него будет всегда один и тот же (ExecuteCommand1).
Когда я задавал Вам вопрос, я еще не додумался что достаточно реализацию IContext вынести в базовый класс (хотя решение типовое),чтобы получить то, что мне хочется.
если это сделать то получатель будет выглядеть следующим образом:
SomeReceiver = class(BaseReceiver, IReceiver)
public
procedure ExecuteCommand1(cmd: Command1); override;
end;
procedure SomeReceiver.ExecuteCommand1(cmd: Command1);
begin
// Что делаем ....
...
end;
Остальные команды его не интересуют он их не переопределяет. То есть получилось мы сделали
конкретного получателя под конкретную команду, не заграмождая его пустой реализацией других команд,
которые его не интересуют, и при добавлении новых команд он изменяться никак не будет. Вот это я и хотел.
Еще раз повторюсь идея интересная, самое главное что оформлено в виде четкой и понятной концепции.
Спасибо за внимание
Здравствуйте, Аноним, Вы писали:
А>Стоило из-за этого такой велосипедище строить.
Стоило. . Да и велосипедиЩА не вышло, а так, маленький, трехколесный

... Но как раз на 100% подошел к моей задаче
Да и как я понял, идея неплохо переносится на другой язык.
Вобщем спасибо автору за статью...лучше поздно, чем никогда