Разделение модуля API – CodesCode

Стоимость изменения или поддержания программного обеспечения в основном высока из-за каскадирования, которое представляет собой значительное изменение в связанной системе программного обеспечения.

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

Пример

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

Вероятно, у вас будет три сервиса для каждой из упомянутых функций:

Теперь добавим взаимодействие между модулями:

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

Предположим, что посещение выглядит следующим образом:

посещение {  идентификаторПосещения  имяПокупателя  имяПитомца  датаПосещения  процедуры [] }

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

процедура {  идентификаторПроцедуры  типПроцедуры  цена }

Для создания счета Сервису «Счета» понадобятся как данные о посещении, так и сделанные процедуры:

счет {  деталиПосещения  сделанныеПроцедуры []  суммаКОплате }

У нас есть несколько вариантов передачи данных в Сервис «Счета»:

Он может принимать объект посещения и массив объектов процедур. Затем он создаст печатные детали из объекта посещения и массива процедур и рассчитает сумму цен каждой процедуры в массиве процедур.

ИЛИ

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

Связывание модулей

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

Вариант 1: Передача целых объектов

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

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

Вариант 2: Передача только неизменяемых данных

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

ПолучитьДеталиПосещения(идентификаторПосещения) → строка

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

ПолучитьПроцедурыПосещенияСЦенами(идентификаторПосещения) → Словарь<строка, число с плавающей запятой>

Заключение

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

Спасибо за чтение! Пожалуйста, поделитесь своими мыслями.