@vlad_light

Хочу написать простенькую покерную программу на с++. Нужна помощь с архитектурой. Напишите, пожалуйста, какие классы стоит реализовать. Спасибо!

0

@stima

Это как?)) Постоянно играть одними и теми же картами?

Не думаю что для моего примера нужна документация к этому классу.

Это откуда? С моего примера? Тогда скомпильте это.

Добавлено через 1 минуту
2vlad_light
Дело в том, что это не имеет смысла. То что не имеет смысла не нужно и приведет к ошибкам. Так что резать на этапе компиляции.

0

@vlad_light

И, кстати, нужна помощь с классом Player. Я сделал ему такие переменные:
и 2 метода (помимо set/get): fold () и invest (int). Что ещё добавить/убрать?

0

Jupiter

Класс карты примитывный, тут нет ресурсов которые требуется освобобождать или копировать, потому писать свой свои пустые реализации смысла нет. "Если в друг что" - что например? Класс карты станет не картой или что?

1

@vlad_light

Дело в том, что я пока не очень разбираюсь, где класс примитивный, а где -- нет. Поэтому и пишу эти штуке везде где надо и где не надо Это больше для выработки привычки (как std:: вместо using namespace std), чем для извлечения какой-то пользы из этого.

0

@stima

2 vlad_light
Это по теме. Тема называется проектирование. Упростим. Как пример представьте вы разрабатываете класс Human. Человек может быть или мужчина или женщина. Это можно сделать так как предложил lemegeton.

Так вот. Такой код позволяет написать так
Что:
1. Компилируеться.
2. Линкуеться,
3. Работает

Но пола 42 нету. И нужно постоянно помнить кто 0, а кто 1. И это может сказаться потом часами отладки.

Или так как предложил я
Теперь. Это
будет ошибкой компиляции.

Что же касается Вашего вопроса по поводу Player.
Следует заменить на
Так как во первых у вас постоянная вставка/удаление (почитайте разницу междуstd::list и std::vector). Во вторых картами владеет колода, а не игрок. Игрок их только держит(указатель/ссылка) и не может менять их содержимое(const).

И почитайте про понятия pimpl или наследование. Тогда вот эти вот переменные
Уйдут в имплементацию(припустим PokerPlayer). И вы можете на основе Player описывать игроков для любой карточной игры.

1

@vlad_light

Под переменной cards_ в классе Player я имел ввиду карты, которыми владеет игрок. Т.е. я предлагаю создать колоду в виде стека и из неё доставать (удалять) по одной карте и передавать (записывать в переменную) её игроку. Т.е. картами уже владеет игрок, а не колода.
Вашу идею я понял, но мне кажется, её будет сложнее реализовать (нужно будет держать в голове, что куда указывает). Хотя по эффективности она конечно выигрывает
Почитаю, но позже. Я пока до этого не дошёл, поэтому попробую пока сделать так, а потом переделаю.

0

@lemegeton

В битсете нечего перемешивать. Представьте пятьдесят два установленных бита подряд. Что там перемешивать?

Документация нужна всегда.

Энумы это прекрасно, но менее гибко.

... и не дай Б-г вдруг пользователю класса узнать, что существуют гермафродиты. Будет переписывать весь класс. По теме карт -- не модифицируя код класса Card, представьте с помощью него новую карту -- джокера.

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

Моя идея заключалась в том, чтобы хранить любой набор 52 карт в семи байтах, вычисляя саму карту походя из позиции установленного бита. That's, в общем-то, it.

0

@ninja2

Мне от просто интересно понять иерархию классов, если от так создать классы, то в каких они будут отношения?
Класс Deck будет отностися к Card, значит что в нем будет хранится указатель на объекты Card. Класс игрок, что он будет делать? В игрока наверно будет колода, и наверно еще свои карты, значит это, то что игрок имеет колоду. Класс ИИ это разновидность игрока Значит можно сделать ИИ : public игрок. (но я думаю это фигня там простая функция которая просто по алгоритму будет менять параметры массива розданных карт).
А стол куда будет относится? Наверно игрок имеет и стол и игрок имеет и колоду, на столе допустим просто будут розданые карты. Как мы видим в верху всего у нас стоит класс карта, от нее идет производный класс колода, от колоды идет производный класс игрок, от также производный и от класса стол,
Получается просто :
колода : public карта;
игрок : public колода, public стол.
стол как бы сам по себе хранит просто данные об игре.

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

