@Ryote

Занимался обычным программированием (начинал с Pascal, потом Delphi, также программировал на PHP, JavaScript) и решил попробовать создать более серьезный в реализации проект для конкретной платформы.
Так вот, перед программированием более или менее серьезного проекта необходимо все-таки предварительно иметь набросок диаграммы классов и знать какие функции они выполняют.
Итак имеется карточная игра наподобие Magic: The Gathering. Опыта в создании проектов нет. Пока что есть наработки (пока пользовательского интерфейса в представлении нет):
Классы - Card (содержит данные по картам), Deck(содержит данные по колоде карт), Player (содержит данные игрока - параметры здоровья, очков призыва и т.п.), Action (содержит действия, которые могут происходить - призыв карты, атака, защита, использование заклинаний), Exception (обработка корректности действий игроков), Table (который в принципе и описывает все действия с картами, просчеты, комбинации карт и т.п.).
Возникают подозрения, о том, что я все-таки упускаю моменты уже в текущей модели, и в классе Table содержится огромное количество методов, поэтому необходимо его разбивать.
Уважаемые форумчане, прошу помощи как раз в этом вопросе.

0

@CheshireCat

А за что именно отвечает твой класс Table? Какое такое "огромное количество методов" он содержит? Они могут быть разбиты на функциональные группы? Какие?

0

@Ryote

Ну если смотреть на данную модель, то все перечисленные классы до Table и Exception, хранят только данные.
Exception как я говорил будет "фильтром" корректности передаваемых данных (ну мало ли игра сетевая будет).
А на Table сваливается все остальное по обработке данных. Действия с колодами каждого игрока, переходы из колоды в руку, с руки на призыв, с призыва - останется ли карта или умирает, получение количества очков защиты, атаки в данный ход, изменение параметров игрока (отнимает здоровье при успешно проведенной атаке, количество очков призыва при изъятии карты из руки на игровое поле), тасовка колоды, удаление "мертвых" карт из текущей игры, сохранение т.д.
У меня в этом и заключается проблема правильно разбить данный класс на другие классы, чтобы каждый отвечал за свои функции. Опыт таковой отсутствует.

0

@CheshireCat

Ага. Мда, у тебя этот самый Table получается как антипаттерн "God Object" (Божественный Объект или Универсальный Всемогутер). Попробуй выделить функционально ограниченные группы действий в отдельные классы (например, PlayerLogic, GameLogic могут отвечать за логику отдельного игрока и игры в целом, GameLoader может отвечать за загрузку/сохранение игры на диске... и так далее, - к сожалению, я не знаком с игрой и не могу сказать конкретнее). Поможет анализ предметной области (правил игры?).

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

1

@Ryote

Спасибо за помощь и подсказки. Все-таки хочется потому что делать "по науке", а не как придется (как зачастую приходилось во время учебы). Анализируя и обучаясь на каждом этапе разработки. Буду двигаться и развивать идеи. Спасибо еще раз.

0

TanaTiX

Ryote, если не в курсе, почитай про SOLID - должно пригодиться.

1

@Ryote

Спасибо большое, почитаю.

0

XRuZzz

А вы попробуйте подробно описать в текстовом виде как игра происходит в жизни без компьютера. (или возьмите готовое описание)
И внимательно посмотрите все ли сущности вы определили правильно
Например эти сущности у меня сомнений не вызывают
Карта
Игрок

Колода? может это просто массив карт и такая сущность нам не нужна?
Table? первая ассоциация с этим словом это стол. А стол это как бы игровое поле. Может так и обозначить его
GameField тогда эта сущность описанная в предметной области становиться классом на диаграмме классов.

Собственно можно и нарисовать первичную диаграмму классов, на которой показаны сущности предметной области( без классов программы). Это может стать ключем к решению вопроса архитектуры приложения. На такой диаграмме должны присутствовать отношения между сущностями.

Добавлено через 30 минут
думаю, что четкой науки тут не получиться. Это просто некоторые методы основанные на догадках создателей ООП. Которые как бы предлагают: "Попробуйте описывать сущности реального мира, как программные единицы".

подход RUP скорее всего больше подходит к желанию "сначала всё продумать, потом начинать делать"
XP же направлен на более быстрое получение рабочего прототипа.

0

@Ryote

Сейчас у меня получатся так:
Card (параметры карты, тип карты (по правилам их всего 5 типов))
Deck (массив карт)
Player (параметры игрока)
Action (список действий, реализуемых в рамках правил)
Error (класс для обработки ошибок)
Filter (класс проверки корректности полученных данных)
PlayerLogic (отвечает за изменение данных игрока, его параметров)
GameLogic (отвечает за правила ведения игры)
ActionLogic (описана логика действий соответствующим правилам, описанным в GameLogic)
Естественно ActionLogic все равно оказывается антипаттерном. Поэтому класс разбивать следует на отдельные действия в соответствии с текущими правилами. Т.е. имеются этапы хода - начало игры, призыв существ, атака/защита, конец хода. И по ним выстроить отдельные классы.

