> p->x = x;
> p->y = y;
> return p;
>}
>double distance(struct Point* p1, struct Point* p2) {
> double dx = p1->x – p2->x;
> double dy = p1->y – p2->y;
> return sqrt(dx*dx+dy*dy);
>}
Пользователи >point.h не имеют доступа к членам структуры >Point. Они могут вызывать функции >makePoint() и >distance(), но не имеют никакого представления о реализации структуры Point и функций для работы с ней.
Это отличный пример поддержки инкапсуляции не в объектно-ориентированном языке. Программисты на C постоянно использовали подобные приемы. Мы можем объявить структуры данных и функции в заголовочных файлах и реализовать их в файлах реализации. И наши пользователи никогда не получат доступа к элементам в этих файлах реализации.
Но затем пришел объектно-ориентированный C++ и превосходная инкапсуляция в C оказалась разрушенной.
По техническим причинам[12] компилятор C++ требует определять переменные-члены класса в заголовочном файле. В результате объектно-ориентированная версия предыдущей программы Point приобретает такой вид:
>point.h
>class Point {
>public:
> Point(double x, double y);
> double distance(const Point& p) const;
>private:
> double x;
> double y;
>};
>point.cc
>#include "point.h"
>#include
>Point::Point(double x, double y)
>: x(x), y(y)
>{}
>double Point::distance(const Point& p) const {
> double dx = x-p.x;
> double dy = y-p.y;
> return sqrt(dx*dx + dy*dy);
>}
Теперь пользователи заголовочного файла >point.h знают о переменных-членах >x и >y! Компилятор не позволит обратиться к ним непосредственно, но клиент все равно знает об их существовании. Например, если имена этих членов изменятся, файл >point.cc придется скомпилировать заново! Инкапсуляция оказалась разрушенной.
Введением в язык ключевых слов >public, >private и >protected инкапсуляция была частично восстановлена. Однако это был лишь грубый прием (хак), обусловленный технической необходимостью компилятора видеть все переменные-члены в заголовочном файле.
Языки Java и C# полностью отменили деление на заголовок/реализацию, ослабив инкапсуляцию еще больше. В этих языках невозможно разделить объявление и определение класса.
По описанным причинам трудно согласиться, что ОО зависит от строгой инкапсуляции. В действительности многие языки ОО практически не имеют принудительной инкапсуляции[13].
ОО безусловно полагается на поведение программистов – что они не станут использовать обходные приемы для работы с инкапсулированными данными. То есть языки, заявляющие о поддержке OO, фактически ослабили превосходную инкапсуляцию, некогда существовавшую в C.
Наследование?
Языки ОО не улучшили инкапсуляцию, зато они дали нам наследование.
Точнее – ее разновидность. По сути, наследование – это всего лишь повторное объявление группы переменных и функций в ограниченной области видимости. Нечто похожее программисты на C проделывали вручную задолго до появления языков ОО[14].
Взгляните на дополнение к нашей исходной программе point.h на языке C:
>namedPoint.h
>struct NamedPoint;
>struct NamedPoint* makeNamedPoint(double x, double y, char* name);
>void setName(struct NamedPoint* np, char* name);
>char* getName(struct NamedPoint* np);
>namedPoint.c
>#include "namedPoint.h"
>#include
>struct NamedPoint {
> double x,y;
> char* name;
>};
>struct NamedPoint* makeNamedPoint(double x, double y, char* name) {
> struct NamedPoint* p = malloc(sizeof(struct NamedPoint));
> p->x = x;
> p->y = y;
> p->name = name;
> return p;
>}
>void setName(struct NamedPoint* np, char* name) {
> np->name = name;
>}
>char* getName(struct NamedPoint* np) {
> return np->name;
>}
>main.c
>#include "point.h"