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

@Anton-KRaV · Регистрация: 28.07.2013

Студворк — интернет-сервис помощи студентам

Всем доброго времени суток.

Снова прошу вас о помощи!
Код располагается по ссылке в спойлере - не вставлю сюда, так как слишком длинный для форума ИМХО.
Как говорится - писал, писал, а мозги включить забыл.
Программа работает по принципу создания объекта Table, затем Hand. Все идет хорошо до конца жизни Hand. После его уничтожения, мне нужно создание нового объекта Hand, БЕЗ уничтожение Table и создания нового. Но как это реализовать - не знаю. Уже понял что структура программы плохая, и т. д. - не судите строго, я начинающий, и уж что то очень непросто дается освоение ООП.

Кликните здесь для просмотра всего текста

http://ideone.com/tgQMnR

Вопрос: как сохранять Table живым независимо от количество Hand в нем?

Заранее благодарю!!!

Добавлено через 2 часа 36 минут
Кажется, начинаю осозновать ошибку. Hand следовало сделать не производным классом, а включением, верно?

@Nosey · 16.05.2015, 20:40

Anton-KRaV,
А почему вы не сделали Hand полем Player?
Этож самое логичное, жизненное решение )

@Anton-KRaV · 17.05.2015, 08:40 **[ТС]**

Често? Я незнаю как я это то написал

А если серьезнее, то не совсем понял идею. Класс Hand - единичная раздача в игре, то есть вот, чего я хотел получить:
- создание Table
- создание Hand
- удаление Hand
- . . . (Неопределенное количество итераций)
- удаление Table

А на практике имею создание нового Table при создании Hand, так как он его наследник.
По вашему предложению не совсем понял, сделать класс Hand, отвечающий за единичную раздачу объектом класса Player?
А в чем выгода?
Заранее благодарю!

@Nosey · 17.05.2015, 09:16

Сделайте как в жизни)))
Table - за ним сидит n Player'ов, у каждого игрока есть Hand.

Игровой контроллер примерно такой:
- Контроллер получает линк на Table. И далее уже
- создание Hand
- удаление Hand
.... для каждого игрока.

Player - name, и другая статистика.
Hand - коллекция карт + всякие штуки для оценки карт если требуются, да и отдельные алгоритмы работающие с Hand'ами.

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

@Anton-KRaV · 17.05.2015, 10:14 **[ТС]**

Благодарю вас за быстрый ответ!
Единственное что смущает - одна игра (раздача карт на всех игроков, принятие ставок, раздача карт на стол, и т. п.) это все хотел реализовать в классе Hand. Данный класс - не карты на руках игроков, за это отвечает Player::vector<Card> hand. То есть класс Hand на всех игроков один должен быть, я правильно понимаю?
P.S. Вы меня уж простите, я запутался окончательно, даже диаграмму UML не смог составить

@Nosey · 17.05.2015, 12:09

Сообщение от Anton-KRaV

Единственное что смущает - одна игра (раздача карт на всех игроков, принятие ставок, раздача карт на стол, и т. п.) это все хотел реализовать в классе Hand.

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

Соответственно если это что-то типа префа, где требуется статистика между играми - то не скромничайте, заводите ещё одну сущность аля PlayerGameData.

@Anton-KRaV · 17.05.2015, 13:33 **[ТС]**

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

@kol · 17.05.2015, 13:43

Сначала создается конструктор базового класса. Конструктор производного класса должен передавать информацию базового класса через список инициализаторов членов.
Во время создания объекта производного класса программа сначала вызывает конструктор базового класса, а потом конструктор производного, деструкторы вызываются в обратном порядке.

@Anton-KRaV · 17.05.2015, 13:49 **[ТС]**

Благодарю вас, но решил использовать включение вместо наследования!
P.S. тема названа некорректно, но, видимо, переименовать уже невозможно

@Anton-KRaV · 17.05.2015, 16:55 **[ТС]**

Прошу прощения, выложил диаграмму с ошибками( Исправляюсь.
Подскажите, как правильно разрабатывать структуру программы?

@Nosey · 17.05.2015, 18:00

Anton-KRaV, Я тут вас запутал несколько, незамечая, что hand у вас, это и есть поведенческая штука.
У вас всё нормально с архитектурой, разве что несколько запутались вы.

Я бы в вашем случае, создавал Table отдельно от Hand и соттветственно передавал бы "ссылку". Ведь стол может существовать и до того как игроки будут играть, они могут просто сидеть ))))

@Anton-KRaV · 17.05.2015, 18:18 **[ТС]**

Идею понял, может стол создать отдельно от Player? Стол может быть готов к игре тоже без игроков, так ведь?
Благодарю за терпение!

@Nosey · 17.05.2015, 18:26

Anton-KRaV, Если это не сингл игра, то конечно отдельно.
Потом если вдруг окажется что создавать их нужно чаще чем хотелось бы воспользуйтесь услугами "строителя" и/или "фасада".(ну например ваша игра станет миниигрой встроенной в ММО

)

