Правильно ли я нарисовал план ООП игры шашки?

Question

[Сергей Котов]

Изучаю ООП. Хотел попробовать написать игру шашки для двоих на javascript. И накидал на программе xmind так скажем архитектуру игры. Хотелось бы узнать ваще мнение

Comments

[Сергей Котов]

извините

[Ярослав Иванов]

Да вон какую схему нарисовал крутую. Че докапываешься до орфографии?)

[Василий Мажекин]

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

[Василий Банников]

Лентюй, такие вещи, обычно, не в "ответ", а в "комментарий" пишут.

Answer 1

[Сергей Соколов]

Раз изучаете ООП, может, сделать дамку дочерним классом, наследующим что-то от просто-шашки, но переопределяющим некоторые свойства и методы?

В приведённой схеме не учитана возможность цепочек «атакующих» ходов. В т.ч. с трансформацией в дамку в процессе обжорства )

Можно ввести сущность «ход». Тогда можно складывать ходы в массив игры. Сохранять игру, воспроизводить её. Перехаживать! )

Протяженность во времени: если делать красиво, то будут анимации перехода шашки между клетками. В это время нельзя вмешиваться, например. Хотя, вероятно, это пока излишнее усложнение.

Доске понядобятся методы инициализации, может загрузки позиции, оценки позиции.

Comments

[Сергей Котов]

спасибо за ценный совет

Answer 2

[Dmtm]

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

Answer 3

[Максим]

В целом не плохо. Но бы сделал по другому.

1. Свойства не выносить отдельно в схеме. Не совсем понятно что вы изменяете в методах. Какие условия при изменении. Какие параметры. И т. д. Свойства нужны больше для проектирования БД.

Например лучше так:
Подвесить клетку
- цвет (string(6))

2. Шашка это неотъемлемая часть доски. Поэтому модификация шашек будет из сущности доски.

Для примера можете посмотреть как строится любое API. Везде есть метотоды и описание что они делают. Какие параметры принимают. Какой результат возвращают. Какого типа и так далее. Зайдите VK API сразу поймёте. Вам нужно сделать некое подобие API.

В остальном нормально)

Comments

[xfg]

2. Шашка это неотъемлемая часть доски. Поэтому модификация шашек будет из сущности доски.

У вас DDD указан в профиле. В книге Вон Вернона Implementing domain-driven design про агрегаты написано, что не нужно вкладывать сущность в агрегат просто потому что это кажется логичным. Нужно исходить из наличия инвариантов, то есть ситуации когда корень агрегата меняет своё состояние при изменении внутренней сущности, если такое есть - тогда да, если их нет, тогда нет. Здесь такого не наблюдается, стандартная ситуация из двух агрегатов доски и шашки со связью 1:N, где шашка ссылается на доску по id.

Вот что точно ненормально, так это отрисовка шашки, подсветка клетки, получить возможные ходы и тому подобное. Потому что это не бизнес-логика. Нет такого в игре в шашки, а когда проектируется что-либо, всегда нужно помнить, что мы делаем модель чего-либо. Соответственно чего нет в том предмете/явлении, который мы проектируем, этого не должно быть и в его доменной модели, так как модель есть упрощенная версия того или иного предмета/явления. Рисовать шашки, подсвечивать клетки и ходы - это всё должно быть в слое представления. Вообще автор может открыть выше указанную книгу и самостоятельно понять, что в его модели не совсем хорошо и как это можно исправить.

[Максим]

Да, возможно, вы правы с агрегатами в этой части. Тут можно порассуждать. Спорить не буду.

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

В жизни использования «Подсветить клетку» нет. У шашки должен быть какой-то метод, например «ходить». В него передаём новое положение шашки.
Подсветку шашки следует выполнять по текущему положению курсора или другому событию.

Я не стал описывать все детали автору, так как его вариант выглядит «сыровато». Описывать всю теорию построения архитектуры выйдет на целую статью. Поэтому и написал в конце — «нормально».

Answer 4

[Северное Сияние]

Изучаю ООП. Хотел попробовать написать игру шашки

1. Изучать ООП на Жс не лучшая идея, возьми тот же пхп.
2. Писать столь сложную игру, как шашки, да ещё и на ООП - не самая тривиальная задача для обучения

Answer 5

[Евгений Гл]

СостояниеКлетки{
БелаяШашка,
ЧернаяШашка,
БелаяШашкаДамка,
ЧернаяШашкаДамка,
НетШашки
}

СостояниеИгры{
Старт,
Жеревьевка,
ХодБелых,
ХодЧерных,
ИграЗакончена,
}

Переменные:
"Доска" тип: СостояниеКлетки[8][8];
"Этап" тип: СостояниеИгры
"Игрок1"
"Игрок2"

Методы:
SetЭтап(СостояниеИгры) //Тут можно использовать паттерн "Состояние"

OnStart()
-ИнициализироватьИгроков();

OnЖеревьевка()
-ЗадатьЦветаИгроков()
-ЗаполнитьДоску()

OnХод(Player, X, Y)
-ТутЛогикаХода (удаление фишек, перемещение и т.п.)

OnИграЗакончена()
-ПодсчитатьИВывестиРезультаты()

Answer 6

[robomakerr]

Мне кажется, для такой простой архитектуры не нужно ООП.