ством компонентно-ориентированного подхода с жёстким разделением границ компонентов, при разработке «простой» ИС можно на архитек-

турном уровне заранее заложить будущую миграцию на микросервисы,

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

3.6. Шаблоны и антишаблоны проектирования ИС

3.6.1. Шаблоны проектирования

Для упрощения реализации компонентно-ориентированных систем могут использоваться так называемые шаблоны проектирования [2, 47].

Под шаблонами проектирования понимается набор устоявшихся прак-

тик реализации отдельных типовых задач проектирования ИС.

Всю совокупность шаблонов проектирования можно разделить:

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

тами ИС;

–системные шаблоны проектирования, описывающие верхне-

уровневые (выскоабстрактные) принципы организации отдель-

ных компонентов системы;

–структурные шаблоны проектирования, описывающие способы взаимосвязи программных сущностей внутри компонентов;

–поведенческие шаблоны проектирования, описывающие пове-

дение отдельных программных сущностей внутри компонен-

тов;

–порождающие шаблоны проектирования, предназначенные для описания способов создания новых программных сущностей

внутри компонентов ИС.

58

К архитектурным шаблонам проектирования относятся следую-

щие шаблоны:

–сессия (описывает правила обработки запросов, поступающих от клиентов в изолированной для клиентов среде);

–обратный вызов (сводится к разделению синхронного режима

«запрос-ответ» на две асинхронные операции);

–постоянное обновление (обеспечивает возможность клиенту получать постоянное обновление необходимых ему для работы данных от сервера; сервер при реализации такого шаблона должен знать о местоположении клиентов);

–шаблон проектирования «модель-представление-контроллер»

(описывает разделение архитектуры на три горизонтальных

слоя).

Отдельно стоит остановиться на шаблоне MVC («модель-

представление-контроллер»). Общую схему архитектурной реализации шаблона можно описать так, как представлено на рис. 15. Несмотря на то, что изначально шаблон предполагался как способ организации ар-

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

сов.

Рисунок 15 – Шаблон проектирования MVC

59

–декоратор (decorator) – позволяет расширить функционал про-

граммной сущности без изменения её внутренней структуры за счёт инкапсуляции функционала этой сущности внутри сущно-

сти-декоратора;

–прокси (proxy) – обеспечивает контроль доступа к объекту за счёт его инкапсуляции внутри прокси-сущности.

Следующие шаблоны проектирования можно отнести к поведен-

ческим:

–команда (command) – позволяет представить обработчик дан-

ных в виде объекта для последующей передачи команд от кли-

ента серверу и их отложенной обработки;

–итератор (iterator) – предоставляет метод последовательного доступа к элементам коллекции, позволяет осуществлять дос-

туп в том числе к байтовым последовательностям в режиме па-

кетного чтения;

–состояние (state) – обеспечивает связь состояния объекта с не-

которым конкретным именованным состоянием, упрощает реа-

лизацию конечных автоматов в ИС [48];

–шаблонный метод (template method) – позволяет заменить ме-

тоды базового класса методами производных классов, упроща-

ет быстрое создание прототипов ИС.

Вкачестве порождающих шаблонов проектирования выделяют следующие шаблоны:

–абстрактная фабрика (abstract factory) – предоставляет возмож-

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

вой для реализации подхода «инверсия зависимостей»;

–строитель (builder) – порождающий шаблон проектирования,

организующий процесс создания объекта за счёт последова-

61

тельного вызова отдельных методов, конфигурирующих созда-

ваемый объект и всегда завершающихся вызовом метода соз-

дания объекта (например, метода build или create);

–одиночка (singleton) – способ организации программного кода таким образом, чтобы экземпляр класса создавался в про-

граммном коде лишь один раз (обычно реализуется за счёт ис-

пользования статического поля для хранения объекта, закрыто-

го конструктора этого объекта и метода доступа, создающего

объект, если он ранее не был создан, либо возвращающего уже созданный экземпляр класса).

Отдельно стоит остановиться на шаблоне проектирования «оди-

ночка». В объектно-ориентированных языках крайне не рекомендуется использовать так называемые глобальные переменные. В противовес им использование шаблона singleton считается приемлемым. Связана такая двойственность со следующими причинами:

–глобальные переменные в отличие от singleton не обеспечивают контроль доступа к данным: «одиночка» может контролировать собственную внутреннюю структуру;

–глобальные переменные нельзя отнести к одному вертикально-

му срезу (они используются для решения нескольких различ-

ных задач), в то время как «одиночка», являясь программной сущностью, всегда связан с той или иной функциональной областью ИС;

–глобальные переменные не обеспечивают потокобезопасное изменение своей структуры, в то время как singleton имеет воз-

можность организовать такой доступ (например, за счёт ис-

пользования подхода double-checked lock [49]).

62