0

XRuZzz

если не рассуждать о предметной области и изобразить часть диаграммы классов то я бы сделал так
(люблю называть классы во множественном числе)
типа две агрегации, показывающее связь Fields(игровые поля) с Rules(правилами игры) и Cards(Карты)

Думаю конечная цель это упрощение логики, уменьшение количества кода, и уменьшение вероятности полного рефакторинга

Всё таки классы типа ActionLogic я бы привязывал к сущностям предметной области( поэтому так важно их определять на первом этапе)

Поэтому не ActionLogic
а PlayerActions
и ComputerActions(хотя тут компьютер это тоже в сущности игрок, поэтому можно ограничиться PlayerActions)
то есть некий класс которые выделяет методы действий из класса Players в отдельный класс для повторного использования.

Добавлено через 7 минут
Хотя мы имеем полное право описать все в классе Players (а может лучше назвать его Users, или сделать потомком Users - в будующем может пригодиться)

Добавлено через 2 минуты
может в реальной жизни в игре есть судья?
тогда разумно ввести класс Arbiters

0

@Ryote

Даже если и существует PlayerAction - все равно он будет очень большим классов по сравнению с остальными и в итоге придется разбивать на классы - StartGameAction, SummonAction, AttackAction, ProtectAction, EndGameAction, т.к. правила каждого из компонентов могут быть изменены, но при этом игровой логике наплевать в принципе, что внутри каждого компонента действий находится, ему просто нужно его вызвать в соответствии с правилами ведения игры. А сваливать все действия в PlayerAction тоже неправильно, т.к. при добавлении нового действия в правиле игры, придется добавлять вызов не только в GameLogic , но и в PlayerAction. Поэтому я думаю все-таки для каждого нового действа писать отдельный класс.

Цель все-таки максимально правильно представить модель "по учебникам". Поэтому и возникают такие классы, как Error, которые обрабатывают ошибки.

0

XRuZzz

ещё пришло в голову выделить класс PlayerFields - которые символизируют руки игрока в которых он держит карты.
тогда Players связан с PlayerFields отношением композиции(руки не могут существовать без игрока, или всё таки могут? надо проверить отрубанием )

Добавлено через 3 минуты
правильного не существует, даже на форуме мнение экспертов по предметной области разные. Я просто стараюсь придерживаться Коберна, Фаулера, RUP, материалов собранных на сайте www.uml2.ru

Я не могу с вами спорить мне неизвестна предметная область(как и правила игры)

0

@Ryote

Была такая же идея, но все-таки она неверная. Делить карты. Не важно, где карты находятся, проще просто в данных прописывать в каком статусе находится карта в данный момент (ожидание, призвана, защита/атака, умерла/удалена).

Фаулера я читал, но все-таки опыта никакого. Поэтому получается "учимся плавать, кинув себя в центр глубокого озера".

0

XRuZzz

цитата из вики по вашей ссылке Magic: The Gathering
Честное слово я бы не удержался и сделал бы классы
PowerWizards(или PlanesWalkers)
MagicResources
Spells
Artifactes
и т д

Код становиться фэнтазийным и интересным и пофиг на учебники

Добавлено через 5 минут
Нарисовали бы диаграмму объектов предметной области, которая отражает сущности предметной области. Или диаграмму классов (если не хочется тратить время на первую). Визуальную картинку интереснее изучать.

0

@Ryote

Ну я все-таки для начала упростил, выкинув из правил пока что заклинания и лишние параметры. Оставив у существ показатели атаки/защиты/кол-во очков призыва. А ход делится на начало хода, призыв, фаза атаки - атакующий игрок выбирает атакующих существ, защищающийся игрок выбирает защищающихся существ, конец хода.

Да я тоже так думаю, по диаграмме классов расписать как происходит игра и кто к кому обращается, но к сожалению это во внерабочее только время

0

XRuZzz

http://www.uml2.ru/index.php?o... &Itemid=50
я про то что на диаграмме классов показать это нельзя

Добавлено через 9 минут
Но это можно показать на диаграмме бизнес объектов, которая отражает сущности предметной области. И рисуется в нотации диаграммы классов.

Добавлено через 2 часа 23 минуты
То есть с помощью диаграммы объектов сущностей предметной области можно рассмотреть игру, без проектирования вашей программы и без компьютера.

И на связях как раз можно показывать взаимодействие этих объектов, например рисуем сущности Арбитер и Карта.
на линии отношения можно указать "раздаёт" и направление отношения. Тогда по диаграмме будет видно что арбитер раздаёт карты.
Как это может помочь архитектуре?
Да можно сразу создавать класс Arbiters и метод distributeCards ("раздать карты")
тогда если мы правильно описали взаимодействие на диаграмме бизнес объектов, то такая архитектура не измениться до конца жизни проекта.

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

0