Объектно-ориентированный дизайн - PullRequest
1 голос
/ 24 марта 2011

В настоящее время разрабатывается игра для консоли. На более позднем этапе разработаем его для интерфейса Windows.

Хотелось бы узнать о следующих вещах:
1. В настоящее время у меня есть несколько классов, которые содержат игровую логику. У меня также есть класс для управления всей игрой и класс, который управляет видом консоли, использующей игровой менеджер. Доступ к классу, управляющему представлением, осуществляется через класс Program (с void main)
Вопрос : Что касается модификаторов Access, которые я должен использовать для каждого из перечисленных классов (в общем), должен ли я использовать внутренний или публичный? Учтите, что я хочу, чтобы это подходило для любой последующей реализации без изменения кода логической части игры.

2.a. Как организовывать код в NameSpaces или Projects?
Должен ли я создать два пространства имен (проекта) в рамках одного решения: Один будет содержать логические классы игры, второй - класс программы и класс, который управляет видом для консоли?
и как должны быть теперь модификаторы доступа в соответствии с такой схемой?
Извините за длинную историю
Спасибо

Ответы [ 4 ]

2 голосов
/ 24 марта 2011

Я бы разделил сборки и создал одну сборку с «логикой просмотра», которая отображает ввод / вывод в выбранный вами пользовательский интерфейс (консоль, WinForms, WPF, XNA) и другую сборку, содержащую игровую логику.

Теперь для модификаторов доступа вашей игровой логики:

  1. Классы: Сделайте большинство из них внутренними, и только публично представляйте классы, к которым вам нужен доступ из вашего пользовательского интерфейса.

  2. Методы / свойства. Предоставляйте только те методы и свойства, которые вам действительно нужны, оставляйте их закрытыми до тех пор, пока другим классам не понадобится доступ, а затем делайте их внутренними / открытыми по мере необходимости.

0 голосов
/ 24 марта 2011

Лучшая практика гласит, что не ставьте свои уроки на общедоступные, если они не должны быть публичными.Похоже, что вы можете сойтись с тем, чтобы все отделить от основной вашей программы.

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

Вы, кажется, немного смущены пространствами имен и сборками (проектами), так что это может быть полезно для вас.http://msdn.microsoft.com/en-us/library/ms973231.aspx

0 голосов
/ 24 марта 2011

On 2: Вы можете поместить логику в новую папку в вашем проекте.Это автоматически создает новое пространство имен и избавляет вас от проблем, связанных с несколькими проектами и их зависимостями.

0 голосов
/ 24 марта 2011

У нас есть правило, согласно которому все средства доступа должны быть частными, а при необходимости - общими.Это просто для того, чтобы уменьшить беспорядок автозавершения в Visual Studio.

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

В зависимости от сложности, я бы добавил проекты, когда это необходимо, и где можно повторно использовать весь dll.

...