Go Fish и частая ошибка в ООП

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

Отблагодарить меня можно следующими способами:
Яндекс деньги: 410012245557024
Webmoney-R: R327167873071
Webmoney-Z: Z345122673518

[AntiPolarity]

Видео можно назвать "частая ошибка преподавателя". Преподаватель в универе зачастую подразумевает, что задача окончательна и изменена не будет. Поэтому он сразу же пытается её оптимизмровать.
Если взять реализацию из видео как пример, то что произойдёт если нам нужно добавить к правилам масть? Приёдется менять колоду и руки и алгоритм игры. То есть всю программу целиком. Если же карта останется классом, то мы прсто добавляем в класс новое поле и добавляем условие в алгоритм игры. Всё, изменений минимум.
Так, что протите, Владимир, но в этом видео Вы неправы.

[vividbw]

Есть несколько замечаний:
Все зависит от модели игры. Если масть не имеет значения и никак не отображается пользователю, то можно её не хранить. Но если игрок должен видеть масти, то от неё не избавиться.
Класс 'колода' вместо обычного вектора вводят для того, чтобы манипулировать с объектом предметной области, а не обычной коллекцией. Также для того, чтобы ограничить набор действий, которые можно выполнить с колодой. Вектор позволяет добавлять элементы в произвольное место. Колода ограничивает нас в свободе действий.

[constantinekhvalin]

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

[xzxz]

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

[criterrors]

У нас эта игра называется "сундук"

[barnabashiawatha]

А что на счет масштабируемости? Это слишком маленькая задача. ООП начинает проявлять свои сильные стороны при написании большых программ.

[Partey-xhfr]

Даже от мастей можно отказаться как отдельное число. А класс, если и пригодиться, то с методами get масть и ранг. Их можно высчитыватьть с помощью остатка от деления на 4 и попасть деления на 4

[multigelius]

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

[drevilnothingissacred]

В детстве я играл в эту игру(реальными картами). Но мы угадывали ещё и масть 😁

[AndersonSilva-dgmg]

Показалось, что речь пойдет про Golang )

[masterswift]

Здравствуйте, а вы не думали курсы делать?

[yourstarchan]

Володя, вот скажи мне, если мы завязались на том что некоторые объекты хранят в себе одну единицу примитивной информации, например число, как в твоем примере, или строку, то в случае когда нам необходимо будет дополнить эту структуру доп. информацией (например правила изменились и теперь в логике участвует масть), придется переписывать все классы которые как-либо завязаны на int[52]. Может лучше изначально сделать приложение более расширяемым?

[Negative]

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

[ДмитрийПрокопьев-шз]

Не стоит плодить сущности там где они не нужны...

[СергейКрым-эг]

Я вам больше скажу. Все игры с случайностью против компьютера можно упростить до одной функции!
Человек что-то там думает, просчитывает, пляшет с бубном и делает ход. А компьютер тупо рандомит - выиграл он или проиграл. Независимо от ходов и всякой логики.
Единственное что программе надо сделать, это подобрать свою комбинацию карт или др. фигни, которую надо показать человеку чтоб она соответствовала результату игры.
К примеру.
Игра "Камень-ножницы-бумага". Я делаю ход. Пофиг какой. Допустим я выбрал "камень". Комп рандомно выбирает, к примеру, что я проиграл. И в зависимости от моего хода, показывает якобы свой ход. В данном примере это "бумага". Вот и все. Одна функция. Никакой логики, никакого смысла в выборе и тот же результат!
Как тебе такое, Илон Маск? :)