Я просто сам пытаюсь разобраться в этих иерархиях и архитектурах классов, хотя как мне кажется нету никакой архитектуры, просто есть допустим громадная программа, которую мы можем разбить на подклассы, допустим отдельные мелкие функции взять и разбить на подклассы, законченные конечно. Это просто более удобно один класс верхушку создал, отладил все работает, мы больше к нему не возвращаемся делаем наследование создаем производный класс, либо еще новый который независимый и так от строим иерархию. Это выглядит построение снизу вверх, просто явно видно. И тоже способ очень в принципе хороший да и простенько и ясненько. Разделяй и властвуй как говорится.

Хотя мб я и не прав. Но я больше думаю что всетаки прав, потому что по другому как строить я не вижу.

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

0

@lemegeton

Колоду нельзя наследовать от карты, так как колода не является картой. Тут должна быть аггрегация.

0

@ninja2

Тут похоже кругом агрегацию нужно применять.

0

@lemegeton

Ибо одно из правил гласит -- предпочитайте аггрегацию наследованию.

1

@ninja2

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

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

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

Я в этом не сильно опытен и компетентен, но если просто представить как будет строится программка и как она будет работать, то получается очень удобно.

0

@lemegeton

Читайте больше теории. Еще больше теории. Книжки по проектированию подойдут.
У карты какие свойства? Ранг и масть.
Какая масть у колоды? Какой ранг у колоды?!
Так какой смысл колоду наследовать от карты?! Что бы все запутались?
Ошибки не появляются. Они есть. Всегда. В любом коде. Земля вертится, все меняется. То, что сегодня казалось безупречным, завтра будет куском легаси кода, подлежащим немедленному рефакторингу.
Осторожно, вы уже выходите за грань как добра так и зла.
Простите, но это будет ад и содомия.
Индусский код это называется.

Чет я не понял. У вас ВСЕ классы будут зависеть друг от друга наследованием(!), но код при этом каким-то чудом окажется независимым?! Это странно как минимум.

Очень большая проблема ООП -- так называемая "хрупкость" базового класса. Т.е. в большом проекте изменения в базовом классе сделать либо практически невозможно либо повлечет за собой непредсказуемое поведение системы в целом. Отсюда и правило -- предпочитайте аггрегацию наследованию.

2

@ninja2

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

Можно только использовать классы отдельно если они не имеют никакой зависимости с другими классами либо имеют зависимость с вложенными классами.

Получается все взаимосвязано и что то поменять уже не так просто.

0

@lemegeton

Безусловно. Код на аггрегациях все же менее хрупкий.
Все равно, стоит сначала разобраться, когда можно использовать наследование, перед тем, как предпочитать ему аггрегацию. )

1

@ninja2

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

Добавлено через 1 минуту
lemegeton, да я понял наследование нужно применять, если есть общие методы и члены для классов наследников, чтобы не писать код дважды.

0

@lemegeton

не надо другом. Все общение с объектами происходит через открытые методы.

Бессмысленно. Просто ни к чему.

Абсолютно.

Тоже не нужно. Игрок не является колодой.

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

1

@ninja2

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

Добавлено через 5 минут
lemegeton, Спасибо за лекбез. ООП правда запутанная тема, возможностей много, а как правильно делать кто его знает как.

0

@ТОрчОК

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

0

@ninja2

ТОрчОК, Попытайся без дерева. Я так понимаю дерево это альфа-бета осечение или как там его называют?
Просто попробуй 3 правила для хода компа. От если ходит комп то обязательно с самой меньшей карты не козырь и подкидывает допустим карты максимум валет и шушваль, остальное оставляет себе, там дамы короли тузы. Просто попробуй для начала придумать небольшой набор правил я думаю аи этим инструкциям будет следовать постоянно то к концу игры у него накопится норм козырей и больших карт так что с ним играть будет интересно.
Так же какой нибудь набор правил придумай небольшой для того варианта, если комп отбивается. Не обязательно дерево. Дерево это мегаацкий камп сделать, который не переиграть , а в дурака играют обычные пользователи кое как, им не интересно будет с таким компом играть, так что твой простой алгоритм будет рулить

Добавлено через 4 минуты
ТОрчОК, я тоже делал игру reversi и тоже нужно было AI сделать так я простейшие правила для хода компа сделал и кам тяжело выиграть, хотя можно было альфа-бета отсечение ну в нем еще нужно разобраться было, поэтому я не делал. Просто понял что альфа-бета отсечение это дерево в котором находятся все возможные ходы которые токо могут быть, комп как то их перебирает и обязательно ходит правильно, всегда выберает наиболее правильный ход заглядывая на перед, Но нафиг так делать? Обычный пользователь не профи, ему пару правил и мега ацкий AI получается.

0