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

Суть же самого разделения на декларацию и имплементацию состоит в том, что декларация (т.е. описание классов) меняется довольно редко, а вот реализация в процессе разработки изменяется часто.

Такое разделение даёт несколько очевидных преимуществ.

1. Скрытие реализации (не скажу, что для всех преимущество , однако для разработчиков коммерческих библиотек так точно)
2. Возможность т.н. прекомпиляции (или раздельной компиляции).
3. Стандартизация интерфейсов.

поясню.
С первым понятно...

Второе, есть код, который используется повторно в нескольких участках программы, например

Код

// code.h class Code {     Code();     DoCode(); }; // code.cpp #include "code.h" void Code::Code() {   // реализация } void Code::DoCode() {  // реализация }

и есть несколько участков в которых он используется

Код

#include "code.h" .... void Section1::func() {   Code cd;   cd.DoCode(); } .... void Section2::func() {   Code* pCode = new Code();   ...   pCode->DoCode();   ...   delete pCode; }

Все эти три класса расположены в отдельных файлах и при компиляции образуется три байткодовых файла (Code.obj, Section1.obj, Section2.obj)

А теперь представим что код в классе Code постоянно изменяется (А интерфейс не изменяется). Однако, поскольку Section1 и Section2 ссылаются лишь на прототип класс и поэтому вне зависимости от того, как будет изменён класс Code, эти два класса перекомпилироваться не будут.

Обратная ситуация в случае с реализацией, непосредственно в заголовках. Как известно C++ компилятор (в отличии от компилятора Java) при компиляции некоторого кода руководствуется только набором директив include, всё что будет таким образом найдено, используется при компиляции. Поэтому при описании реализации в заголовочных файлах, для каждого из частков кода (читай файла), который использует эти методы будет создаваться своя копия кода данных методов.(во закрутил ). Вообщем код описанный в заголовочных компилируется вновь всякий раз, когда будет использован.

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

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

Цитата(NiJazz @ 15.12.2004, 10:22)

Представляете, если бы книги так писали.

Может, лучше бы тогда было?

azesmcar все правильно написал.
Кстати, interface и implementation появились в паскале в связи с появлением модулей, а не с поддержкой ООП.

Разделение программы на заголовки (интерфейсы) и реализацию - та же самая инкапсуляция (один из ее видов). Header'ы - это public, cpp - private.
Кстати, если уж на то пошло, то модуль - это просто синглтон. У него есть интерфейс, есть реализация, и существует он в единственном экземпляре.

Цитата

Может, лучше бы тогда было?

сомневаюсь. писать, все-таки, правильно нужно.

А что у него неправильно

пунктуация

Да и про тещу горестно было читать.
А вообще пошёл флейм.

Да уж, действительно хватит.