Всего лишь визуальное представление

Всего лишь визуальное представление

Каждый смертный все таки лицезреет

Только то, что желает созидать,

Отметая остальное.

Ля-ля-ля…

П. Саймон и А. Гарфункель, Боксер

Ранее нас учили не писать программки одним огромным кусочком, а использовать принцип "дели и владычествуй" и разбивать программку на модули. У каждого молу-ля есть свои собственные обязанности; модуль (либо Всего лишь визуальное представление класс) считается верно определенным, если у него имеется одна верно обозначенная обязанность.

Но как вы разбиваете программку на разные модули, основанные на обязательствах, вы сталкиваетесь с новейшей неувязкой. Каким образом объекты разговаривают вместе на стадии выполнения программки? Как вы управляете логическими зависимостями меж ними? Другими словами, как вы осуществляете синхронизацию конфигураций состояния Всего лишь визуальное представление (либо обновление значений данных) разных объектов? Этой работе должна быть присуща четкость и упругость – мы не желаем, чтоб они узнали друг о друге очень много. Мы желаем, чтоб каждый модуль был похож на героя песни Саймона и Гарфункеля и лицезрел только то, что желает узреть.

Начнем с концепции Всего лишь визуальное представление действия. Событие представляет собой особое сообщение, в каком говорится: "Только-только случилось нечто увлекательное" (очевидно, исходя из убеждений наблюдающего). Мы можем использовать действия, чтоб говорить одному объекту об конфигурациях, произошедших с другим объектом, в каких последний может быть заинтересован.

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

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

Протокол "Публикация и подписка"

Почему считается дурным тоном пропускать все действия через одну-единственную программку? Так как при всем этом нарушается инкапсулирование объекта – сейчас этой подпрограмме приходится получать заветную информацию Всего лишь визуальное представление о содействии меж многими объектами. Это также содействует повышению связывания, а мы пытаемся его уменьшить. Так как и самим объектам приходится получать информацию об этих событиях, то, по всей вероятности, вы собираетесь нарушить принцип DRY, принцип ортогональности и, может быть, некие разделы Женевской конвенции. Может быть, вам Всего лишь визуальное представление бывало созидать подобные программки – их доминантой является большой оператор case либо разнообразная конструкция if-then. Мы можем сделать это изящнее.

Объекты обязаны иметь возможность регистрации только для приема событий, которые им необходимы, и никогда не должны посылать действия, которые им не необходимы. Мы не желаем, чтоб наши объекты подверглись Всего лишь визуальное представление спаммингу! Заместо этого мы можем пользоваться протоколом типа "публикация и подписка", который представлен на рисунке 5.4 при помощи диаграммы последовательностей на языке UML [34].

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

Рис. 5.4. Протокол "Публикация и подписка"

Если нам увлекательны определенные действия, которые генерируются объектом Publisher (Издатель), то все, что нам необходимо, – это зарегистрироваться. Объект Publisher выслеживает все заинтригованные объекты Subscriber (Подписчик); когда объект Publisher генерирует событие, представляющее Всего лишь визуальное представление энтузиазм, он, в свою очередь обращается к каждому объекту Subscriber, извещая их о том, что данное событие вышло.

На данную тему существует несколько вариантов, отражающих другие стили обмена данными. Объекты могут использовать протокол "Публикация и подписка" на одноранговой базе (как показано выше), также "программную шину", где централизованный объект поддерживает базу данных «слушателей Всего лишь визуальное представление» и производит подобающую диспетчеризацию. Вы даже сможете получить схему, в какой критичные действия транслируются ко всем «слушателям» – как зарегистрированным, так и незарегистрированным. Одна из вероятных реализаций событий в распределенной среде иллюстрируется службой сообщений CORBA, описанной во врезке "Служба событий CORBA" (см. ниже).

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

Принцип "модель-визуальное представление-контроллер»

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

Служба событий CORBA

Служба событий CORBA позволяет объектам-участникам отправлять и получать извещения о событиях через общую шину, так именуемый канал событий. Канал событий воспринимает решение по обработке событий, также производит разделение Всего лишь визуальное представление производителей и потребителей событий. Он работает в 2-ух главных режимах: «проталкивание» и "вытягивание".

В режиме «проталкивания» поставщики событий информируют канал событий о том, что событие вышло. Потом канал автоматом распространяет это событие ко всем объектам-клиентам, которые зарегались, выражая собственный энтузиазм.

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

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

Разумеется, мы не Всего лишь визуальное представление желаем иметь три отдельных копии одних и тех же данных. Потому мы создаем модель – сами данные и обыденные операции для их обработки. Потом мы можем сделать отдельные зрительные представления, которые показывают данные разными методами: в виде электрической таблицы, графика либо поля суммы с скоплением. Каждое из этих зрительных Всего лишь визуальное представление представлений может располагать своими контроллерами. К примеру, график может располагать некоторым контроллером, позволяющим приближать и отдалять объекты, производить панорамирование относительно данных. Ни одно из этих средств не оказывает воздействия на данные, лишь на это представление.

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

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

Подсказка 42: Отделяйте зрительные представления от моделей

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


vsegda-vozmozhno-stat-uspeshnoj.html
vsego-105-chelovek-obrazovatelnie-programmi-i-tehnologii-analiz-kadrovogo-obespecheniya-pedagogicheskogo-processa.html
vsego-2100-itogi-samoobsledovaniya-po-kachestvu-podgotovki-specialistov-krasnoyarsk-2008g.html