Чистая архитектура. Искусство разработки программного обеспечения

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

Принципы устойчивости абстракций (SAP) и устойчивых зависимостей (SDP) вместе соответствуют принципу инверсии зависимостей (DIP) для компонентов. Это верно, потому что принцип SDP требует, чтобы зависимости были направлены в сторону устойчивости, а принцип SAP утверждает, что устойчивость подразумевает абстрактность. То есть зависимости должны быть направлены в сторону абстрактности.

Однако принцип DIP сформулирован для классов, и в случае с классами нет никаких полутонов. Класс либо абстрактный, либо нет. Принципы SDP и SAP действуют в отношении компонентов и допускают ситуацию, когда компонент частично абстрактный или частично устойчивый.

Мера абстрактности

Мерой абстрактности компонента служит метрика A. Ее значение определяется простым отношением количества интерфейсов и абстрактных классов к общему числу классов в компоненте.

• Nc: число классов в компоненте.

• Na: число абстрактных классов и интерфейсов в компоненте.

• A: абстрактность. A = Na ÷ Nc.

Значение метрики A изменяется в диапазоне от 0 до 1. 0 означает полное отсутствие абстрактных классов в компоненте, а 1 означает, что компонент не содержит ничего, кроме абстрактных классов.

Главная последовательность

Теперь мы можем определить зависимость между устойчивостью (I) и абстрактностью (A). Для этого нарисуем график со значениями A по вертикальной оси и значениями I — по горизонтальной (рис. 14.12). Если нанести на график «хорошие» компоненты обоих видов, обнаружится, что максимально устойчивые и абстрактные находятся слева вверху, в точке с координатами (0, 1), а максимально неустойчивые и конкретные — справа внизу, в точке (1, 0).

Рис. 14.12. График I/A

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

Так как нельзя потребовать, чтобы все компоненты находились в двух точках (0, 1) или (1, 0), мы должны предположить, что на графике A/I имеется некоторое множество точек, определяющих оптимальные позиции для компонентов. Вывести это множество можно, определив области, где компоненты не должны находиться, — иными словами, определив зоны исключения (рис. 14.13).

Рис. 14.13. Зоны исключения

Зона боли

Рассмотрим компонент в точке (0, 0). Это очень устойчивый и конкретный компонент. Такие компоненты нежелательны, потому что слишком жесткие. Их нельзя расширить, потому что они неабстрактные, и очень трудно изменить из-за большой устойчивости. Поэтому правильно спроектированные компоненты обычно не должны находиться рядом с точкой (0, 0). Область вокруг точки (0, 0) — это зона исключения, которую называют зоной боли.

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

Другой пример программного обеспечения, лежащего поблизости от точки (0, 0) — конкретная библиотека вспомогательных функций. Хотя такая библиотека имеет метрику I со значением 1, в действительности она может быть очень негибкой. Возьмем для примера компонент String. Даже при том, что все классы в нем конкретны, он используется настолько широко, что его изменение может породить хаос. Поэтому String — негибкий.

Негибкие компоненты в зоне, окружающей точку (0, 0), безопасны, потому что, скорее всего, не будут изменяться. По этой причине проблемы вызывают только изменчивые программные компоненты, находящиеся в зоне боли. Чем более изменчив компонент, находящийся в зоне боли, тем больше «боли» он доставляет. Фактически изменчивость можно рассматривать как третью ось графика. С этой точки зрения на рис. 14.13 изображена самая болезненная плоскость, где изменчивость = 1.

Зона бесполезности

Рассмотрим компонент рядом с точкой (1, 1). Такие компоненты также нежелательны, потому что они максимально абстрактны и не имеют входящих зависимостей. Они бесполезны. Поэтому данная область так и называется: зона бесполезности.