Возможно, вас заинтересовала презентация, которую я дал ACCU '09 - «Adopting Model-View-Controller in Cocoa and Objective-C».
С чего начать? С контроллером ? Это, кажется, делает для меня , но как это началось ?
Создайте новый проект приложения Cocoa, и вы увидите, что уже есть класс контроллера, предоставляемый шаблоном - это класс делегата приложения. Теперь посмотрите в MainMenu.xib. Есть экземпляр делегата приложения, и он подключен к выходу delegate объекта «Файл» владельца. В этом случае NSApplication является владельцем файла; это то, что нужно MainMenu для распаковки. Так что это действительно делегат приложения.
Это означает, что у нас есть что-то, что является объектом контроллера, может разговаривать с экземпляром NSApplication и может иметь выходы для всех других объектов в XIB. Это отличное место для настройки начального состояния приложения - то есть для «точки входа» для вашего приложения. Фактически точкой входа должен быть метод -applicationDidFinishLaunching:. Это называется, как только приложение закончило все, что нужно для того, чтобы ваше приложение стало стабильным, работающим состоянием - другими словами, Cocoa рад, что он сделал то, что ему нужно, и все остальное зависит от вас.
-applicationDidFinishLaunching: - это место, где вы хотите создать или восстановить исходную модель, представляющую собой состояние приложения (вы также можете думать о нем как о представлении документа пользователя, если эта аналогия подходит для вашего приложения - документ основанные на приложениях, являются лишь немного более сложными, чем стандартные) и сообщают View, как представлять вещи пользователю. Во многих приложениях вам не нужно загружать всю модель при запуске приложения; для начала он может быть медленным и использовать больше памяти, чем вам нужно, а во-вторых, первый вид, вероятно, не отображает каждый бит о модели. Поэтому вы просто загружаете нужные вам биты, чтобы показать пользователю, что происходит; вы контролируете взаимодействие между представлением и моделью.
Если вам нужно отобразить другую информацию в другом представлении - например, если ваш основной вид является основным видом, и вам нужно показать подробный редактор - тогда, когда пользователь скажет вам, что они хотят сделать, вам нужно установить это выше. Они расскажут вам, выполнив какое-то действие, с которым вы могли бы справиться в делетете приложения. Затем вы создаете новый контроллер для поддержки нового представления и рассказываете, где получить требуемую информацию о модели. Вы можете удерживать другие объекты View в отдельном XIB, поэтому они загружаются только тогда, когда они нужны.
Как бы настроить игровой мир? I В настоящее время используются два массива, один для мир (Стены, Этажи, Двери, Вода, Лава и т. Д.), И один для предметов (я добавлю третий для символов). Карта (a .plist) загружена , а затем объекты созданы и добавлены в массив, к которому принадлежит . Куда идут массивы? В прототипе они также являются частью вида, поэтому, я думаю, вы могли бы сказать, что я объединил два (вид и контроллер) вместе. Будет ли объект карты создан для каждой карты? Был бы объект Maps, который содержит все карты ?
Мы можем решить, какие объекты мы моделируем, анализируя ваше утверждение выше - вы можете не осознавать этого, но вы набросали спецификацию :-). Там есть мир, который содержит стены, двери и т. Д., Поэтому мы знаем, что нам нужны объекты для них, и что они должны принадлежать объекту World. Но у нас также есть предметы и персонажи - как они взаимодействуют с миром? Может ли место содержать воду и характер? Если это так, возможно, мир состоит из локаций, и каждое местоположение может иметь стену или дверь или что-то еще, а также может содержать предметы и символы. Обратите внимание: если я пишу его так, кажется, что элемент принадлежит местоположению, а не местоположению элемента. Я бы сказал, что «у кота есть кошка», а не «у кота есть под ним».
Так что просто подумайте о том, что вы хотите, чтобы ваш игровой мир представлял, и о взаимоотношениях между вещами в игре. Это называется доменное моделирование, потому что вы описываете вещи в игровом мире, а не пытаетесь описать вещи в мире программного обеспечения. Если это поможет, запишите несколько предложений, описывающих мир игр, и найдите глаголы и существительные, как это было в последнем абзаце.
Теперь некоторые из ваших существительных станут объектами в программном обеспечении, некоторые станут атрибутами других объектов. Глаголы будут действиями (т. Е. Методами). Но в любом случае, будет легче подумать, если вы сначала подумаете над тем, что вы пытаетесь моделировать, а не прыгаете прямо к программному обеспечению.
Как все это работает вместе? Игрок нажимает клавишу, которая перемещает символ в игре. Вид будет обрабатывать вход, правильно? Был бы вы отправите это контроллеру, который будет проверять все (стены, монстров и т. Д.) На карте/другие массивы, а затем вернуть результат? Или вы отправите его игроку, который пойдет на контроллер, который выполнит все проверки и , а затем вернет результат?
Мне нравится следить за политикой «рассказывать, не спрашивать», в которой говорится, что вы приказываете объекту что-то делать, а не просите его предоставить вам информацию для принятия решения. Таким образом, если поведение изменяется, вам нужно только изменить объект, который будет указан. Что это означает для вашего примера, так это то, что представление обрабатывает событие нажатия клавиши (это происходит потому, что они обрабатываются NSControl), и он сообщает контроллеру, что это событие произошло. Предположим, что View получает нажатие «стрелка влево», и контроллер решает, что игрок должен двигаться влево. Я просто сказал бы игроку «двигаться влево» и позволить игроку разобраться, что происходит, когда движение влево означает натыкаться на стену или монстра.
Чтобы объяснить, почему я хочу сделать это так, представьте, что вы добавляете в игру 1.1 возможность плавать игроком. Теперь у игрока есть свойство ableToSwim, поэтому вам нужно сменить игрока. Если вы говорите игроку двигаться влево, то вы обновляете игрока, чтобы знать, что перемещается по воде, в зависимости от того, могут ли они плавать. Если вместо этого Контролер попросит игрока о перемещении налево и примет решение, то Контролер должен знать, чтобы спросить о возможности плавать, и ему нужно знать, что это означает возле воды. Как и любой другой объект контроллера в игре, который может взаимодействовать с игроком, как и контроллер в игре для iPhone ;-).
Я добавляю 300 бонусов. Я хочу проклятый ответ. – Sneakyness
Если вам нужно, чтобы я что-то уточнил, или вам нужно больше деталей, просто дайте мне знать прямо здесь, я более чем готов. – Sneakyness
Извините, что дал первый ответ, я не имел много времени, но думал, что презентация может помочь :-) – 2009-07-28 21:05:17