Концепции ОО подхода

Разделение программы на части (модули) до некоторой степени позволяет уменьшить ее сложность. Внутри модульной программы создаются множества хорошо определенных и документированных интерфейсов. Эти интерфейсы неоценимы для исчерпывающего понимания программы в целом. Классы и объекты составляют логическую структуру системы, они помещаются в модули, образующие физическую структуру системы. Выявление классов и объектов в проекте и организация модульной структуры – независимые действия, выполняемые итеративно. Модульность дополняет инкапсуляцию и абстрагирование.

В разных языках программирования модульность поддерживается по-разному. В Smalltalk модулей нет, а в Delphi модуль – это специальная языковая конструкция.

unit mymodule;
interface // интерфейс
  function len(a,b:extended):extended;
implementation // реализация
  uses math; // использование модуля math
  function len(a,b:extended):extended;
  begin
    len:=sqrt(a*a+b*b);
  end;
end.

В языке C++ модулями являются раздельно компилируемые файлы. Интерфейсная часть модуля помещается в заголовочный файл с расширением .hpp (может быть общим для нескольких модулей), а реализация помещается в файл с расширением .cpp. Заголовочный файл подключается к файлу с реализацией и в модули-клиенты с помощью директивы препроцессора #include. Такой подход строится исключительно на соглашении и не является строгим требованием самого языка. Пример программы, состоящей из двух модулей.

#pragma once
struct point { 
  double x,y; 
  double len();
};
extern point p1;

#include "module1.hpp"
#include <math.h>
double point::len()
{ return sqrt(x*x+y*y);
}
point p1;

#include "module1.hpp"
...
int main()
{ point a=p1;
  cout<<a.len()<<"\n";
  ...
}

В C++20 были добавлены специальные резервированные слова для определения и использования модулей.

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

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

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

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