@Anton-KRaV · 17.05.2015, 18:46 **[ТС]**

Nosey, огромное вам спасибо!
Буду пробовать реализовать с чистого листа))
Осталось три маленьких вопроса:
1. Какой связью лучше установить взаимоотношение между классами игрока и стола, и стола и раздачи? Включение, композиция или какой то другой?
2. Мои классы карт и игрока оставить классами или переделать в структуры? То ли Шилдт, то ли Лафоре писал, что такие структуры для хранения данных лучше описывать как struct...
3. Можно попросить вас ссылку про "строителя" и "фасад"? Впервые слышу о таком, а беглый поиск в инете не дал ожидаемых результатов...
Еще раз благодарю!

@Nosey · 17.05.2015, 19:02

Сообщение от Anton-KRaV

Какой связью лучше установить взаимоотношение между классами игрока и стола, и стола и раздачи? Включение, композиция или какой то другой?

Ой, я не мастер, таких красивых терминов

. Могу лишь по своему сказать, что я за невладеющее "взаимодействие".

Сообщение от Anton-KRaV

Мои классы карт и игрока оставить классами или переделать в структуры? То ли Шилдт, то ли Лафоре писал, что такие структуры для хранения данных лучше описывать как struct...

Тут кому как удобно, кто как привык, я дитя С++ и пратически всегда пишу классы.

Сообщение от Anton-KRaV

Можно попросить вас ссылку про "строителя" и "фасад"? Впервые слышу о таком, а беглый поиск в инете не дал ожидаемых результатов...

https://ru.wikipedia.org/wiki/... 0%B8%D1%8F
https://ru.wikipedia.org/wiki/Design_Patterns

@Anton-KRaV · 17.05.2015, 19:22 **[ТС]**

Святой вы человек!
Спасибо!

Новые блоги и статьи Все статьи Все блоги /
Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .	Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и напряжениями. Надо найти токи в ветвях. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и решает её. Последовательность действий:. . .
Новый CodeBlocs. Версия 25.03 palva 04.01.2026 Оказывается, недавно вышла новая версия CodeBlocks за номером 25. 03. Когда-то давно я возился с только что вышедшей тогда версией 20. 03. С тех пор я давно снёс всё с компьютера и забыл. Теперь. . .	Модель микоризы: классовый агентный подход anaschu 02.01.2026 Раньше это было два гриба и бактерия. Теперь три гриба, растение. И на уровне агентов добавится между грибами или бактериями взаимодействий. До того я пробовал подход через многомерные массивы,. . .	Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Programma_Boinc 28.12.2025 Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Налог на собак: https:/ / ********/ gallery/ V06K53e Финансовый отчет в Excel: https:/ / ********/ gallery/ bKBkQFf Пост отсюда. . .	Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Programma_Boinc 26.12.2025 Нашел на реддите интересную статью под названием Anyone know where to get a free Desktop or Laptop? Ниже её машинный перевод. После долгих разбирательств я наконец-то вернула себе. . .

@Anton-KRaV 1 / 1 / 1 Регистрация: 28.07.2013 Сообщений: 41

	Структура программы или наследование, без использования конструктора базового класса 16.05.2015, 19:57. Показов 1678. Ответов 15 Метки нет (Все метки) Всем доброго времени суток. Снова прошу вас о помощи! Код располагается по ссылке в спойлере - не вставлю сюда, так как слишком длинный для форума ИМХО. Как говорится - писал, писал, а мозги включить забыл. Программа работает по принципу создания объекта Table, затем Hand. Все идет хорошо до конца жизни Hand. После его уничтожения, мне нужно создание нового объекта Hand, БЕЗ уничтожение Table и создания нового. Но как это реализовать - не знаю. Уже понял что структура программы плохая, и т. д. - не судите строго, я начинающий, и уж что то очень непросто дается освоение ООП. Кликните здесь для просмотра всего текста http://ideone.com/tgQMnR Вопрос: как сохранять Table живым независимо от количество Hand в нем? Заранее благодарю!!! Добавлено через 2 часа 36 минут Кажется, начинаю осозновать ошибку. Hand следовало сделать не производным классом, а включением, верно? 0

@Nosey 1379 / 406 / 144 Регистрация: 22.10.2014 Сообщений: 872
	16.05.2015, 20:40
	Anton-KRaV, А почему вы не сделали Hand полем Player? Этож самое логичное, жизненное решение ) 0

@Anton-KRaV 1 / 1 / 1 Регистрация: 28.07.2013 Сообщений: 41
	17.05.2015, 08:40 [ТС]
	Често? Я незнаю как я это то написал А если серьезнее, то не совсем понял идею. Класс Hand - единичная раздача в игре, то есть вот, чего я хотел получить: - создание Table - создание Hand - удаление Hand - . . . (Неопределенное количество итераций) - удаление Table А на практике имею создание нового Table при создании Hand, так как он его наследник. По вашему предложению не совсем понял, сделать класс Hand, отвечающий за единичную раздачу объектом класса Player? А в чем выгода? Заранее благодарю! 0

