ООП: Разработка системы меню

Question

В настоящее время я пытаюсь создать систему меню для игры и не могу найти какой-либо действительно разумный способ сделать это. Есть несколько экранов меню, каждый из которых нетривиален, поэтому я хотел бы сохранить их как отдельные классы. Основная проблема, с которой я сталкиваюсь, - передача управления между этими экранами меню.

Я пытался создать каждый из экранов как одиночный и вызывать один экран непосредственно из другого, т.е. что-то вроде [[MainMenu instance] display] в Objective C. Это немного грязно, потому что (1) я должен написать шаблонный код для каждого экрана меню и (2) классы становятся зависимыми друг от друга, иногда мне приходится кодировать вокруг круговых зависимостей и т. д.

Я думал о том, чтобы сделать классы полностью статичными, чтобы обойти управление экземплярами (что в данном случае немного лишнее, поскольку на каждом экране действительно только один экземпляр). Но это также выглядит довольно уродливо, особенно если Objective C вынуждена «подделывать» переменные класса, объявляя их static.

Затем я подумал о каком-то классе «manager», который создавал бы экземпляры и передавал управление, но я не уверен, что введение дополнительного класса решит проблему, особенно если этот класс должен называться Manager: -)

Должен заметить, что у меня есть работающая система, просто она не очень приятная. Под этим я подразумеваю, что происходит небольшое дублирование кода, если я не буду осторожен, вещь может зависнуть и так далее. Есть идеи? Я знаю, что это недостаточно точно, так что обсуждение, вероятно, будет скорее мозговым штурмом, но в любом случае меня интересуют идеи, даже если они не решают мою проблему напрямую.

Обновление: спасибо всем за идеи. Что я сделал в итоге:

Я переработал содержимое меню (кнопки, графику и т. Д.), Чтобы оно подходило под один интерфейс под названием ScreenView. Это общий интерфейс, который выглядит следующим образом:

@protocol ScreenView

- (void) draw;
- (BOOL) handlesPoint: (CGPoint) p;

- (void) appearWithAnimation;
- (void) disappearWithAnimation;
- (BOOL) hasFinishedAnimating;

@optional

- (void) fingerDown;
- (void) fingerUp;

@end

Благодаря этому протоколу я смог отбросить все определенные экраны меню и создать общий экран меню, который отображает список подпредставлений и обрабатывает все презентации, такие как рисование, переходы, события и тому подобное. Этот общий экран меню не имеет большого подкласса, потому что большинство экранов меню просто отображают список подпредставлений. Это будет V в MVC.

Затем я также создал класс контроллера, который обрабатывает все события для определенного экрана меню. (Очевидно, C в MVC.) Класс корневого контроллера обрабатывает управление экземплярами, переходы между меню и некоторые другие мелочи. Большинство экранов меню получают настраиваемый подкласс контроллера, который обрабатывает события от кнопок и других подпредставлений.

Количество классов возросло, но код намного чище, не повторяется и менее подвержен ошибкам. Управление экземплярами все еще не идеально, но я довольно доволен дизайном. Еще раз спасибо всем, кто ответил.

Answer 1

Один из приемов, которым я научился приличному дизайну, всегда отделяет ваши данные от вашего кода. Это сделает чудеса для вашей конкретной проблемы.

Под этим я подразумеваю, что пункты меню (строки) и связи между меню должны храниться где-либо в массиве или в отдельном файле (и считываться в массив).

Затем вы используете этот массив для создания экземпляров всех ваших классов меню.

Как только вы перекодируете его для работы таким образом (я сделал это с меню), весь ваш код станет на свои места, вы также исключите - 90% вашего кода меню (каждое меню больше не будет это собственный класс, точно такой же класс, созданный со своими уникальными данными.

Назначение пунктов меню также сохраняется в «данных» (как указатели методов или экземпляры классов).

Answer 2

Я думаю, что класс MenuManager был бы подходящим вариантом. У вас будет один базовый класс Menu, из которого происходят все экраны меню, и менеджер будет иметь указатель на текущий активный экран меню. Он также может, например, отслеживать предыдущие экраны меню для простого использования кнопок возврата на экранах меню при произвольных вызовах экрана меню. Возможно, просто используйте для этого std :: vector, чтобы вам не приходилось заново создавать предыдущие экраны меню при возврате (это также предотвратит потерю введенной информации, как в меню «Параметры» с подменю «Дополнительно»).

Answer 3

Помещение всего содержимого меню в словарь, выгрузка в список и чтение каждого из них по мере необходимости на экранах меню, вероятно, является самым простым путем, но, честно говоря, вы должны рассмотреть возможность использования более MVC-ориентированного подхода к решению проблемы. проблема. Экраны должны быть предназначены для представления данных, а не для их хранения. Если вы обеспечите чистое отделение данных от представлений, проблема решится сама собой.