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