ВУЗ:
Составители:
Рубрика:
16
включать только методы. Поля данных класса должны быть скрыты-
ми.
• Не следует определять методы типа get/set для всех скрытых по-
лей класса — это все равно, что открыть к ним доступ, только
более сложным способом. Поля класса вводятся только для того,
чтобы реализовать свойства класса, представленные в его интер-
фейсе с помощью методов.
• Не нужно расширять интерфейс класса без необходимости, «на
всякий случай», поскольку увеличение количества методов ведет
к трудности понимания класса пользователем. В идеале интерфейс
должен быть полным, то есть предоставлять возможность выпол-
нить любые разумные действия с классом, и минимальным — без
дублирования и пересечения возможностей методов.
• В виде методов рекомендуется определять только действия, реа-
лизующие свойства класса. Если какое-либо действие можно реа-
лизовать, не обращаясь к скрытым полям класса, его нет необхо-
димости описывать как метод; лучше описать его как обычную
функцию, поместив ее в общее с классом пространство имен. Если
функция выполняет действие, не являющееся свойством класса, но
нуждается в доступе к его скрытым полям, ее следует объявить
как дружественную. Но в общем случае дружественных функций и
классов надо избегать, поскольку главной идеей ООП является
минимизация связей между инкапсулированными классами.
• Для увеличения производительности программы наиболее часто вы-
зываемые методы можно объявить как встроенные (inline). В ос-
новном это касается коротких методов, тело которых оказывается
меньше размера кода, генерируемого для их вызова. Кроме уско-
рения программы за счет исключения вызовов, это дает возмож-
ность компилятору производить более полную оптимизацию. Однако
необходимо учитывать, что директива inline носит для компиля-
тора рекомендательный характер.
• Конструкторы и деструкторы делать встраиваемыми не рекоменду-
ется, поскольку в них фактически присутствует код, помещаемый
компилятором, размер этого кода может быть весьма значительным
(например, в конструкторе производного класса должны быть вы-
званы конструкторы всех базовых и вложенных классов).
• Перегруженные операции класса должны иметь интуитивно понятный
общепринятый смысл (например, не следует заставлять операцию +
выполнять что-либо, кроме сложения или добавления).
• Если какая-либо операция перегружена, следует, если возможно,
перегрузить и аналогичные операции, например, +, += и ++ (ком-
пилятор этого автоматически не сделает). При этом операции
должны иметь ту же семантику, что и их стандартные аналоги.
• И конструктор копирования, и операция присваивания, создавае-
мые по умолчанию, выполняют поэлементное копирование из облас-
ти-источника в область-приемник. Если объект содержит указате-
ли, это приведет к тому, что после копирования два соответст-
вующих указателя разных объектов будут ссылаться на одну и ту
же область памяти. При уничтожении первого из объектов эта па-
мять будет освобождена, а повторная попытка освободить ее при
уничтожении второго объекта приведет к неопределенному поведе-
нию программы. Поэтому для классов, содержащих поля-указатели,
16 включать только методы. Поля данных класса должны быть скрыты- ми. • Не следует определять методы типа get/set для всех скрытых по- лей класса — это все равно, что открыть к ним доступ, только более сложным способом. Поля класса вводятся только для того, чтобы реализовать свойства класса, представленные в его интер- фейсе с помощью методов. • Не нужно расширять интерфейс класса без необходимости, «на всякий случай», поскольку увеличение количества методов ведет к трудности понимания класса пользователем. В идеале интерфейс должен быть полным, то есть предоставлять возможность выпол- нить любые разумные действия с классом, и минимальным — без дублирования и пересечения возможностей методов. • В виде методов рекомендуется определять только действия, реа- лизующие свойства класса. Если какое-либо действие можно реа- лизовать, не обращаясь к скрытым полям класса, его нет необхо- димости описывать как метод; лучше описать его как обычную функцию, поместив ее в общее с классом пространство имен. Если функция выполняет действие, не являющееся свойством класса, но нуждается в доступе к его скрытым полям, ее следует объявить как дружественную. Но в общем случае дружественных функций и классов надо избегать, поскольку главной идеей ООП является минимизация связей между инкапсулированными классами. • Для увеличения производительности программы наиболее часто вы- зываемые методы можно объявить как встроенные (inline). В ос- новном это касается коротких методов, тело которых оказывается меньше размера кода, генерируемого для их вызова. Кроме уско- рения программы за счет исключения вызовов, это дает возмож- ность компилятору производить более полную оптимизацию. Однако необходимо учитывать, что директива inline носит для компиля- тора рекомендательный характер. • Конструкторы и деструкторы делать встраиваемыми не рекоменду- ется, поскольку в них фактически присутствует код, помещаемый компилятором, размер этого кода может быть весьма значительным (например, в конструкторе производного класса должны быть вы- званы конструкторы всех базовых и вложенных классов). • Перегруженные операции класса должны иметь интуитивно понятный общепринятый смысл (например, не следует заставлять операцию + выполнять что-либо, кроме сложения или добавления). • Если какая-либо операция перегружена, следует, если возможно, перегрузить и аналогичные операции, например, +, += и ++ (ком- пилятор этого автоматически не сделает). При этом операции должны иметь ту же семантику, что и их стандартные аналоги. • И конструктор копирования, и операция присваивания, создавае- мые по умолчанию, выполняют поэлементное копирование из облас- ти-источника в область-приемник. Если объект содержит указате- ли, это приведет к тому, что после копирования два соответст- вующих указателя разных объектов будут ссылаться на одну и ту же область памяти. При уничтожении первого из объектов эта па- мять будет освобождена, а повторная попытка освободить ее при уничтожении второго объекта приведет к неопределенному поведе- нию программы. Поэтому для классов, содержащих поля-указатели,
Страницы
- « первая
- ‹ предыдущая
- …
- 14
- 15
- 16
- 17
- 18
- …
- следующая ›
- последняя »