Глава 3. Объектно-ориентированные анализ и проектирование 65

вы замените закрытое поле currentBaiance на transactions? Как вы видите на листинге 3.1, интерфейс изменится — даже не столько интерфейс, сколько определение объекта — вынуждая перекомпилировать другой модуль, так же как и ваш (обрабатывая модуль, включающий savings.hpp, компилятор должен знать, сколько места нужно отвести под объект savingsAccount). Это именно та ситуация, которую вы хотите избежать посредством модульности. Хороший пример модульности приведен в предыдущем разделе (см. "Инкапсуляция") в том месте, где вы переделали реализацию функции currentBaiance. Если изменения не вышли за пределы файла, содержащего код реализации, например Savi.ngs.cpp, то преимущества модульности реально окупятся в масштабах всего проекта.

// savings.hpp #ifndef _SAVINGS_HPP

ftdefine _SAVINGS_HPP

«

typedef float Balance;

typedef float Amount;

typedef float Rate;

class SavingsAccount ( public:

SavingsAccount(Balance initialBalance);

virtual -SavingsAccount(void);

void deposit(Amount depositAmount) ;

void withdraw(Amount withdrawalAmount) ;

void setInterestRate(Rate interestRate);

Balance currentBaiance(void) ;

Rate currentInterestRate(void);

private:

Balance currentBaiance;

Rate currentInterestRate;

t;

ftendif

Третьим — и последним в этой главе — преимуществом модульности является легкость, с которой умело сгруппированные по модулям объекты и классы можно повторно использовать в других проектах с минимальными изменениями или без оных вообще. К примеру, класс SavingsAccount можно использовать в массе разработок из области личных финансов. Повторное использование программного обеспечения — это одна из высочайших целей объектно-ориентированной разработки; нет лучшего пути облегчить себе работу, чем использовать классы, объекты и модули, которые вам уже хорошо известны!