- Должен ли я иметь один файл на класс? Должен ли я иметь одну папку на ветку наследования?
Благодаря индексаторам кода я часто забываю, как и где код на самом деле находится на диске.
Файл для каждого класса для меня не имеет смысла. Особенно в C ++ у меня много маленьких служебных классов.
Обычно: компонент - это каталог. Все компоненты живут под одним корнем. (Это более печальное следствие, что я должен использовать make как цепочку сборки. С лучшими системами сборки, такими как SCons , которые изначально поддерживают рекурсию, это не имеет значения.)
Я придерживаюсь общих принципов повторного использования, достаточности и сплоченности (согласно Booch ) для группировки классов. Часто бывает, что я помещаю код в разделяемую / статическую библиотеку, чтобы облегчить интеграцию в цепочку сборки, поэтому для группировки классов в компоненты / каталоги я использую принципы, очень похожие на те, которые используются для группировки методов в классах.
- Должна ли я иметь папку «include», содержащую мои файлы заголовков, или мои файлы заголовков должны находиться в той же папке, что и мои файлы .cpp / .c?
Лично я предпочитаю заголовки в одном каталоге с исходными файлами.
Заметным исключением являются открытые заголовки, которые определяют открытый интерфейс компонента. Те, что я положил в include / compname / sudbirectory: тогда легко увидеть, что изменение, которое я делаю / собираюсь зарегистрировать, повлияет на другие компоненты.
Очевидно, что другим компонентам разрешено включать только заголовки из подкаталога $ ROOT / compname / include / compname /. (Наличие compname / dir в include / make включает директивы include в других файлах, чтобы они выглядели как #include "compname/headername.h", что способствует удобочитаемости и предотвращает конфликты имен заголовков.)
- Я планирую регулярно добавлять больше классов (добавляя больше уровней в дерево наследования). На самом низком уровне дерева реализации, скорее всего, будут относительно не связаны, но все же будут переопределять те же виртуальные функции. Должны ли такие несвязанные реализации находиться в одной папке?
Наследование редко имеет отношение к физическому расположению файлов.
Базовые классы изменяются редко, поскольку они мало влияют на бизнес-логику. Классы высшего уровня - это то, где находится логика, и над ней будут работать многие люди в течение долгого времени. Таким образом, базовые классы, повторно используемые многими компонентами, заслуживают того, чтобы иметь свой собственный компонент. Просто убрать их с глаз долой.
Это приносит еще один важный момент. Сколько людей собирается работать над проектом? На одном человеке проекта вы можете делать почти все, что вы хотите, как вы хотите. В команде из 3+ человек компонент / модуль будет служить естественным контейнером для одного человека, который будет работать над ним независимо. Таким образом, проект формы может не зависеть от того, как выглядит иерархия классов - скорее места кода, над которыми будет работать большинство, должны быть достаточно изолированы друг от друга. И иерархия классов при необходимости должна быть приспособлена для этого: вам следует избегать случаев, когда один человек работает над базовым классом, а другой - над его потомком. Это тот случай, когда можно рассматривать агрегацию вместо наследования.