Паттерн: понятие, структура, классификация.
Понятие паттерна
Опытные разработчики объектно-ориентированных систем сформулировали общие принципы и стандартные решения, помогающие в разработке программного обеспечения. Если их систематизировать, структурировать, а также присвоить им имена, то их можно использовать в качестве шаблонов (паттернов).
Паттерн (шаблон, pattern) — это именованное описание проблемы и ее решения, которое можно применить при разработке других систем.
В идеале паттерн должен содержать еще и советы по поводу его применения в различных ситуациях, а также описание его преимуществ и недостатков.
Использование именованных паттернов позволяет:
· создать словарь основных терминов и определений, а также язык для их совместной увязки, что приведет к формированию фундамента дисциплины проектирования информационных систем;
· зафиксировать описываемое паттерном понятие в памяти;
· облегчить общение разработчиков при совместном решении проблем;
· передать опыт решения различных проблем анализа, проектирования и разработки.
Структура и Классификация паттернов
Низшим уровнем представления программной системы является описание ее в терминах классов (со своими атрибутами и операциями) и соответствующих им обьектов. Примером элемента следующего уровня является системная архитектура. Самым высоким уровнем является интеграция отдельных систем.
На основе этого разделения можно выделить следующие классы паттернов:
|
|
|
· паттерны проектирования распределения обязанностей и взаимодействия отдельных классов или обьектов информационных систем;
· архитектурные паттерны;
· аттерны интеграции информационных систем.
Существуют монографии, посвященные каждой отдельной группе паттернов, но нет их унифицированного рассмотрения на единых принципах.
Что касается вышеперечисленных групп паттернов, внутри каждой из них обычно проводится дополнительная классификация.
Проектирование на основе обязанностей. Принципы GRASP.
Зачастую проектирование программных объектов описывают в терминах обязанностей, ролей и кооперации (взаимодействия с другими объектами). Это — часть более широкого подхода, получившего название проектирование на основе обязанностей (Responsibility-Driven Design, RDD).
В RDD считается, что программные объекты имеют определенные обязанности — абстракции, реализуемые ими. Обязанности описывают 4 поведенеие объекта в терминах его ролей. В общем случае можно выделить две группы обязанностей: знание (knowing) и действие (doing).
К действиям объекта относятся следующие обязанности:
· выполнение некоторых действий самим объектом (например, создание экземпляра или выполнение вычислений);
|
|
|
· инициирование действий других объектов;
· управление действиями других объектов и их координирование.
К знаниям объекта относятся следующие обязанности:
· наличие информации о закрытых инкапсулированных данных;
· наличие информации о связанных объектах;
· наличие информации о следствиях или вычисляемых величинах.
Обязанности присваиваются объектам в процессе объектно-ориентированного проектирования. Например, можно сказать, что объект Sale отвечает за создание экземпляра SalesLineItems (действие) или что объект Sale отвечает за наличие информации о стоимости покупки (знание).
Обязанности-знания зачастую вытекают из модели предметной области, поскольку она иллюстрирует атрибуты и ассоциации. Например, если в модели предметной области класс Sale содержит атрибут time, то программный класс Sale тоже должен «знать» время соответствующей продажи.
Возможность реализации обязанностей в виде классов и методов зависит от точности их описаний. Реализация сложных обязанностей требует определения сотен классов и методов. Для простых обязанностей достаточно одного метода. Например, реализация обязанности «обеспечения доступа к реляционным БД» может потребовать создания десятков классов и сотен методов. А для реализации обязанности «создание экземпляра объекта Sale» достаточно одного метода одного класса.
|
|
|
В RDD существует идея кооперации (collaboration). Обязанности реализуются посредством методов, действующих либо отдельно, либо во взаимодействии с другими методами и объектами. Например, для класса Sale 5 можно определить один или несколько методов вычисления стоимости (скажем, метод getTotal). Для выполнения этой обязанности объект Sale должен взаимодействовать с другими объектами, в том числе передавать сообщения getSubtotal каждому объекту SalesLineItem.
RDD — это общий подход к проектированию программных объектов. Программные объекты рассматриваются как люди, имеющие свои обязанности и сотрудничающие с другими людьми для их выполнения.
Согласно основному принципу RDD, объектное программное решение представляет собой сообщество взаимодействующих объектов, имеющих свои обязанности.
Основные принципы распределения обязанностей выражены в шаблонах (или принципах) GRASP.
ПРИНЦИПЫ GRASP
Принципы объектно-ориентированного проектирования отражены в шаблонах GRASP, изучение и применение которых позволит освоить методологический подход к проектированию на основе распределения обязанностей.
|
|
|
Аббревиатура GRASP означает «General Responsibility Assignment Software Patterns (Общие принципы распределения обязанностей в программных системах)»
В состав GRASP входят 9 принципов: Creator (Создатель), Controller (Контроллер), Indirection (Перенаправление), Information Expert (Информационный эксперт), High Cohesion (Высокое зацепление), Low Coupling (Низкая связность), Polymorphism (Полиморфизм), Protected Variations (Защищенные изменения), Pure Fabrication (Чистая синтетика).
GRASP: принцип Low Coupling.
Проблема. Как обеспечить зависимость, незначительное влияния изменений и повысить возможность повторного использования?
Решение. Распределить обязанности таким образом, чтобы степень связанности оставалась низкой.
Степень связанности (coupling) — это мера, определяющая насколько жестко один элемент связан с другими элементами, либо каким количеством данных о других элементах он обладает. Элемент с низкой степенью связанности (или слабым связыванием) зависит от не очень большого числа других элементов.
Класс с высокой степенью связанности (или жестко связанный) зависит от множества других классов. Однако наличие таких классов нежелательно, поскольку оно приводит к возникновению следующих проблем:
· изменение в связанных классах приводят к локальным изменениям в данном классе;
· затрудняется понимание каждого класса в отдельности;
· усложняется повторное использование, поскольку для этого требуется дополнительный анализ классов, с которыми связан данный класс.
Принцип Low Coupling используется для оценки существующего проектного решения или выбора решения из нескольких вариантов — при прочих равных условиях предпочтение следует отдавать решению с более низкой степенью связывания.
Пример. Имеем три класса Payment, Register, Sale. Предположим, что необходимо создать экземпляр класса Payment и связать его с объектом Sale. Какой класс должен отвечать за выполнение этой операции? Поскольку в реальной предметной области регистрация объекта Payment выполняется объектом Register, объект Register хороший кандидат для создания объекта Payment (рис. 1).
Такое распределение обязанностей предполагает, что класс Register обладает знаниями о данных класса Payment (т.е. связывается с ним).
Рис. 1. Первый вариант (централизованный) кооперации классов с целью реализации обязанности «Создание платежа и связывание его с покупкой»
Альтернативный способ создания объекта — это создание платежа объектом Sale (рис. 2).
Рис. 2. Второй вариант (распределенный) кооперации классов с целью реализации обязанности «Создание платежа и связывание его с покупкой»
Какой из методов обеспечивает более низкую степень связывания? В обоих случаях предполагается, что объекту Sale должно быть известно о существовании Payment. При использовании первого способа, между 8 Payment и Register добавляется новая связь, тогда как второй способ степень связывания объектов не усиливает.
Обсуждение. В шаблоне Low Coupling описывается принцип, о котором нельзя забывать на протяжении всех стадий работы над проектом. Он является объектом постоянного внимания. Шаблон Low Coupling представляет собой средство, которое разработчик применяет при оценке всех принимаемых в процессе проектирования решений.
В объектно-ориентированных языках программирования, таких как C++, Java и С#, имеются следующие стандартные способы связывания объектов ТуреХ и TypeY.
· объект ТуреХ содержит атрибут (переменную-член), который ссылается на экземпляр объекта TypeY или сам объект TypeY;
· объект ТуреХ вызывает службы объекта TypeY;
· объект ТуреХ содержит метод, который каким-либо образом ссылается на экземпляр объекта TypeY или сам объект ТуреY (обычно это подразумевает использование TypeY в качестве типа параметра, локальной переменной или возвращаемого значения);
· объект ТуреХ является прямым или непрямым подклассом объекта TypeY;
· объект TypeY является интерфейсом, а ТуреХ реализует этот интерфейс.
Шаблон Low Coupling подразумевает такое распределение обязанностей, которое не влечет за собой чрезмерное повышение степени связывания, приводящее к отрицательным результатам.
Шаблон Low Coupling поддерживает независимость классов, что, в свою очередь, повышает возможности повторного использования и обеспечивает более высокую эффективность приложения. Его нельзя рассматривать изолированно от других шаблонов, таких как Expert и High Cohesion. Он обеспечивает один из основных принципов проектирования, применяемых при распределении обязанностей.
Подкласс жестко связан со своим суперклассом. Поэтому, принимая решение о наследовании свойств объектов, следует учитывать, что отношение наследования повышает степень связанности классов. Например, предположим, объекты необходимо постоянно хранить в реляционной или объектной базе данных. В этом случае зачастую создают абстрактный суперкласс PersistentObject, от которого наследуют свои свойства другие классы. Недостатком такого подхода является жесткое связывание объектов с конкретной службой, а преимуществом — автоматическое наследование
поведения.
Не существует абсолютной меры для определения слишком высокой степени связывания. Важно понимать степень связанности на текущий момент и не упустить тот момент, когда дальнейшее повышение связанности может привести к появлению проблем. В целом следует руководствоваться таким соображением: классы, которые являются достаточно общими по своей природе и с высокой степенью вероятности будут повторно использоваться в дальнейшем, должны иметь минимальную степень связанности с другими классами.
Крайним случаем при реализации шаблона Low Coupling является полное отсутствие связывания между классами. Такая ситуация тоже нежелательна, поскольку базовой идеей объектного подхода является система связанных объектов, которые «общаются» между собой посредством передачи сообщений. При слишком частом использовании принципа слабого связывания система будет состоять из нескольких изолированных сложных активных объектов, самостоятельно выполняющих все операции, и множества пассивных объектов, основная функция которых сводится к хранению данных. Поэтому при создании объектно-ориентированной системы должна присутствовать некоторая оптимальная степень связывания между объектами, позволяющая выполнять основные функции посредством
взаимодействия этих объектов.
Дата добавления: 2018-05-13; просмотров: 1305; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!