Читаем Программист-прагматик. Путь от подмастерья к мастеру полностью

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

• Модель. Абстрактная модель данных, представляющая целевой объект. Модель не располагает непосредственной информацией о любых визуальных представлениях или контроллерах.

• Визуальное представление. Способ интерпретации модели. Оно подписывается на изменения в модели и логические события, приходящие от контроллера.

• Контроллер. Способ контроля визуального представления и снабжения модели новыми данными. Он осуществляет публикацию событий для модели и визуального представления.

Рассмотрим пример с текстовым интерфейсом.

Игра в бейсбол представляет собой уникальное явление. Где еще можно найти такие пустяки, как "самый результативный матч, сыгранный во вторник под дождем при искусственном освещении между командами, названия которых начинаются с гласной буквы"? Предположим, что нам поручили разработать программу для помощи бесстрашным дикторам, которым по должности полагается сообщать счет, статистику и прочие мелочи.

Ясно, что нам необходима информация о матче, который проходит в настоящее время – играющие команды, условия, игрок, принимающий подачу, счет и т. д. Эти факты образуют наши модели; они будут обновляться по мере поступления новой информации (смена подающего, выбывание игрока, начался дождь…).

Затем у нас появится ряд объектов – визуальных представлений, которые будут использовать эти модели. Один объект должен наблюдать за набираемыми очками – для обновления текущего счета. Другой объект может получать уведомления о новых игроках, отбивающих мяч, и извлекать краткую справку об их статистических показателях за год. Третий объект может просматривать данные и проверять, не установлен ли мировой рекорд. Можно даже использовать средство просмотра «мелочей», которое несет ответственность за придумывание сверхъестественных и бесполезных фактов, щекочущих нервы зрителей.

Рис. 5.5. Комментирование бейсбольного матча. Средства просмотра являются подписчиками модели.

Но мы не хотим, чтобы несчастный диктор работал со всеми этими окнами непосредственно. Вместо этого мы сделаем так, чтобы каждое из окон генерировало извещения об «интересных» событиях, и обеспечим возможность планирования показа с помощью некоторого высокоуровневого объекта [36].

Эти объекты (средства просмотра) внезапно стали моделями высокоуровневого объекта, который сам по себе может стать моделью для различных форматирующих средств просмотра. Одно такое средство просмотра могло бы создать сценарий для телесуфлера, с которым работает диктор, второе могло бы генерировать заставки непосредственно на спутниковом канале, а третье могло бы осуществлять обновление web-страниц телевизионной сети или бейсбольной команды (см. рис. 5.5).

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

В усовершенствованных системах, наподобие описанной выше, полезно иметь окна отладки – специализированные окна, которые отображают подробности модели. Дополнение системы средством трассировки отдельных событий также способствует существенной экономии времени.

<p>Все такой же связанный (после стольких лет)</p>

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

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

Другие разделы, относящиеся к данной теме:

• Ортогональность

• Обратимость

• Несвязанность и закон Деметера

• Доски объявлений

• Все эти сочинения

Упражнения

29. Предположим, что имеется система бронирования авиабилетов, основанная на следующем принципе формирования авиарейса:

public interface Flight {

//Return false if flight full.

public Boolean addPassenger(Passenger p);

public void addToWaitlJst(Passenger p);

public int getFlightCapacity;

public int getNumPassengers;

}

Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT