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

@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 **[ТС]**

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

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .

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

	Структура программы или наследование, без использования конструктора базового класса 16.05.2015, 19:57. Показов 1714. Ответов 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

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

Решение