Рабочая программа по дисциплине Цели и задачи освоения дисциплины Дисциплина Объектноориентированный анализ и программирование
 Скачать 339.98 Kb.
|
private void flip(int x, int y) { if (x > && x < 4 && у > -1 && у < 4) data.x. .у. = (byte) (1 - data.x. ]y] ) ; public void printstate() { for(int i = 0; i < 4; i++) { for(int j = 0; j < 4; j++) System.out.print(data.i. . j. ); System.out.printin(); В данном примере класс Grid представляет собой абстракцию квадратной доски размером четыре на четыре ячейки, в каждой из которых может находиться либо 0, либо 1. Состояние любой ячейки может быть изменено, однако такое действие повлечет изменение состояний соседних клеток. Классы FlipUp и FlipDown обеспечивают взаимодействие с элементами доски. Операции, реализованные в них, и отвечают за изменения состояний. В контексте примера именно они и являются объектами-командами. Класс Invoker аккумулирует в себе операции и предоставляет клиенту единую точку доступа ко всем возможным сценариям. Концепция МУС как результат применения объектно-ориентированного анализа и проектирования Одним из наиболее наглядных и понятных практических примеров мощности объектно-ориентированной парадигмы является концепция MVC. В связи с быстрым ростом темпов развития компьютерной инженерии и резким увеличением сложности решаемых задач в конце 1970-ых потребовался гибкий способ для разграничения программной логики и визуализации. Именно эту цель и преследовала предложенная в 1979 году MVC. MVC предполагает разделение данных, представления данных и обработку действий пользователя на три компонента: модель, представление и контроллер. Модель предоставляет данные предметной области и методы работы с ними. При этом она не содержит никакой информации о том, как эти данные визуализируются. Представление отвечает за визуализацию информации. Типичным примером представления является графический интерфейс пользователя. Контроллер же обеспечивает связь между пользователем и системой: осуществляет проверку введенных данных и использует модель и представление для реализации необходимой реакции. На рисунке представлено схематическое изображение концепции MVC. Сплошными линиями показаны прямые связи (вызов функций, передача данных), пунктирными — косвенные (через сообщения).  Представление и контроллер зависят от модели, однако модель от них никоим образом не зависит. Тем самым достигается возможность работать с моделью независимо от се визуального представления.Принято выделять две модели MVC: • Пассивная модель. Модель нс влияет на представление и контроллер, а используется ими только в качестве источника данных для отображения. Все изменения модели отслеживаются контроллером. Контроллер отвечает за перерисовку, если это необходимо. • Активная модель. Модель оповещает и представления о том, что в ней произошли изменения. Заинтересованные в конкретных изменениях предст авления подписываются на оповещение. Использование концепции МУС позволяет добиться следующих преимуществ. Возможность присоединения к одной модели нескольких видов без модификации самой модели (одни и те же данные могут быть представлены и таблицей, и диаграммой). Возможность присоединения к одному виду разных контроллеров, что позволяет получить разную реакцию на действия пользователя. Более высокий уровень разделения труда программистов. Разработчики, занимающиеся логикой, нс связаны с разработкой представления. Повышение степени повторного использования кода. В то же время концепция относительно сложна для понимания, что зачастую вызывает ее неправильное использование. Кроме того, в некоторых случая MVC приводит к чрезмерному усложнению разрабатываемой архитектуры. Примечательно то, что МУС практически полностью «составлена» из шаблонов проектирования. Основными с архитектурной точки зрения являются «наблюдатель», «стратегия», «команда», «компоновщик» и «фабричный метод». Разберем подробнее ранее не рассмотренные шаблоны. «Наблюдатель» — это шаблон поведения объектов, определяющий связь «один ко многим» таким образом, что при изменении состояния одного объекта все объекты, зависящие от него, оповещаются об этом изменении и автоматически обновляются. Данный шаблон позволяет обеспечить согласование состояний объектов без жесткой связи классов, что повышает повторную используемость кода. Структура шаблона приведена на рисунке. Участниками являются субъект (Subject), наблюдатель (Observer), конкретный субъект (ConcreteSubject), конкретный наблюдатель (ConcretcObscrver). Субъект является интерфейсом, предоставляющим методы для присоединения и отделения наблюдателей. Помимо этого он также аккумулирует информацию обо всех наблюдателях. Конкретный субъект — это класс, реализующий интерфейс Subject. Экземпляр Subject содержит некоторое состояние, представляющее интерес для конкретного наблюдателя, и декларирует методы для оповещения наблюдателей <х> изменении этого состояния. Наблюдатель — интерфейс для обновления состояния объектов-наблюдателей. Конкретный наблюдатель хранит ссылку на субъект и значение состояния субъекта, за которым осуществляется наблюдение. Помимо этого конкретный наблюдатель реализует интерфейс Observer.  foreach(o: observers) oupdateQ
        Concreteobserver - state: Subjectstate ♦ updateQ', ConcreteSubject subject - state: Subjectstate getStateO: Subjectstate setStateQ ■ ' b. state = subject getStateO return state Диаграмма шаблона «наблюдатель» Абстрактная связанность субъекта и наблюдателя. Субъекту известно только то, что у него есть ряд наблюдателей. Он не знает ни их типов, ни положения в иерархии классов. Таким образом, связь между субъектом и наблюдателями сведена к минимуму и носит абстрактный характер. Повышение повторной используемости кода. За счет высокой степени абстракции шаблон обладает высокой степенью повторной используемости. Обеспечение широковещательной коммуникации. Уведомление об изменения автоматически поступают всем наблюдателям, подписавшимся на него. При этом для субъекта нс имеет значения, проигнорирует ли конкретный наблюдатель это сообщение или обработает. «Стратегия» — поведенческий шаблон проектирования, определяющий семейство алгоритмов. В некоторых ситуациях программа должна обеспечивать различные варианты поведения разных экземпляров одного класса. Иногда поведение требуется менять на стадии выполнения. Решение данной задачи возможно с помощью отделения процедуры выбора алгоритма от его реализации. Как следует из представленной на диаграмме структуры, этот шаблон имеет много общего с «мостом».         Context + strategy Strategy + executeO strategy «Strategy» strategy algonthmO
algorithm© Диаграмма шаблона «стратегия» Здесь Strategy — интерфейс реализации алгоритма. ConcretcStrategy реализует интерфейс Strategy. Класс Context конфигурируется объектом класса ConcretcStrategy и хранит ссылку на объект класса Strategy. В некоторых случаях Context может определять интерфейс, позволяющий получить объектам класса Strategy доступ к своим данным. Шаблон также обладает некоторыми важными свойствами. Во-первых, «стратегия» позволяет с легкостью использовать семейство алгоритмов, предотвращая порождение большого числа подклассов. Естественно, что от класса Context можно породить группу подклассов с разным поведением, однако такое решение приведет к затруднению понимания иерархии. Во-вторых, данный шаблон позволяет избавиться от условных операторов, определяющих стратегию поведения. Наконец, в-третьих, «стратегия» позволяет определять несколько реализаций одного и того же алгоритма. Клиент может динамически выбирать конкретную реализацию в зависимост и от ситуации или объема свободных ресурсов. Однако, «стратегия», как правило, значительно увеличивает число объектов в адресном пространстве. Кроме того, отчасти этот шаблон противоречит принципу инкапсуляции, так как клиент должен обладать информацией о различиях в стратегиях. Кроме того, стратегии могут различаться «по сложности». Простой стратегии могут не требоваться данные от клиента, а сложной понадобится много дополнительной информации. В этом случае простой стратегии будет предана избыточная информация, что приведет к повышению накладных расходов. Последний, еще не рассмотренный, шаблон — «компоновщик», — объединяющий объекты в древовидную структуру для представления иерархии от частного к целому. Основным назначением шаблона является предоставление одинакового доступа как к объектам, так и к группам объектов. Структура «компоновщика» изображена на диаграмме классов.         Component предоставляет интерфейс для компонуемых объектов и определяет общую для всех классов операцию по умолчанию. Leaf является листовым узлом композиции и нс имеет потомков (определяет поведение примитивных объектов композиции). Composite является составным объектом (хранит объекты-потомки и реализует относящиеся к управлению операции). Также Composite перенаправляет запросы на обработку своим потомкам. «Компоновщик» позволяет определить иерархию классов из примитивных и составных объектов, что значительно упрощает профаммную архитектуру. С помощью данного шаблона приложение может однообразно работать как с простыми, так и с составными объектами. Помимо этого значительно упрощается процедура добавления новых видов компонентов, так как отпадает необходимость в переписывании кода приложения. Наиболее существенным недостатком является невозможность ограничить типы используемых примитивных объектов. В некоторых ситуациях необходимо, чтобы в состав контейнера входили только определенные типы примитивов. Предлагаемое решение нс позволяет пользоваться для реализации таких офаничений статической системой типов. «Component 0 operation© Z5-
|