Паттерн: понятие, структура, классификация.

Понятие паттерна

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

Паттерн (шаблон, 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 (Чистая синтетика).