Введение в аналитические шаблоны и стили проектирования

Введение

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

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

Важным начальным этапом при работе с паттернами является адекватное моделирование рассматриваемой предметной области. Это необходимо как для получения должным образом формализованной постановки задачи, так и для выбора подходящих паттернов проектирования.

Использование паттернов проектирования на практике дает проектировщику следующие неоспоримые преимущества:

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

Основные концепции объектно-ориентированного программирования и их практическая значимость

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

Для более детального понимания сути объектно-ориентированного проектирования, базиса, на котором построены шаблоны, сравним следующие подходы:

• Полиморфизм:
• традиционный, рассматривающий объекты как совокупность данных и методов;
• новый, понимающий под объектом предмет, имеющий некоторые обязательства.
• Инкапсуляция:
• традиционный, рассматривающий инкапсуляцию исключительно как механизм сокрытия данных;
• новый, понимающий под инкапсуляцией способность к сокрытию чего угодно.
• Наследование:
• традиционный способ применения механизма наследования с целью реализации специализации и повторного использования кода;
• новый, понимающий под наследованием метод классификации объектов.

Затронем при рассмотрении различные уровни проектирования и то, как они соотносятся с данными и связями:

• Концептуальный уровень.
• Уровень спецификаций.
• Уровень реализации.

Именно "новый подход" позволил создателям шаблонов проектирования разработать

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

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

Это определение помогает сконцентрироваться на том, что объект должен делать, не задаваясь преждевременно вопросом реализации необходимой функциональности. Это помогает декомпозировать реализацию информационной системы на два этапа:

1. Создание предварительного проекта.
2. Реализация разработанного проекта.

Такой подход позволяет более точно выбрать и определить основной объект проектирования.

Второе определение объекта является более гибким, поскольку позволяет сосредоточиться на том, что объект делает, а механизм наследования предоставляет инструмент реализации его поведения по мере необходимости. При взгляде на объект с точки зрения реализации также можно достичь этого, но гибкость в таком случае, как правило, обеспечивается более сложным путем.

Рассуждение в терминах обязательств помогает сосредоточиться на определении открытого интерфейса объекта. Обязательства объекта накладывают дополнительное требование на определение способа их вызова.

Предположим, что существует объект, имеющий ряд следующих обязательств:

• знать свое положение;
• отобразить себя на экране;
• удалить изображение.

Эти обязательства предполагают существование определенного набора методов, необходимых для их реализации. Для нас не имеет никакого значения, что именно находится внутри рассматриваемого объекта. Единственное, что необходимо, – это чтобы рассматриваемый объект обеспечивал требуемое "поведение". Для этой цели могут использоваться атрибуты внутри объекта или методы, вычисляющие требуемые результаты или даже обращающиеся к другим объектам за необходимыми для их функционирования данными. Этот подход предоставляет необходимую гибкость для эффективного моделирования процессов в конкретной бизнес-области.

Следует отметить, что перенос акцента с реализации на мотивацию – характерная черта описания шаблонов проектирования. Необходимо стремиться рассматривать автоматизируемые объекты в указанном ракурсе, как части техносоциосистемы. Выбор такого подхода позволит создавать успешные программные продукты.

Качество инкапсуляции следует понимать как "любой вид сокрытия". Другими словами, это механизм, способный скрывать данные. Преимущество использования инкапсуляции состоит в том, что она упрощает разбиение программы. Инкапсулированные уровни в этом случае становятся независимыми интерфейсами, которые необходимо будет спроектировать.

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

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

Найдите то, что изменяется, и инкапсулируйте это.

При проектировании решения в первую очередь необходимо выделить то, что будет наиболее изменяемым в создаваемом продукте. Такой подход позволяет более гибко подходить к разработке. При нем не концентрируются на установлении причин возможных переделок, а сосредоточиваются на том, что хотят уметь изменять, не переделывая проект. Идея состоит в том, что следует инкапсулировать те концепции, которые могут изменяться. Шаблоны проектирования используют инкапсуляцию для распределения объектов по различным уровням приложения. Это позволяет разработчику вносить изменения на одном уровне, при этом не оказывая влияния на другой. Этим достигается слабая связанность между объектами разных уровней. Далее подобная стратегия использования инкапсуляции для реализации требуемого поведения класса будет продемонстрирована при описании нескольких шаблонов проектирования.

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

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

Анализ общности проводится над концептуальным уровнем проекта системы, тогда как анализ изменчивости относится к уровню его реализации, т.е. к процедурам конкретного воплощения системы.

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

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

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