Класс должен обрабатывать один аспект системы, который будет построен в контексте выбранного дизайна.
Интерфейс должен быть минимальным (без сахара и функций удобства). Это означает, что если вы можете реализовать прецедент с подмножеством интерфейса, функция, которая понимала бы, что используемый случай не должен быть функцией-членом.
Пример:
class Foo
{
public:
void TurnLeft(uint32_t radians);
void TurnRight(uint32_t radians);
// Bad - interface not minimal and this is a convenience function.
void TurnLeftThenRight(uint32_t radiansLeft, uint32_t radiansRight);
};
Класс должен быть абстракцией сортов. Это означает, что он не должен требовать всех деталей реализации класса и полного понимания всех его требований, используемых для его реализации при использовании класса. Правильное использование класса должно быть проще, чем его реализация.
Класс не должен просто «экспортировать» все состояние, которое он инкапсулирует с помощью свойств, поскольку тогда это не будет абстракция, а просто группа данных.
Для практического использования класса он сделает предположения о контексте, в котором он находится, и об общей архитектуре. (Threading, политики использования памяти, использование стека (рекурсии да/нет), исключения да/нет, ...). Попытка рассчитать все это из класса или превратить его в монстра с несколькими параметрами шаблона обычно не является оптимальной стратегией для программирования приложений.
Реализация класса должна иметь единичный тест и некоторую форму документации о его ограничениях и допущениях.
Методы классов должны быть реализованы в защитном стиле. То есть перед фазой оптимизации и настройки класс должен проверять входные аргументы и, если возможно, также свои выходные аргументы и указывать на его ограничения.
Я хотел бы идентифицировать все мои объекты, прежде чем начинать кодирование, а не во время. –
Определение до и во время создания тех же результатов. Вам просто нужно решить, что представляет ваш объект и какие его свойства нужно определить. Планирование - это замечательно, но вы всегда сможете добавлять и удалять функциональность по ходу дела. Поэтому вы задаете широкий и очень индивидуалистический вопрос. – iore
Я не согласен с вами в том, что функциональность изменится по мере моего кода. Тем не менее, мы можем ограничить количество изменений, ошибок и улучшить общее качество кода, если мы определим все, что мы можем перед вами. _Вы гораздо чаще избегаете грабежа банка, если вы планируете свой гейст, чем если вы хотите импровизировать, когда идете ._ –