Classes and class hierarchies
C.109
Если дескриптор ресурса имеет семантику указателя, предоставьте `*` и `->`
Причина
Вот что ожидается от указателей. Знакомство.
Пример
???
Применение
???
C.lambdas: Function objects and lambdas
Объект функции — это объект, предоставляющий перегруженный () так что вы можете его вызвать. Выражение lambda (в разговорной речи часто сокращённо «lambda») — это нотация для генерирования объекта функции. Объекты функций должны быть дешёвыми для копирования (и поэтому переданы по значению).
Резюме:
- F.10: Если операция может быть повторно использована, дайте ей имя
- F.11: Используйте безымянную lambda если вам нужен простой объект функции только в одном месте
- F.50: Используйте lambda когда функция не подойдёт (для захвата локальных переменных или написания локальной функции)
- F.52: Предпочитайте захват по ссылке в lambda'ах, которые будут использованы локально, включая передачу алгоритмам
- F.53: Избегайте захвата по ссылке в lambda'ах, которые будут использованы нелокально, включая возвращение, сохранение на heap или передачу другому потоку
- ES.28: Используйте lambda'ы для сложной инициализации, особенно
constпеременных
C.hier: Class hierarchies (OOP)
Иерархия классов конструируется для представления набора иерархически организованных концепций (только). Обычно базовые классы действуют как интерфейсы. Существует два основных использования иерархий, часто называемых наследованием реализации и наследованием интерфейса.
Резюме правил иерархии классов:
- C.120: Используйте иерархии классов для представления концепций с присущей иерархической структурой (только)
- C.121: Если базовый класс используется как интерфейс, сделайте его чистым абстрактным классом
- C.122: Используйте абстрактные классы как интерфейсы когда полное разделение интерфейса и реализации необходимо
Правила проектирования классов в иерархии резюме:
- C.126: Абстрактный класс обычно не нуждается в пользовательском конструкторе
- C.127: Класс с виртуальной функцией должен иметь виртуальный или защищённый деструктор
- C.128: Виртуальные функции должны указывать ровно один из
virtual,overrideилиfinal - C.129: При проектировании иерархии классов различайте наследование реализации и наследование интерфейса
- C.130: Для создания глубоких копий полиморфных классов предпочитайте виртуальную функцию
cloneвместо публичного конструктора копирования/присваивания - C.131: Избегайте тривиальных getters и setters
- C.132: Не делайте функцию
virtualбез причины - C.133: Избегайте
protectedданных - C.134: Убедитесь, что все non-
constэлементы данных имеют одинаковый уровень доступа - C.135: Используйте множественное наследование для представления нескольких отличных интерфейсов
- C.136: Используйте множественное наследование для представления объединения атрибутов реализации
- C.137: Используйте
virtualбазы для избежания чрезмерно общих базовых классов - C.138: Создайте набор перегрузок для производного класса и его базовых классов с
using - C.139: Используйте
finalна классах редко - C.140: Не предоставляйте различные аргументы по умолчанию для виртуальной функции и переопределяющей функции
Резюме правил доступа к объектам в иерархии:
- C.145: Получайте доступ к полиморфным объектам через указатели и ссылки
- C.146: Используйте
dynamic_castгде навигация иерархии классов неизбежна - C.147: Используйте
dynamic_castк типу ссылки когда неспособность найти требуемый класс рассматривается как ошибка - C.148: Используйте
dynamic_castк типу указателя когда неспособность найти требуемый класс рассматривается как действительная альтернатива - C.149: Используйте
unique_ptrилиshared_ptrдля избежания забыванияdeleteобъектов, созданных с помощьюnew - C.150: Используйте
make_unique()для конструирования объектов, на которые владеютunique_ptrы - C.151: Используйте
make_shared()для конструирования объектов, на которые владеютshared_ptrы - C.152: Никогда не присваивайте указатель на массив производного класса указателю на базовый класс
- C.153: Предпочитайте виртуальную функцию кастингу