Предисловие

На Хабре есть много статей, часть из которых, как мне показалось, относится к обзорным, а часть к детальным реализациям. Первый вид чаще характеризуется словосочетанием «на подумать», второй — представляет собой статью‑справку. Данная статья больше относится к первому виду.

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

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

Если есть на просторах интернета подобный материал или серия статей по очень похожей тематике — смело указывайте в комментариях. Если увидите любые подозрительные неточности в статье — смело указывайте в комментариях. Я имею представление о концепции ООП, оптимизациях при ООП подходах, использовании SOLID, серии диаграмм UML, BPMN. В данном материале как и во многом другом хотелось проанализировать целостно картину и выявить общие закономерности, на основе этого заново собрать всю картину, но из новых пазлов, которые охватывают больше материала, больше всевозможных комбинации.

Всевозможные инициалы людей и названия компаний, организаций, указанные в статье выдуманы и не имеют никакой связи с реальным миром.

Оглавление

• введение

• описание мира

• представление системы

• виды дизайна

• определение и реализация

• внедрение зависимостей

• тестирование

• примечание

Введение

Думаю, вы знаете, что во всех областях знания есть всего два подхода:

• Теоретический

• Эмпирический

Если первый опирается на математический аппарат и систему знаний, то второй является некоторой «Реализацией» этой теории на практике, исходя из чего получаются новые знания, которые в свою очередь, могут корректировать теорию.

Важно понимать, что представляет из себя в данном контексте «реализация». Есть «Теория», которая описывает определенный процесс. Можно провести несколько конкретных опытов, которые полностью соответствуют условиям теоретического описания процесса. Таким образом получается следующая схема.

Можно сделать вывод, что «Теория» первостепеннее «Реализации». А «Реализация» зависима от «Теории» и не должна существовать в единственном экземпляре.

Описание мира

Все, что нас окружает – информация, представляемая в виде данных, которые мы можем использовать. При этом данные имеют изменяемую природу, из любых данных можно породить новые. Действие, которое происходит над одними данными, чтобы породить новые называется «Процессом».

Любую систему можно охарактеризовать определенными данными о ней, т.е. «Состоянием системы», любой «Процесс», в свою очередь, изменяет старое «Состояние системы» на новое «Состояние системы».

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

• «Процесс»

• «Состояние системы»

Мы плавно подошли к теории автоматов.

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

Представление системы

Любую систему можно представить в виде конечного автомата. Конечный автомат сочетает в себе состояние, которое представляет из себя «Состояние системы» (система – конечный автомат), и логику, которая представляет из себя «Процесс». Важно понимать, что конечный автомат должен иметь и состояние, и логику в любом случае.

Перейдем к более высокой абстракции с определенными дополнительными условиями.

Введем более гибкий термин для описания системы абстрактным понятием – «Сущность». «Сущность» в отличии от конечного автомата состоит из нескольких «Процессов» и/или нескольких «Состояний системы», но не требует одновременного наличия обоих. «Сущностей» может быть сколько угодно, все они могут взаимодействовать между собой. Таким образом, у нас возникают следующие виды «Сущности», называемые «Конфигурациями сущности»:

• «Сущность с состоянием» – сущность не может ничего делать, все действия над изменением ее состояния производят внешние сущности. Представляет из себя «Сущность» с наличием внутри себя одного или нескольких «Состояний системы».

• «Сущность с процессом» – сущность может менять состояние другой сущности. Представляет из себя «Сущность» с наличием внутри себя одного или нескольких «Процессов».

• «Сущность с состоянием и процессом» – является конечным автоматом. Сущность может менять свое состояние, состояние других сущностей. Ее состояние тоже могут менять. Она представляет из себя «Сущность» с наличием внутри себя одного или нескольких «Процессов» и «Состояний системы».

Виды дизайна

Для дальнейшего прочтения читателю рекомендовано знать такие виды дизайна, как DOD (Data-Oriented Design) и OOD (Object-Oriented Design) при организации систем.

Рассмотрим их в контексте данной статьи:

• DOD. Данному техническому дизайну соответствуют «Сущность с состоянием», «Сущность с процессом».

• OOD. Ставит условие, что каждая сущность должна иметь как минимум «Состояние системы» и «Процесс», который на направлен на изменение «Состояния системы» этой же сущности. То есть «Сущность» может быть только «Сущностью с состоянием и процессом».

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

Определение и реализация

Введем два новых термина, которые будут являться подтипами «Сущности»:

• «Описание сущности»

• «Реализация сущности»

«Описание сущности» – это «Сущность», определяющая условия или описания поведения некоторой системы, ее можно трактовать как определенную «Теорию». При этом оно не имеет реализацию описанного функционала, а если имеет, то часть этой реализации должна быть доступна для изменения в «Реализации сущности». «Описание сущности» поддерживает все виды «Конфигурации сущности».

«Реализация сущности» – это «Сущность», соответствующая всем условиям конкретного «Описания сущности». Можно трактовать термин как «Реализация». «Реализация сущности» поддерживает все виды «Конфигурации сущности». У одного и того же «Описания сущности» может быть несколько «Реализаций сущности».

Пример:

Важно учесть, что «Описание сущности» точно гарантирует, что у зависимой от неё «Реализации сущности» есть определенные «Состояния системы» и определенные «Процессы», которыми может воспользоваться любая другая «Сущность» при взаимодействии с данной «Реализацией сущности».

