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

Модульная конструкция

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

Цель модульного дизайна - минимизировать зависимости между модулями.

Каждый модуль состоит из двух частей: интерфейса и реализации.

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

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

Лучший модуль определяет:

  • Интерфейс модуля намного проще, чем его реализация
  • Модифицируйте модуль без изменения интерфейса

Что в интерфейсе?

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

  • Формальный

Формальный интерфейс класса состоит из подписей всех его общедоступных методов, а также имен и типов любых общедоступных переменных.

  • Неофициальный

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

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

Абстракции

Абстракция - это упрощенное представление сущности, в котором не учитываются неважные детали. Каждый модуль предоставляет абстракцию в виде своего интерфейса.

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

Абстракция может пойти не так, как надо

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

Глубокие модули

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

Площадь каждого прямоугольника пропорциональна функциональности, реализованной модулем. Верхний край прямоугольника представляет интерфейс модуля; длина этого края указывает на сложность интерфейса.

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

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

Мелкие модули

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

Красный флаг:

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