@Nosey 1379 / 406 / 144 Регистрация: 22.10.2014 Сообщений: 872
	17.05.2015, 09:16
	Сделайте как в жизни))) Table - за ним сидит n Player'ов, у каждого игрока есть Hand. Игровой контроллер примерно такой: - Контроллер получает линк на Table. И далее уже - создание Hand - удаление Hand .... для каждого игрока. Player - name, и другая статистика. Hand - коллекция карт + всякие штуки для оценки карт если требуются, да и отдельные алгоритмы работающие с Hand'ами. Ну и в общем, все эти сущности - очень разные, наследование среди них совершенно лишняя штука. 1

@Anton-KRaV 1 / 1 / 1 Регистрация: 28.07.2013 Сообщений: 41
	17.05.2015, 10:14 [ТС]
	Благодарю вас за быстрый ответ! Единственное что смущает - одна игра (раздача карт на всех игроков, принятие ставок, раздача карт на стол, и т. п.) это все хотел реализовать в классе Hand. Данный класс - не карты на руках игроков, за это отвечает Player::vector<Card> hand. То есть класс Hand на всех игроков один должен быть, я правильно понимаю? P.S. Вы меня уж простите, я запутался окончательно, даже диаграмму UML не смог составить 0

@Anton-KRaV 1 / 1 / 1 Регистрация: 28.07.2013 Сообщений: 41
	17.05.2015, 13:33 [ТС]
	Блин, я все равно не могу понять, как правильней составит структуру, хотя бы для минимальной функциональности... Я приложил мини диаграмму UML, что добавить нужно, помогите пожалуйста разработать грамотную структуру программу дереву... Изображения 0

@kol 24 / 10 / 5 Регистрация: 30.01.2015 Сообщений: 175
	17.05.2015, 13:43
	Сначала создается конструктор базового класса. Конструктор производного класса должен передавать информацию базового класса через список инициализаторов членов. Во время создания объекта производного класса программа сначала вызывает конструктор базового класса, а потом конструктор производного, деструкторы вызываются в обратном порядке. 1

@Anton-KRaV 1 / 1 / 1 Регистрация: 28.07.2013 Сообщений: 41
	17.05.2015, 13:49 [ТС]
	Благодарю вас, но решил использовать включение вместо наследования! P.S. тема названа некорректно, но, видимо, переименовать уже невозможно 0

@Anton-KRaV 1 / 1 / 1 Регистрация: 28.07.2013 Сообщений: 41
	17.05.2015, 16:55 [ТС]
	Прошу прощения, выложил диаграмму с ошибками( Исправляюсь. Подскажите, как правильно разрабатывать структуру программы? Миниатюры 0

@Nosey 1379 / 406 / 144 Регистрация: 22.10.2014 Сообщений: 872
	17.05.2015, 18:00
	Anton-KRaV, Я тут вас запутал несколько, незамечая, что hand у вас, это и есть поведенческая штука. У вас всё нормально с архитектурой, разве что несколько запутались вы. Я бы в вашем случае, создавал Table отдельно от Hand и соттветственно передавал бы "ссылку". Ведь стол может существовать и до того как игроки будут играть, они могут просто сидеть )))) 0

@Anton-KRaV 1 / 1 / 1 Регистрация: 28.07.2013 Сообщений: 41
	17.05.2015, 18:18 [ТС]
	Идею понял, может стол создать отдельно от Player? Стол может быть готов к игре тоже без игроков, так ведь? Благодарю за терпение! 0

@Nosey 1379 / 406 / 144 Регистрация: 22.10.2014 Сообщений: 872
	17.05.2015, 18:26
	Сообщение было отмечено Anton-KRaV как решение Решение Anton-KRaV, Если это не сингл игра, то конечно отдельно. Потом если вдруг окажется что создавать их нужно чаще чем хотелось бы воспользуйтесь услугами "строителя" и/или "фасада".(ну например ваша игра станет миниигрой встроенной в ММО ) 1

@Anton-KRaV 1 / 1 / 1 Регистрация: 28.07.2013 Сообщений: 41
	17.05.2015, 18:46 [ТС]
	Nosey, огромное вам спасибо! Буду пробовать реализовать с чистого листа)) Осталось три маленьких вопроса: 1. Какой связью лучше установить взаимоотношение между классами игрока и стола, и стола и раздачи? Включение, композиция или какой то другой? 2. Мои классы карт и игрока оставить классами или переделать в структуры? То ли Шилдт, то ли Лафоре писал, что такие структуры для хранения данных лучше описывать как struct... 3. Можно попросить вас ссылку про "строителя" и "фасад"? Впервые слышу о таком, а беглый поиск в инете не дал ожидаемых результатов... Еще раз благодарю! 0

@Anton-KRaV 1 / 1 / 1 Регистрация: 28.07.2013 Сообщений: 41
	17.05.2015, 19:22 [ТС]
	Святой вы человек! Спасибо! 0

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

Решение