Читать онлайн «Как функции, не являющиеся методами, улучшают инкапсуляцию». Страница 2

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

Этот анализ применяется к любому виду методов, включая и статические. Добавление статического метода к классу, когда его функциональные возможности могут быть реализованы как не члены и не друзья уменьшают инкапсуляцию точно так же, как это делает добавление нестатического метода. Перемещение свободной функции в класс с оформлением ее в виде статического метода, только для того, чтобы показать, что она соприкасается с этим классом, является плохой идеей. Например, если я имею абстрактный класс для виджетов (Widgets) и затем использую функцию фабрики классов [4,5,6], чтобы дать возможность клиентам создавать виджеты, я могу использовать следующий общий, но худший способ организовать это:

// a design less encapsulated than it could be

class Widget {

 … // внутренее наполнение Widget; может быть:

 // public, private, или protected

public:

 // может быть также "недругом" и не членом

 static Widget* make(/* params */);

};

Лучшей идеей является создание вне Widget, что увеличивает совокупную инкапсуляцию системы. Чтобы показать, что Widget и его создание (make) все-таки связаны, используется соответствующее пространство имен (namespace):

// более инкапсулированный проект

namespace WidgetStuff {

 class Widget {…};

 Widget* make(/* params */);

};

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

Возможно что Вы, как и многие люди, с которыми я обсуждал эту проблему, имеете представление относительно синтаксического смысла моего утверждения, что не методы и не друзья предпочтительнее методов. Возможно, что Вы даже "купились" на мои аргументы относительно инкапсуляции. Теперь, предположим, что класс Wombat (Вомбаты – семейство австралийских млекопитающих отряда сумчатых. Благодарю Алекса за коррекцию перевода. А.Л.) поддерживает функциональные возможности, поедания и засыпания. Далее предположим, что функциональные возможности, связанные с поеданием, должны быть выполнены как метод, а засыпание может быть выполнено как член или как не член и не друг. Если Вы следуете моим советам, описанным выше, вы создадите описание подобные этим:

class Wombat {

public:

 void eat(double tonsToEat);

 …

};

void sleep(Wombat& w, double hoursToSnooze);

Это привело бы к синтаксическому противоречию для клиентов класса, потому что для

Wombat w;

они напишут:

w.eat(.564);

при вызове eat. Но они написали бы:

sleep(w, 2.57);

для выполнения sleep. При использовании только методов класса можно было бы иметь более опрятный код:

class Wombat {

public:

 void eat(double tonsToEat);

 void sleep(double hoursToSnooze);

 …

};

w.eat(.564);

w.sleep(2.57);

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

Чтобы непосредственно ее использовать, нужны функции – не методы. Позвольте нам продолжить пример Wombat. Предположим, что Вы пишете программу моделирования этих прожорливых созданий, и воображаете, что одним из методов, в котором Вы часто нуждаетесь при использовании вомбатов, является засыпание на полчаса. Ясно, что Вы можете засорить ваш код обращениями w.sleep (.5), но этих (.5) будет так много, что их будет трудно напечатать. А что произойдет, если это волшебное значение должно будет измениться? Имеется ряд способов решить эту проблему, но возможно самый простой заключается в определении функции, которая инкапсулирует детали того, что Вы хотите сделать. Понятно, что если Вы не являетесь автором Wombat, функция будет обязательно внешней, и вы будете вызвать ее таким образом:

// может быть inline, но это не меняет сути

void nap(Wombat& w) {w.sleep(.5);}

Wombat w;

…

nap(w);

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

Если Вы самокритичны и честны сами с собой, вы увидите, что имеете эту предполагаемую несогласованность со всеми нетривиальными классами, Вы используете ее потому, что класс не может имеет любую функцию, которую пожелает како-то клиент. Каждый клиент добавляет, по крайней мере, несколько своих функций для собственного удобства, и эти функции всегда не являются методами классов. Программисты на C++ используют это, и они не думают ничего о этом. Некоторые вызовы используют синтаксис методов, а некоторые синтаксис внешних вызовов. Клиенты только ищут, какой из синтаксисов является соответствующим для тех функций, которые они хотят вызвать, затем они вызывают их. Жизнь продолжается. Это происходит особенно часто в STL (Стандартной библиотеки C++), где некоторые алгоритмы являются методами (например, size), некоторые – не методами (например, unique), а некоторые – тем и другим (например, find). Никто и глазом не моргает. Даже Вы.

Herb Sutterr объяснил, что "интерфейс" класса (подразумевая, функциональные возможности, обеспечиваемые классом) включает также внешние функции, связанные с классом. Им также показано, что правила области видимости имен в C++ поддерживают эти изменения понятия "интерфейса" [7,8]. Это замечательные новости для моего тезиса "не друзья и не члены лучше, чем члены", потому что это означает, что решение сделать функцию, зависимую от класса, в виде не друга – не члена вместо члена даже не изменяет интерфейс этого класса! Кроме того, вывод функций интерфейса класса за границы определения класса ведет к некоторой замечательной гибкости упаковки, которая была бы иначе недоступна. В частности, это означает, что интерфейс класса может быть разбит на множество заголовочных файлов.

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

Вместо размещения всех Wombat-зависимых функций в одном заголовочном файле, предпочтительнее было бы разместить элементы интерфейса Wombat в четырех отдельных заголовках: один для функций ядра Wombat (описания функций, связанных с определением класса), и по одному для каждой дополнительной функции, определяющей, еду, сон, и размножение. Клиенты включают в свои программы только те заголовки, в которых они нуждаются. Возникающее в результате программное обеспечение не только более ясное, оно также содержит меньшее количество зависимостей, пустых для трансляции [4,9]. Этот подход, использующий множество заголовков, был принят для стандартной библиотеки (STL). Содержание namespace std размещено в 50 различных заголовочных файлах. Клиенты включают заголовки, объявляющие только части библиотеки, необходимые им, и они игнорирует все остальное.

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