Другими словами, «Реализация сущности» зависит от определенного «Описания сущности» и удовлетворяет всем её условиям. «Реализация сущности» может выступать самостоятельной «Сущностью» без зависимости от «Описания сущности».

Если «Реализация сущности» с названием A1 имеет зависимость от определенного «Описания сущности» с именем IA1, то все внешние «Сущности» взаимодействуют не с сущностью A1 напрямую, а лишь через описание «Сущности» IA1, не зная, с какой именно «Реализацией сущности» они взаимодействуют.

Пример:

Внедрение зависимостей

Рассмотрим совокупность «Сущностей» и зависимости между ними. Вспомним, что «Сущность» имеет в себе «Процессы» и «Состояния системы». Введем понятие «Логика сущности», которая представляет из себя множество «Процессов» и «Состояний системы». Таким образом, «Сущность» содержит в себе «Логику сущности». Рассмотрим схему сущностей, в которой префиксом Р обозначим «Реализацию сущности», а префиксом О – «Описание сущности». Данная схема аналогична предыдущей.

Обратим внимание на второй тип связи, при котором одно «Описание сущности» основано на другом «Описании сущности». В данном случае второе «Описание сущности» – О_В1 – соответствует всем поставленным условиям О_А1 и на основе их создает более строгие условия таким образом, чтобы не возникали противоречия.

Введем понятие «Системная сущность». «Системная сущность» – это «Сущность», которая содержит в себе помимо «Логики сущности» еще и другие подобные «Системные сущности». Построим схему для «Системных сущностей» с обозначением внутренностей «Системных сущностей».

«Реализация сущности» к соответствующему «Описанию сущности» выделена синим цветом.

Рассмотрим данный пример агрегации, одна «Системная сущность» содержит в себе другую «Системную сущность», которую мы будем называть «Подсущностью».

Заметим, когда «Подсущность» является «Реализацией сущности», она является лишь вспомогательным инструментом для «Логики сущности», а когда она является «Описанием сущности», то не имеет в данной сущности четко определенной реализации. Выбор реализации теперь определяется в контексте внешней сущности.

Таким образом, мы определили термин «Внедрение зависимости» – процесс определения внешней сущностью «Реализации сущности» в качестве параметра для своей «Подсущности», являющейся «Описанием сущности». «Системная сущность», в которой определяется «Реализация сущности» к соответствующему «Описанию сущности» называется – «Точка внедрения зависимости».

Важно заметить, что «Точка внедрения зависимости» может располагаться дальше от исходной позиции. Пример такой ситуации показан на рисунке.

На данном рисунке «Точкой внедрения зависимости» для O_B1 -  будет «Системная сущность» на уровень выше – Р_А1, для О_Н1 – на два уровня выше Р_П1, для О_Ш1 – на два уровня выше Р_П1, для О_Ш2 - на уровень выше О_Ш3, для О_Т1 - в другой сущности Р_Т1.

Для лучшего понимания приведем пример, поясняющий, последнюю диаграмму:

Тестирование

При тестировании любой системы проверяется насколько её функционал соответствует разработанному описанию. В рамках «Системной сущности» требуется проверить следующие пункты:

1. Соответствие «Системной сущности» (если она является «Реализацией сущности») зависимому «Описанию сущности» (если таковое есть).

2. Проверка функционала «Системной сущности», который может быть использован внешними «Системными сущностями».

3. Проверка общения «Системной сущности» с «Подсущностями», которые являются «Описаниями сущности».

Пример:

На рисунке отображена тестируемая «Системная сущность».

Рассматриваемая сущность – сущность Р_Б1. Подсущности: сущность Р_В1, сущность О_С1.

У рассматриваемой сущности нет зависимости от «Описания сущности», поэтому нет проверки первого пункта.

Создаются сценарии использования рассматриваемой сущности в виде тестов для проверки второго пункта. Для полноценной работы сценария при наличии в нем «Подсущностей» типа «Описания сущности» требуется предоставить им зависимую «Реализацию сущности». В этом случае в качестве «Реализации сущности» используются так называемые stub компоненты, которые имитируют работу компонента.

Также создаются сценарии использования рассматриваемой сущности в виде тестов для проверки 3 пункта. Главная цель – проверка, что рассматриваемая «Системная сущность» корректно использует свои «Подсущности», с условием, что эти «Подсущности» являются «Описаниями сущности». В качестве «Реализации сущности» для «Подсущности» в виде «Описания сущности» используются так называемые mock компоненты, которые имитируют работу и на каждом шаге проверяют корректность использования сущности.

Примечание

В контексте программирования термин «Системная сущность» чаще всего называется классом, а «Описание сущности» и «Реализация сущности» обозначаются абстрактными/интерфейсными классами и имплементациями соответственно.

В программировании условия проверки могут существовать на двух этапах:

• Compile time

• Runtime

Таким образом, «Реализация сущности» может быть присоединена к соответствующему «Описанию сущности» как в compile time, так и в runtime. При внедрении зависимости в compile time подразумевается, что данная «Реализация сущности» назначается разработчиком вручную. При внедрении зависимости в runtime подразумевается, что данная «Реализация сущности» может быть легко изменена на другую по условию в программе.