Статья:
Использование паттерна “Команда”

Автор(ы): Андрей Глизнецов
Дата: 08.03.2005
В этой статье разбирается применение паттерна “Команда” в приложении WinForms. C помощью этого паттерна можно выделить обработку действий пользователя, ассоциируемых с пунктами меню, в отдельные объекты. Это позволяет отделить код пользовательского интерфейса от основной функциональности приложения, и, соответственно, сделать код приложения более структурированным и облегчить его поддержку.

Авторы:
Андрей Глизнецов

Аннотация:
В статье описаны преемущества применения паттерна "команда" в больших приложениях, в частности применение паттерна “команда” в приложении WinForms. C помощью этого паттерна можно выделить обработку действий пользователя, ассоциируемых с пунктами меню, в отдельные объекты. Это позволяет отделить код пользовательского интерфейса от основной функциональности приложения, и, соответственно, сделать код приложения более структурированным и облегчить его поддержку.

Всем ДВС!

АГ>Статья:
АГ>Использование паттерна “Команда”

Автор(ы): Андрей Глизнецов
Дата: 08.03.2005
В этой статье разбирается применение паттерна “Команда” в приложении WinForms. C помощью этого паттерна можно выделить обработку действий пользователя, ассоциируемых с пунктами меню, в отдельные объекты. Это позволяет отделить код пользовательского интерфейса от основной функциональности приложения, и, соответственно, сделать код приложения более структурированным и облегчить его поддержку.

А на альтернативный пример реализации этой идеи можно посмотреть в классе TAction и его предках VCL Delphi.

Правда TAction значительно заточен под особенности Delphi и её DFM-ки, но кореляция с тем, что в статье очень сильная.

Здравствуйте, Андрей Глизнецов, Вы писали:

Был сильно удивлен, что в стандатной библиотеке .NET отсутствует гибкий и удобный механизм обработки команд, подобный тому, что есть в VCL. (Вспомним, что .NET позиционировался чуть ли не как "убийца Delphi"). И это заставляет разработчиков писать такого рода статьи и изобретать новые велосипеды на каждый проект (ну или на команду, что немногим лучше).

Здравствуйте, wildwind, Вы писали:

А уж это: "К сожалению, стандартное .NET-меню не позволяет отображать картинки." — вообще стыд и срам.

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, wildwind, Вы писали:

W>А уж это: "К сожалению, стандартное .NET-меню не позволяет отображать картинки." — вообще стыд и срам.

Не надо издеваться. У Delphi уже 2005-ая версия, а у .NET только вторая

Здравствуйте, kavlad, Вы писали:

K>У Delphi уже 2005-ая версия, а у .NET только вторая
Не оправдание. Они бы еще начали только с консольных приложений в первой версии.

Здравствуйте, wildwind:

Да, уж. Что правда, то правда. С точки зрения построения форм VS NET и в подметки не годится по сравнению с Delphi.
А самое интересное, то что не сделано прячут за громким словом паттерн, типа вот ведь есть типовое решение. Так я вообще не понимаю, если есть типовое решение, так встройте его в оболочку...

Тем не менее автору огромное спасибо за реализацию этой возможности. Я давно искал что либо подобное, пробовал сам реализовать, получалось достаточно неуклюже, и наконец, сегодня только нашёл эту статью, Был очень рад.
Очень локоничный код, жаль я так не умею !

Хотелось бы задать вопрос Андрею Глизнецову:
При проектировании классов для паттерна "Команда" вы пользовались каким либо визуальным case — средством, или
писали код сразу ?
Каким образом научиться проектировать ООП приложения, на подобном уровне ?
P.S Книжку "паттерны проектирования" я уже прочёл

Выходит, класс команды зависит от пользовательского интерфейса, раз ему в конструкторе передается ссылка на главную форму.
Хм.. "ловкое" решение.
Значит если мой слой бизнес-логики не имеет зависимостей от слоя презентации (графического интерфейса), и соответсвенно не имеет ссылки на форму (а вдруг есть еще и Web-интерфейс?), то мои объекты не смогут выступать получателями команды, т.е. выполнять ее. А кто как не они знают что делать и определяют контекст для выполнения.
Результат -- почти тот же, что и до написания статьи: обработчик команды (получатель) и команда — часть интерфейса, которую надо переписывать каждый раз при его новой реализации. Выходит кроме инкапсуляции иконки, названия и ненужной глобальной фабрики-кэша полезного добавилось мало..

Здравствуйте, Аноним, Вы писали:

А>Выходит, класс команды зависит от пользовательского интерфейса, раз ему в конструкторе передается ссылка на главную форму.
А>Хм.. "ловкое" решение.
А>Значит если мой слой бизнес-логики не имеет зависимостей от слоя презентации (графического интерфейса), и соответсвенно не имеет ссылки на форму (а вдруг есть еще и Web-интерфейс?), то мои объекты не смогут выступать получателями команды, т.е. выполнять ее. А кто как не они знают что делать и определяют контекст для выполнения.
А>Результат -- почти тот же, что и до написания статьи: обработчик команды (получатель) и команда — часть интерфейса, которую надо переписывать каждый раз при его новой реализации. Выходит кроме инкапсуляции иконки, названия и ненужной глобальной фабрики-кэша полезного добавилось мало..

Команда инкапсулирует пару получатель-действие, при этом создает ее отправитель, значит команда так или иначе — часть пользовательского интерфейса, который инициализирует ее получаетелем из уровня бизнес логики.
Бизнес логика в результате просто получает сообщение в виде вызова метода и никак не зависит от пользовательского интерфейса.
Тут нет никакой проблемы.

На эту тему уже есть Composite UI Application Block от Microsoft там кроме как "меню" еще куча всего

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/cab.asp

Здравствуйте, NickSm, Вы писали:

Так я вообще не понимаю, если есть типовое решение, так встройте его в оболочку...

Моя смеялся и плакаль....
Вы хоть какие-то книги по компьютер сайенс читаете? Или только в дельфях на кнопочки тыкаете?