Предположим, что автор класса Wombat обнаружил, что клиенты Wombat часто нуждаются в ряде дополнительных функций, связанных, с едой, сном и размножением. Такие функции по определению не строго необходимы. Те же самые функциональные возможности могли бы быть получены через вызов других (хотя и более громоздких) методов. В результате, а также в соответствии с моим советом в этой статье, каждая дополнительная функция должна быть не другом и не методом. Но предположим, что клиенты дополнительных функций, используемых для еды, редко нуждаются в дополнительных функциях для сна или размножения. И предположим, что клиенту, использующему дополнительные функции для сна и размножения, также редко нужны дополнительные функции для еды. То же самое можно развить на функции размножения и сна.
Вместо размещения всех Wombat-зависимых функций в одном заголовочном файле, предпочтительнее было бы разместить элементы интерфейса Wombat в четырех отдельных заголовках: один для функций ядра Wombat (описания функций, связанных с определением класса), и по одному для каждой дополнительной функции, определяющей, еду, сон, и размножение. Клиенты включают в свои программы только те заголовки, в которых они нуждаются. Возникающее в результате программное обеспечение не только более ясное, оно также содержит меньшее количество зависимостей, пустых для трансляции [4,9]. Этот подход, использующий множество заголовков, был принят для стандартной библиотеки (STL). Содержание namespace std размещено в 50 различных заголовочных файлах. Клиенты включают заголовки, объявляющие только части библиотеки, необходимые им, и они игнорирует все остальное.
Кроме этого, такой подход расширяем. Когда объявления функций, составляющих интерфейс класса, распределены по многим заголовочным файлам, это становится естественным для клиентов, которые размещают свои наборы дополнительных функций, специфические для приложения, в новых заголовочных файлах, подключаемых дополнительно. Другими словами, чтобы обработать специфические для приложения дополнительные функции, они поступают точно так же, как и авторы класса. Это то, что и должно быть. В конце концов, это только дополнительные функции.
Минимальность и инкапсуляция
В "Эффективном использовании C++" (Effective C++), я приводил доводы в пользу интерфейсов класса, которые являются полными и минимальный [10]. Такие интерфейсы позволяют клиентам класса делать что-либо, что они могли бы предположительно хотеть делать, но классы содержат методов не больше, чем абсолютно необходимо. Добавление функций вне минимума, необходимого для того, чтобы клиент мог сделать его работу, как я писал, уменьшает возможности повторного использования класса. Кроме того, увеличивается время трансляции для программы клиента. Джек Ривес (Jack Reeves) написал, что добавление методов сверх этих требований, нарушает принцип открытости-закрытости, производит жирные интерфейсы класса, и в конечном счете ведет к загниванию программного обеспечения [11]. Возможно увеличение числа параметров, чтобы уменьшить число методов в классе, но теперь мы имеем дополнительную причину, чтобы отказаться от этого: уменьшается инкапсуляция класса.
Конечно, минимальный интерфейс класса – не обязательно самый лучший интерфейс. Я отметил в "Эффективном использовании C++", что добавление функций сверх необходимости может быть оправданным, если это значительно увеличивает эффективность класса, делает класс, более легким в использовании или предотвращает вероятные клиентские ошибки [10]. Основываясь на его работе с различными строковыми классами, Джек Ривес отмечает, что для некоторых функций трудно ощутить, когда их делать не членами, даже если они могли быть не друзьями и не методами [12]. "Наилучший" интерфейс для класса может быть найден только после балансировки между многими конкурирующими параметрами, среди которых степень инкапсуляции является лишь одним.
Однако урок этой статьи должен быть ясен. Стандартная мудрость, несмотря на использование "недругов" и не методов улучшает инкапсуляцию класса, и предпочтительнее для таких функций над методами, потому что делает решение проще, когда надо проектировать и разрабатывать классы с интерфейсами, которые являются полными и минимальными (или близкими к минимальному). Возражения, связанные с неестественностью, возникающей в результате изменения синтаксиса вызова, являются совершенно необоснованными, а склонность к "недругам" и не методам ведет к пакующим стратегиям для организации интерфейсов класса, которые минимизируют клиентские зависимости при трансляции, сохраняя доступ к максимальному числу дополнительных функций.
Пришло время, чтобы отказаться от традиционной, но неточной идеи, связанной с тем, что означает "быть объектно-ориентированным". Действительно ли Вы – истинный сторонник инкапсуляции? Если так, я знаю, что вы ухватитесь за "недружественные" внешние функции с пылом, которого они заслуживают.
Благодарности
Благодарю Арона Канду за постановку вопроса, которая привела к этой статье. Благодарю также Джека Ривеса (Jack Reeves), Херба Шутера (Herb Sutter), Дейва Смаллберга (Dave Smallberg), Андрея Александреску (Andrei Alexandrescu), Брюса Екела (Bruce Eckel), Брайна Страуструпа (Bjarne Stroustrup), и Андрю Коунига) Andrew Koenig за комментарии перед публикацией. В заключение, большая благодарность Аделе Новак (Adela Novak) за организации семинаров C++ в Люцерне (Швейцарии), которая вели к многочасовым дискуссиям, позволившим мне написать начальный проект этой статьи.
Заметки и ссылки
[1] Scott Meyers. Effective C++: 50 Specific Ways to Improve Your Programs and Designs, First Edition (Addison-Wesley, 1991), Item 19.
[2] Scott Meyers. Effective C++, Second Edition (Addison-Wesley, 1998).
[3] The algorithm remains unchanged in current printings of Effective C++, because I'd have to also add the requisite reasoning (this article), and making such a substantial change to a book already in production simply isn't practical.
[4] Effective C++, Item 34.
[5] Erich Gamma et al. Design Patterns, Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995). Also known as the GOF or ''Gang of Four'' book.
[6] James O. Coplien. Advanced C++: Programming Styles and Idioms (Addison-Wesley, 1991).
[7] Herb Sutter. ''Sutter's Milclass="underline" What's in a Class?'' C++ Report, March 1998.
[8] Herb Sutter. Exceptional C++ (Addison-Wesley, 1999), Items 31-34.
[9] John Lakos. Large-Scale C++ Software Design (Addison-Wesley, 1996).
[10] Effective C++, Item 18.
[11] Jack Reeves. ''(B)leading Edge: How About Namespaces?,'' C++ Report, April 1999.
[12] Jack Reeves. Personal communication.
Об авторе
Scott Meyers – известный авторитет по C++; он обеспечивает консультативные услуги клиентам по всему миру. Он автор Effective C++, Second Edition (Addison-Wesley, 1998), More Effective C++ (Addison-Wesley, 1996), и Effective C++ CD (Addison-Wesley, 1999). Скотт получил его Ph. D. в области Информатики в Университета Броуна (Brown University) в 1993.
Примечания. Первая, из перечисленных выше книг переведена на русский язык:
Скотт Мейерс. Эффективное использование C++. 50 рекомендаций по улучшению ваших программных проектов: Пер. с англ. – М.: ДМК, 2000. – 240 с.: ил.
Статья, на мой взгляд, показывает, что не все так гладко в чистых методах объектно-ориентированного проектирования, если приходится прибегать к ухищрениям, присущим чисто процедурному программированию. Конечно, эффект от использования будет очевиден лишь при разработке достаточно больших программных систем, когда программу приходится развивать и модифицировать, а не создавать заново. Но статья намекает, что чисто объектные языки и методы могут оказаться в этом случае весьма неудобными. А значит: прощай Java и C#? Или их ждет ревизия?