#c #class
#c #класс
Вопрос:
Мне действительно нравится кодирование, но в настоящее время каждый проект, который я начал, закончился рано из-за циклических зависимостей, которые действительно мешают мне и моей голове. У меня возникли проблемы, я пытаюсь создавать игры, однако из-за моей структуры классов я полагаюсь на некоторые циклические зависимости, которые в конечном итоге вызывают проблемы, которые почти всегда растут и выходят из-под моего контроля. Как я обычно это структурирую:
- игра класса
- класс GameContext
- окно класса
- класс GameContext
- класс EventManager
- класс GameContext
- class StateManager
- класс GameContext
- окно класса
- класс GameContext
Я использую это, так как мне иногда нужно получить доступ, например, к окну из EventManager. В конце концов, я всегда, кажется, теряю это. Есть ли лучший способ для чего-то подобного, который позволяет избежать циклических зависимостей? И если нет, то как вы на самом деле думаете, когда вам приходится иметь с ними дело? Я думал, что понял их, но явно нет.
То, что я пытаюсь заархивировать, — это класс «Контекста» центрального хранилища, к которому могут обращаться другие классы, но я не знаю, как избежать циклических зависимостей в таком случае.
Чтобы действительно показать, что я имею в виду, вы можете взглянуть на ЭТО, мою последнюю неудачную попытку. Проблема, с которой я сталкиваюсь с этой текущей структурой, похоже, связана с зависимостью между EventManager и GameStateManager, поскольку в EventManager я получаю сообщение об ошибке, когда GameStateID не определен.
Комментарии:
1. Я думаю, вам нужно попытаться выяснить, почему вам «нужно» получить доступ к окну из EventManager. В чем заключается работа EventManager? Зачем для этого нужно окно?
2. @ZongZhengLi Да, я бы предположил, что это тоже относится к этому. Хотя в настоящее время это слишком широко / неясно, IMO.
3. Это не предназначено для разработки кода, специально разработанного для игр, у меня просто есть игры в качестве темы, поскольку именно там я его использую и получаю проблемы. Это может быть rocketship, который содержит RocketContext, содержащий ExhaustManager, которому иногда нужно что-то из RocketContext.
4. @EdwinW. Я понимаю вашу проблему, но я думаю, что без четкой проблемы на ваш вопрос не будет ответа. Возможно, вы можете попытаться создать (минимальный!) пример из кода, который вы связали? Тогда вы, вероятно, получите ответ, адаптированный для этого конкретного случая, но, возможно, это поможет вам обобщить подход к другим случаям?
5. Например, если я нажал клавишу, окно должно стать полноэкранным.
Ответ №1:
Мне удалось разобраться в своей проблеме, и это было больше похоже на то, как я думал об этом, я думал, что хочу такую структуру:
- игра класса
- класс GameContext
- окно класса
- класс GameContext
- класс EventManager
- класс GameContext
- окно класса
- класс GameContext
Но на самом деле я хотел было:
- игра класса
- окно класса
- класс EventManager
- класс GameContext
Где каждый класс, кроме GameContext, содержит указатель на GameContext. Также одной из моих проблем было мое понимание прямого объявления, я не понимал их и смешивал и распространял их повсюду, потому что думал, что это волшебство.
Комментарии:
1. Обычно эти проблемы возникают, когда вы создаете классы без состояния или просто используете их как набор функций, вы можете захотеть взглянуть на эту статью: steve-yegge.blogspot.com.br/2006/03 /…
2. Что вы подразумеваете под «состоянием»?
3. Если все функции в классе могут быть извлечены и работать как свободные функции, то у вашего класса нет состояния, и он вообще не должен быть классом. Распространенный пример, который вы могли бы увидеть в Интернете, — это класс «Formatter», который будет содержать функцию для форматирования чего-либо.
4. Обычно говорят, когда имя класса заканчивается на «er», такие термины, как «Менеджер», «Контроллер» и т.д. … Очень расплывчаты. Другая статья ( yegor256.com/2015/03/09/objects-end-with-er.html ) Конечно, вы не должны слепо следовать этому правилу, но это помогает вам проанализировать, действительно ли вам нужен класс и его назначение.
5. @AlexandreBorela Ах, да, у него есть состояние, ничто в моей программе в настоящее время не имеет состояния, я бы не использовал его как класс, если бы в этом не было необходимости. Я думаю, что некоторые вещи в этой статье могут быть немного личными предпочтениями, но я согласен, что функции, которым действительно не нужно состояние, не должны быть классом.