20.Паттерны проектирования. Классификация паттернов проектирования

Паттерны (шаблоны) проектирования (design pattern) — это многократно применяемая архитектурная конструкция, предоставляющая решение общей проблемы проектирования в рамках конкретного контекста и описывающая значимость этого решения [42, 43]. Любой паттерн проектирования, используемый при разработке ПО АСОИУ, представляет собой формализованное описание часто встречающейся задачи проектирования, удачное решение данной задачи, а также рекомендации по применению этого решения в различных ситуациях. Кроме того, паттерн проектирования обязательно имеет общеупотребимое наименование. Паттерн, в общем случае, состоит из четырех элементов:

1. Имя – однозначное определение паттерна, говорящее о его назначении.

2. Задача – условия применения паттерна.

3. Решение – абстрактное описание решения задачи и модель решения в виде набора связанных классов.

4. Результат – ожидаемые последствия применения паттерна.

Классификация паттернов проектирования

Ниже представлены основные паттерны классифицированные по группам [44, 45].

1. Группа структурных шаблонов:

   1. адаптер, обеспечивающий решение проблемы взаимодействия несовместимых интерфейсов или компонентов с разными интерфейсами;

   2. декоратор (оболочка) позволяет возложить дополнительные обязанности (прозрачные для клиентов) на отдельный объект, а не на класс в целом;

   3. компоновщик (Composite) позволяет обрабатывать группу или композицию структур обьектов одновременно.

2. Группа поведенческих шаблонов

   1. команда (Command) решает проблему инкапсуляции запроса и получателя результата;

   2. посредник (Mediator) - обеспечить взаимодействие множества обьектов, без необходимости явных ссылок объектов друг на друга.

   3. Состояние (State) – позволяет сохранять – восстанавливать текущее состояние объекта.

3. Группа порождающих шаблонов проектирования

   1. одиночка (singleton) - обеспечивает гарантию наличия только одного объекта класса.

   2. абстрактная фабрика, (Abstract factory) — позволяет изменять поведение системы, варьируя создаваемые объекты, при этом сохраняя интерфейсы.

21.Разработка программного обеспечения через тестирование. Процесс рефакторинга по асоиу

Разработка программного обеспечения через тестирование.

В современных технологиях разработки программного обеспечения основанных на так называемым гибком (agile) подходе особое внимание уделяется процессу автоматического тестирования кода [46, 47]. Для это разработаны специальные инструменты, позволяющие формировать классы для тестирования (Unit tests) создаваемой программы, интегрированные в среду разработки. Процесс реализации программного кода через написание тестов к нему называется разработка через тестирования (Test – driven development). Данный подход был заявлен Кент Беком, основоположником экстремального программирования [46]. Цикл разработки в этом случае включает следующие шаги:

1. реализуется тест (Unit Test) для тестирования реализуемого функционала. Так как не создан класс и объекты которые подвергаются тестированию, то тест не срабатывает. Таким образом, срабатывают все тесты кроме добавленного.

2. реализуются классы, выполняющие требуемый функционал.

3. происходит отладка программы с целью выполнения наборов тестов.

4. происходит рефакторинг программы с целью улучшения эффективности кода.

К средствам автоматического тестирования относятся программное обеспечение NUnit (http://www.nunit.org/index.php) которое интегрируется в среду IDE MS Visual Studio. Методика создания тестов с использованием NUnit включает следующие шаги:

1. создание проекта (Project) в имеющемся решении (Solution);

2. добавление в ссылки созданного проекта каркАСОИУ NUnit (nunit.framework);

3. создание классов для тестирования [Test] в области [TestFixture]

4. выполнение тестов.

Результат выполнения тестов зависит от всех тестов включенных в TestFixture. Если в наборе тестов не выполняется хотя бы один тест, то считается, что набор тестов также не выполняется (рис 23.1).

Рисунок 23.1 Выполнение набора тестов.

Процесс рефакторинга ПО АСОИУ.

Рефакторинг— процесс полного или частичного преобразования внутренней структуры программы при сохранении её внешнего поведения [47]. В его основе лежит последовательность небольших эквивалентных (т.е., сохраняющих поведение) преобразований.

Ниже перечислены некоторые методы рефакторинга.

1. Изменение сигнатуры метода (Change Method Signature) (заключается в добавлении, изменении или удалении параметра метода).

1. Инкапсуляция поля (Encapsulate Field) – закрывается (private) свойство и добавляются public методы доступа к нему.

2. Выделение класса (Extract Class) – создается новый класс с указанными методами и формируются объекты для доступа к методам.

3. Выделение интерфейса (Extract Interface).

4. Выделение метода (Extract Method) – разбивается метод на несколько из расчета повышения читаемости и восприятия методов.

На рисунке 23.2 отображены возможные методы рефакторинга поддерживаемые в среде MS Visual Studio c интегрированным инструментом ReSharper (http://www.jetbrains.com/resharper/download/)

Рисунок 23.2 Методы рефакторинга в среде ReSharper.