Алгоритмические языки и программирование. Викентьева О.Л - 16 стр.

UptoLike

16
включать только методы. Поля данных класса должны быть скрыты-
ми.
Не следует определять методы типа get/set для всех скрытых по-
лей классаэто все равно, что открыть к ним доступ, только
более сложным способом. Поля класса вводятся только для того,
чтобы реализовать свойства класса, представленные в его интер-
фейсе с помощью методов.
Не нужно расширять интерфейс класса без необходимости, «на
всякий случай», поскольку увеличение количества методов ведет
к трудности понимания класса пользователем. В идеале интерфейс
должен быть полным, то есть предоставлять возможность выпол-
нить любые разумные действия с классом, и минимальнымбез
дублирования и пересечения возможностей методов.
В виде методов рекомендуется определять только действия, реа-
лизующие свойства класса. Если какое-либо действие можно реа-
лизовать, не обращаясь к скрытым полям класса, его нет необхо-
димости описывать как метод; лучше описать его как обычную
функцию, поместив ее в общее с классом пространство имен. Если
функция выполняет действие, не являющееся свойством класса, но
нуждается в доступе к его скрытым полям, ее следует объявить
как дружественную. Но в общем случае дружественных функций и
классов надо избегать, поскольку главной идеей ООП является
минимизация связей между инкапсулированными классами.
Для увеличения производительности программы наиболее часто вы-
зываемые методы можно объявить как встроенные (inline). В ос-
новном это касается коротких методов, тело которых оказывается
меньше размера кода, генерируемого для их вызова. Кроме уско-
рения программы за счет исключения вызовов, это дает возмож-
ность компилятору производить более полную оптимизацию. Однако
необходимо учитывать, что директива inline носит для компиля-
тора рекомендательный характер.
Конструкторы и деструкторы делать встраиваемыми не рекоменду-
ется, поскольку в них фактически присутствует код, помещаемый
компилятором, размер этого кода может быть весьма значительным
(например, в конструкторе производного класса должны быть вы-
званы конструкторы всех базовых и вложенных классов).
Перегруженные операции класса должны иметь интуитивно понятный
общепринятый смысл (например, не следует заставлять операцию +
выполнять что-либо, кроме сложения или добавления).
Если какая-либо операция перегружена, следует, если возможно,
перегрузить и аналогичные операции, например, +, += и ++ (ком-
пилятор этого автоматически не сделает). При этом операции
должны иметь ту же семантику, что и их стандартные аналоги.
И конструктор копирования, и операция присваивания, создавае-
мые по умолчанию, выполняют поэлементное копирование из облас-
ти-источника в область-приемник. Если объект содержит указате-
ли, это приведет к тому, что после копирования два соответст-
вующих указателя разных объектов будут ссылаться на одну и ту
же область памяти. При уничтожении первого из объектов эта па-
мять будет освобождена, а повторная попытка освободить ее при
уничтожении второго объекта приведет к неопределенному поведе-
нию программы. Поэтому для классов, содержащих поля-указатели,
                                                                16

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