C++: читать книгу онлайн полностью и бесплатно

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

Понятие не существует в пустоте, всегда есть группы связанных между собой понятий. Организовать в программе взаимоотношения между классами, то есть определить точную взаимосвязь между различными понятиями, часто труднее, чем сначала спланировать отдельные классы. Лучше, чтобы не получилось неразберихи, когда каждый класс (понятие) зависит от всех остальных. Рассмотрим два класса, A и B. Взаимосвязи вроде «A вызывает функции из B», «A создает объекты B» и «A имеет члены B» редко вызывают большие сложности, а взаимосвязь вроде «A использует данные из B» обычно можно исключить (просто не используйте открытые данные-члены). Неприятными, как правило, являются взаимосвязи, которые по своей природе имеют вид «A есть B и ...».

Одним из наиболее мощных интеллектуальных средств, позволяющих преодолевать сложность, является иерархическое упорядочение, то есть организация связанных между собой понятий в древовидную структуру с самым общим понятием в корне. В С++ такие структуры представляются производными классами. Часто можно организовать программу как множество деревьев (лес?). То есть, программист задает множество базовых классов, каждый из которых имеет свое собственное множество производных классов. Для определения набора действий для самой общей интерпретации понятия (базового класса) часто можно использовать виртуальные функции (#7.2.8). Интерпретацию этих действий можно, в случае необходимости, усовершенствовать для отдельных специальных классов (производных классов).

Естественно, такая организация имеет свои ограничения. В частности, множество понятий иногда лучше организуется в виде ациклического графа, в котором понятие может непосредственно зависеть от более чем одного другого понятия, например, «A есть B и C и ...». В С++ нет непосредственной поддержки этого, но подобные связи можно представить, немного потеряв в элегантности и проделав малость дополнительной работы (#7.2.5).

Иногда для организации понятий некоторой программы оказывается непригоден даже ациклический граф, некоторые понятия оказываются взаимозависимыми по своей природе. Если множество взаимозависимых классов настолько мало, что его легко себе представить, то циклические зависимости не должны вызвать сложностей. Для представления множеств взаимозависимых классов с С++ можно использовать идею friend классов (#5.4.1).

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

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

Вопрос «Как пишут хорошие программы на С++» очень похож на вопрос «Как пишут хорошую английскую прозу?» Есть два вида ответов: «Знайте, что вы хотите сказать» и «Практикуйтесь. Подражайте хорошему языку.» Оба совета оказываются подходящими к С++ в той же мере, сколь и для английского – и им столь же трудно следовать.

Правила Правой Руки*

Здесь приводится набор правил, которых вам хорошо бы придерживаться изучая С++. Когда вы станете более опытны, вы можете превратить их в то, что будет подходить для вашего рода деятельности и вашего стиля программирования. Они умышлено сделаны очень простыми, поэтому подробности в них опущены. Не воспринимайте их чересчур буквально. Написание хороших программ требует ума, вкуса и терпения. Вы не собираетесь как следует понять это с самого начала, поэкспериментируйте!

1. Когда вы программируете, вы создаете конкретное представление идей вашего решения некоторой задачи. Пусть структура отражает эти идеи настолько явно, насколько это возможно:

a) Если вы считаете «это» отдельным понятием, сделайте его классом.

b) Если вы считаете «это» отдельным объектом, сделайте его объектом некоторого класса.

c) Если два класса имеют общим нечто существенное, сделайте его базовым классом. Почти все классы в вашей программе будут иметь нечто общее. Заведите (почти) универсальный базовый класс, и разработайте его наиболее тщательно.

2. Когда вы определяете класс, который не реализует некоторый математический объект, вроде матрицы или комплексного числа, или тип низкого уровня, вроде связанного списка, то:

a) Не используйте глобальные данные.

b) Не используйте глобальные функции (не члены).

c) Не используйте открытые данные-члены.

d) Не используйте друзей, кроме как для того, чтобы избежать [a], [b] или [c].

e) Не обращайтесь к данным-членам или другим объектам непосредственно.

f) Не помещайте в класс «поле типа», используйте виртуальные функции.

g) Не используйте inline-функции, кроме как средство существенной оптимизации.

Замечания для Программистов на C

Чем лучше кто-нибудь знает C, тем труднее окажется избежать писания на С++ в стиле C, теряя, тем самым, некоторые возможные выгоды С++. Поэтому проглядите, пожалуйста, раздел «Отличия от C» в справочном руководстве (#с.15). Там указываются области, в которых С++ позволяет делать что-то лучше, чем C. Макросы (#define) в С++ почти никогда не бывают необходимы, чтобы определять провозглашаемые константы, используйте const (#2.4.6) или enum (#2.4.7), и inline (#1.12) – чтобы избежать лишних расходов на вызов функции. Старайтесь описывать все функции и типы всех параметров – есть очень мало веских причин этого не делать. Аналогично, практически нет причин описывать локальную переменную не инициализируя ее, поскольку описание может появляться везде, где может стоять оператор, – не описывайте переменную, пока она вам не нужна. Не используйте malloc() – операция new (#3.2.6) делает ту же работу лучше. Многие объединения не нуждаются в имени – используйте безымянные объединения (#2.5.2).

Библиографические Ссылки

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

[1] A.V. Aho, J.E. Hopcroft, and J.D. Ulman: Data Structures and Algorithms. Addison-Wesley, Reading, Massachusetts. 1983.

[2] O-J. Dahl, B. Myrhaug, and K. Nygaard: SIMULA Common Base Language. Norwegian Computer Center S-22, Oslo, Norsay. 1970

[3] O-J. Dahl and C.A.R. Hoare: Hierarchical Program Construction in «Structured Programming.» Academic Press, New York. 1972. pp 174-220.

[4] A. Goldberg and D. Robson: SMALLTALK-80 The Language and Its Implementation. Addison-Wesley, Reading, Massachusetts. 1983.