Образцы проектирования

Вернемся к МОК

Одним из следствий последнего проекта является упрощение общей архитектуры, предполагаемой парадигмой МОК ("модель — облик — контроллер"). Контроллер — это часть, являющаяся "склеивающим кодом", и мы должны стараться свести ее к минимуму.

Сердцем архитектуры контроллера является классEVENT_TYPE. В простейшей схеме этого достаточно, если позволять элементам модели непосредственно подписываться на события:

Рис. 8.2. Прямая подписка

(Двойная стрелка, как обычно, означает клиентское отношение, используемое здесь для реализации более абстрактных отношений общей МОК-картины) На этой схеме нет явных компонентов контроллера.

Пока модель не знает непосредственно об обликах (если не используется контекст), она связывается со специфическими типами событий. Такой подход имеет как ограничения, так и преимущества.

• Негативная сторона в том, что изменение обликов становится затруднительным. Если не ограничиваться одним обликом, то новые облики должны включать одни и те же события. Это предполагает, что различные облики не полностью различны, например, один из них может задавать интерфейс GUI, а другой — Web.
• С другой стороны, преимущество в большой простоте. Элементы модели могут непосредственно указать, какие действия следует выполнять для специфических событий, приходящих от интерфейса. Это позволяет не иметь склеивающего кода.

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

Рис. 8.3. Подписка через контроллер

Контроллер теперь становится независимой частью ПО. Его работа состоит в подписке элементов модели на типы события. Он будет иметь связи с:

• моделью, так как аргументы subscribe являются действиями, задаваемыми при подписке, и здесь должны быть агенты, встроенные в механизмы модели;
• обликами, если используются контексты. На рисунке это отображено возможной клиентской связью.

Это решение приводит к полному расщеплению модели и облика. В типичном приложении контроллер — как правило, небольшой компонент, достигающий цели и использующий склеивающий код в минимальной степени, насколько это возможно.

Модель как издатель

В рассматриваемых до сих пор схемах GUI все события приходят обычно через механизм библиотек и обрабатываются моделью. Другими словами, издателями являются облики, а элементы модели — подписчиками.

Схему можно расширить, позволив модели играть роль издателя. Например, если элемент GUI, такой как "сектор круговой диаграммы", отражает множество значений, которое может изменяться в модели, то модель становится причиной события "change". Облики становятся подписчиками этого типа события.

Эта возможность просто добавляется во второй схеме — подписке через контроллер. Контроллер будет действовать полностью как двусторонний брокер, получающий события от обликов для их обработки в модели и аналогично работающий в обратном направлении.

Это решение, добавляющее сложность контроллеру, полезно только при наличии нескольких обликов.

Утром инвестиции, вечером прибыль

Общим для двух архитектур — "Наблюдатель" и "Библиотека Event" — является необходимость предварительной подписки на тип события до начала их обработки.

У подписчиков есть возможность подписки и ее отмены в любое время. Для Event-решения можно создавать новые типы событий на любом этапе вычислений. Такая гибкость может быть полезной, но в типичном сценарии четко выделяются два этапа выполнения.

• На этапе инициализации подписчики регистрируют свои действия, типично приходящие из модели.
• Затем начинается этап, соответствующий бизнес-решению задачи. На этом этапе структура управления становится структурой, управляемой событиями. Выполнение отслеживает включение событий издателями, что (возможно, в зависимости от контекста) становится причиной запуска действий, предписанных моделью.

В соответствии с таким порядком правильнее было бы называть парадигму нашего образца "Подписаться-Публиковать". Это напоминает успешного инвестора: вначале он инвестирует в новое дело, а уж потом, когда оно начинает работать, может получить прибыль.

Возможно, вы вспомнили вариант этого общего подхода — стратегию компиляции, применяемую при топологической сортировке: сперва данные транслируются в подходящую структуру, затем начинается их обработка.

Оценка архитектуры ПО

Ключом качества программных систем является их архитектура, покрывающая такие аспекты, как:

• выбор классов, основанных на подходящей абстракции данных;
• решение о связях между классами. Целью является минимизация таких связей (при сохранении возможности независимой модификации и повторного использования различных частей ПО);
• для связанных классов — выбор правильного отношения, клиентского или наследования;
• задание компонентов классов;
• задание для классов и их компонентов правильных контрактов;
• при задании контрактов — выбор между "требовательным" стилем (сильные предусловия, заставляющие клиентов поставлять проверенные значения исходных данных), толерантным стилем (противоположный подход) или применением промежуточного подхода, возлагая часть проверок на клиента, часть — на соответствующий метод;
• удаление ненужных элементов;
• недопущение дублирования кода и удаление его, если оно уже присутствует. Для этих целей применяйте наследование: если есть общие части у двух и более классов, то сделайте эти классы наследниками общего родителя, который и будет хранителем общности, присущей нескольким классам. Для устранения дублирования используйте также универсальность, кортежи и агентов;
• использование преимуществ известных образцов проектирования;
• проектирование инструментария, пригодного для повторного использования: простого, легкого для понимания, поставляемого с подходящими контрактами;
• обеспечение согласованности: в программной системе подобные цели должны достигаться подобными методами. Это общее требование покрывает все вышеупомянутые требования, например, если для некоторых классов выбрано отношение наследования, то для схожей пары классов также должно выбираться наследование, а не клиентское отношение. Согласованность важна и при построении инструментария — API, если программист изучил некоторую группу классов, то он должен ожидать, что подобные соглашения будут действовать и для других классов. Эти же задачи возникают и при улучшении существующих проектов — деятельность, известная как рефакторинг. Хорошей идей является критический обзор существующей программной системы. Но помните, что лучше не делать ошибки, чем их исправлять. Проектируйте хорошо с самого начала.

Вне зависимости от того, идет ли речь о начальном проектировании или о рефакторинге, работа над архитектурой системы сложна и в то же время полезна. Обсуждение в этой лекции и некоторых других (лекция о топологической сортировке) дают некоторые идеи того, что нужно делать. Критерии успеха всегда одни и те же.

Почувствуй методологию