ООП — Я слишком усложняю вещи?
Я смотрел на некоторые из моих проектов и сравнивал их с вещами, которые я видел на github, и я чувствую, что я слишком обдумываю вещи. Мне нравится ООП, но я чувствую, что делаю слишком много файлов, слишком много классов.
Например, в небольшом проекте, в котором у меня была игра в шашки, у меня было так много файлов, что, возможно, все они помещались в один файл / класс. Как я узнаю, когда я обдумал свои решения? Вот как выглядят некоторые из моих файлов;
|src
| |- player.cpp
| |- piece.cpp
| |- color.cpp
| |- ...
И, конечно же, есть еще много файлов, которые будут иметь дело с такими вещами, как правила, настройки игры, графический интерфейс и т. Д. Но в этом коротком примере вы можете увидеть, как мои проекты могут и станут очень большими. Это обычное дело, писать вещи таким образом? Или я должен просто написать player.cpp файл, который содержит несколько классов, которые, в данном случае, связаны между собой и будут содержать данные частей / цвета / короля и т. д.
Решение
Да, распространение кода на несколько файлов является хорошей практикой, поскольку это делает ваш проект ремонтопригодны.
Я вижу ваши опасения по поводу небольшого проекта (стоит ли это накладных расходов?), Но в действительно больших проектах, если вы не сделаете это таким образом, у вас останутся люди, навсегда прокручивающие большой файл и использующие поиск. через файл, чтобы узнать, что они ищут.
Старайтесь, чтобы ваши файлы были компактными, и один класс на файл, где каждый класс надежен и его цель ясна.
Иногда мы пишем функции в файлы. Было бы неразумно иметь файл для каждой маленькой встроенной функции, это увеличит количество файлов без причины. Было бы лучше иметь семейство функций внутри файла (например, функции, связанные с печатью).
В конце концов, это, вероятно, основано на мнении, что является идеальным балансом между размером и количеством файлов, но я надеюсь, что я ясно дал понять.
Другие решения
На самом деле вы задаете два отдельных вопроса: «какова хорошая гранулярность для разделения функциональности на классы» и «какова хорошая практика для организации структуры файлов проекта». Оба довольно широкие.
Ответ на первый, вероятно, будет следовать одной идиомы ответственности. Вторым ответом было бы сделать структуру папок похожей на структуру пространства имен (как, например, в boost). Ваш текущий подход с хранением всего в src папка не подходит для C ++, потому что это приведет к более длинным именам файлов, чтобы предотвратить конфликт имен, когда классы с одинаковыми именами появляются в разных пространствах имен. Более крупные проекты, как правило, имеют слишком много файлов, так как для одного класса потребуется 4-5 файлов. И это приводит к еще одному вопросу выбора подходящей гранулярности для проектов …
Люди часто беспокоятся о «слишком большом количестве классов» или «слишком большом количестве файлов», но это в значительной степени исторический перенос. 40 лет назад, когда мы писали программы на перфокартах и должны были нести большие лотки и коробки с ними (а не бросать их!), Это, безусловно, было проблемой. 35 лет назад, когда самый большой жесткий диск, который вы могли получить для ПК, был 33 МБ, это было проблемой. Сегодня, когда вы не планируете покупать ПК с менее чем 512 ГБ SSD и иметь доступ к терабайту и петабайту онлайн-хранилища, количество файлов и количество байтов, занимаемых программами, по существу несущественны для процесса разработки.
Для нас, людей, это означает, что мы должны использовать это изобилие возможностей для улучшения других аспектов нашего кода. Если больше файлов поможет вам лучше понять код, используйте больше файлов. Если более длинные имена файлов помогают лучше понять код, используйте более длинные имена файлов. Если следование правилу типа «один файл .cpp и один файл .h на класс» помогает людям поддерживать кодовую базу, тогда следуйте этому правилу. Главное — сосредоточиться на действительно важных вопросах, таких как «что делает этот код более понятным, понятным и понятным для меня и моей команды?»
Другой способ подойти к этому — спросить, является ли «количество файлов» полезным показателем для определения того, поддерживается ли код? Хотя число, которое явно слишком мало для приложения, будет относиться к делу, я не смог бы сказать вам, было ли 10, 100 или 1000 подходящим числом (по крайней мере, не зная количества классов, которые они содержат.) Поэтому оно не представляется полезным показателем.
Означает ли это, что в программе должно быть 1000 файлов, собранных в одну папку, скомпилированных и связанных в одну библиотеку или исполняемый файл? Это зависит, но кажется, что 1000 классов в одном и том же пространстве имен будут немного переполнены, и результирующая программа может быть слишком монолитной. В какой-то момент вы, вероятно, захотите реорганизовать архитектуру в меньшие, более сплоченные пакеты, каждый с соответствующей сферой ответственности. Конечно, никто не может сказать вам, что это за магическое число, так как оно полностью зависит от приложения. Но дело не в количестве файлов, которое определяет решение, а в том, что файлы должны быть связаны друг с другом логически или архитектурно.
Каждый класс должен быть спроектирован и запрограммирован для выполнения одной и только одной вещи
Поскольку каждый класс предназначен только для одной ответственности, многие классы используются для создания всего приложения.
detector