Как правильно структурировать ООП и многофайловые проекты?
Как начинающий программист, только сейчас изучающий основы ООП, я столкнулся со многими проблемами с базовой структурой включения в мои учебные программы. Я сам обучаюсь программированию, используя различные письменные и онлайн-ресурсы. Но вот моя проблема (ну, одна из них...):
С одной стороны, я понимаю важность абстракции, инкапсуляции и низкой степени связанности между классами , однако, с другой стороны, я очень старался структурировать свою программу и разработка моих классов таким образом, чтобы разные классы в разных файлах могли знать друг о друге .
Конечно, это моя серьезная проблема, которая привела к неряшливому, хакерскому коду, который работает только так, как я хочу, после того, как я выбросил все основные принципы ООП и начал заполнять свой код глобальными переменными, предварительными объявлениями всего. везде, и сделать членов класса общедоступными.
Проще говоря:Мое программирование - беспорядок... C++ - мой первый язык программирования, и даже когда я изо всех сил стараюсь проектировать/писать объектно-ориентированным способом, я получаю уродливый беспорядок файлов, #включая все почти в каждом файл и странная смесь процедурного и спагетти-кода ООП, которая редко работает!
Я самопровозглашенный -новичок в программировании, и я согласен с тем, что нужно время, чтобы научиться структурировать программу, но я почти в тупике! Я знаю, что моя проблема связана с тем, что я немного знаю об ООП. Я знаю, что хочу написать независимые классы, которые решают одну задачу. Но в то же время,Я не понимаю, как правильно предупредить каждый класс о существовании других частей программы. Это немного похоже на то, как если бы вы знали, какую пищу вам следует есть, но не знали бы, как пользоваться вилкой...
Это моя проблема в двух словах. И в дальнейшем ответить на некоторые более конкретные вопросы, которые у меня есть:
В многофайловом проекте С++ нормально/необходимо ли помещать основную функцию ()в собственный класс? Или это стандартная вещь, чтобы оставить ваш основной ()в глобальной области видимости?
В предыдущих процедурных программах, которые я писал на C++, нередки были переменные-константы или определения #в глобальной области видимости в верхней части файла main.cpp. Например, возможно, размеры экрана или другая полезная информация будут определены в начале программы. Что происходит в ООП? Следует ли полностью отказаться от этой практики? Или мне создать файл MAIN.H и #включить его во все остальные заголовки проекта? Я понятия не имею, что с этим делать...
Когда я писал свою первую ООП-программу среднего размера, моя работа резко остановилась, когда я начал пытаться написать класс StateMachine. Я хотел, чтобы класс StateMachine содержал все возможные состояния экрана, которые будет использовать программа. Однако возникла проблема, когда мой класс StateMachine, казалось, не знал о некоторых других моих классах State, хотя все они #были включены. Я видел, как раньше люди делали предварительные объявления классов, нужно ли это? Должен ли я спамить предварительные объявления классов повсюду или это запах кода?
Наконец, имеет ли значение порядок #включения и прямого объявления команд?
Я знаю, что это, вероятно, очень простой вопрос, но это то, что доставило мне очень много времени при переходе от однофайловых -процедурных программ на C++ для начинающих к многофайловому -ООП-программированию.Есть ли какое-то общее правило для структурирования ваших программ, чтобы все просто работало? Я использовал охранники включения, так есть ли причина, по которой нельзя просто #включить каждый заголовок в каждый исходный файл? Должен ли я иметь файл common.h, который #включен в каждый заголовочный файл для каждого класса?
Я очень ценю любую помощь/совет, которые может дать мне сообщество. Я знаю, что это простое, но важное препятствие для меня, прежде чем я смогу начать развивать свои навыки ООП. Я пытался вбить в свой мозг важность разделения классов друг от друга до такой степени, что я не уверен, как на самом деле настроить свои классы/файлы таким образом, чтобы они могли действительно взаимодействовать друг с другом! Большое спасибо за помощь!