Вопрос по проектированию - Страница 7

Wolsh · 25.09.2017, 20:45

Полиморфизм строится на переопределении, а то о чем говоришь ты — наличие одних свойств и отсутствие других — не имеет к нему отношения.
Полиморфизм это когда и мальчик и девочка имеют метод piss(), но реализуют его по-разному.
В твоем случае ты мог бы спокойно обращаться к .gender и вызывать этот метод, и если бы .gender хранил ссылку на экземпляр подкласса GenderMale, то выполнялся бы его метод, а GenderFemale делала бы это по-другому.
И тебе НИГДЕ не нужно было бы разбираться, мальчик там или девочка.

Добавлено через 20 минут
И еще. Когда ты пишешь "Wolsh сказал делать так, Wolsh сказал делать сяк" — Wolsh отвечает на ТВОИ вопросы. Я же не знаю всю подноготную. Мне, например, не кажется полезным разделение Гендера на Мужской и Женский, вроде как 1 и 0 было достаточно (к тому же позволяет расшириться, введя 2, 3 и 100500). А если бы в игре были еще и расы? Эльфы там, с "длиной ушей", орки с клыками, гномы — женщин которых никто никогда не видел?
Как справедливо заметил Кейси, и у женщины может быть борода, нет — значит ее длина ноль; и у мужчин есть и талия и грудь. Я бы не стал из-за ЭТИХ свойств делать разводку на два подкласса, НО. Я ведь не знаю предысторию этого разделения. Может как раз и подразумевалось переопределение методов в дальнейшем, чтобы мальчики и девочки делали одно и то же по-разному.

Appleman · 25.09.2017, 22:37

Цитата:

Сообщение от Wolsh

И еще. Когда ты пишешь "Wolsh сказал делать так, Wolsh сказал делать сяк" — Wolsh отвечает на ТВОИ вопросы. Я же не знаю всю подноготную.

Я с конца отвечать начну

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

Цитата:

Полиморфизм строится на переопределении, а то о чем говоришь ты — наличие одних свойств и отсутствие других — не имеет к нему отношения. Полиморфизм это когда и мальчик и девочка имеют метод piss(), но реализуют его по-разному.

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

Цитата:

Может как раз и подразумевалось переопределение методов в дальнейшем, чтобы мальчики и девочки делали одно и то же по-разному.

Да, именно. Мне уже видится достаточно ситуаций, где требуется разная логика для персонажей мужского и женского пола. Хотя возможно выделение подклассов - и правда перебор. Пошёл думать.

Nooob · 25.09.2017, 23:00

Какая-то у вас товарищи абсурдная абстрактная задача Gender, никто в здравом уме не будет её таким образом решать. ООП не нужно делать ради ООП, нужно делать от задачи: удобства, расширяемости, управляемости, устойчивости, простоты, раскрепощенности, определенности, жесткости, все остальное лишь пыль, если не исполняет цели задачи

Wolsh · 25.09.2017, 23:46

Цитата:

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

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

Appleman · 26.09.2017, 14:08

Цитата:

Сообщение от Nooob

Какая-то у вас товарищи абсурдная абстрактная задача Gender, никто в здравом уме не будет её таким образом решать. ООП не нужно делать ради ООП, нужно делать от задачи: удобства, расширяемости, управляемости, устойчивости, простоты, раскрепощенности, определенности, жесткости, все остальное лишь пыль, если не исполняет цели задачи

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

Цитата:

Наследник замещает суперкласс, но не наоборот! И если ты завел у наследника новые свойства и методы, для работы с ними ты должен обращаться с наследником конкретно, а не абстрактно.

Да, спасибо, понятно. Как всегда дьявол в деталях. До этого у меня уже использовалось наследование, но при создании экземпляра класса, там сразу явно указывался тип-наследник, и никаких проблем не возникало. А чуть только я добавил суперкласс в переменную экземпляра (как это получилось в случае с Gender), так началась фигня. Ещё раз благодарю за комментарии и объяснения.

Цитата:

Вобщем, из всего этого хотя бы вынеси понимание полиморфизма, уже плюс к скиллам

Воистину так, аминь!

Appleman · 14.10.2017, 13:53

Други!

Возвращаюсь в эту тему с очередным концептуальным вопросом. Каждый раз, когда мне требуется реализовать очередную функцию, я дико мучаюсь, куда её, пардон, вставлять. С одной стороны, имеем понятие "single responsibility", что несомненно есть благо. Но в пределе такой подход означает - "один метод - один класс" (причём иногда именно так и происходит).

Поэтому мой вопрос - о критериях выделения каких-то функций/методов в самостоятельные классы или, напротив, группировки их в один класс. И если с первым хоть как-то интуитивно понятно, то со вторым - полная каша в голове.

Вот например, обсуждаем в соседней теме вопросы многоязычности приложения. Понятно, что весь функционал загрузки данных из XML лучше выделить в отдельный класс и наладить с ним простое как грабли взаимодействие: ты ему ID-шник, он тебе обратно - фразу (в моём случае массив фраз, но это неважно). Никаких вопросов. Но вот, например, есть функционал (также обсуждавшийся в этой теме выше) подбора словесных расшифровок для свойств персонажа, типа "дурак - умный - гениальный". Там уже не просто запрос варианта, но и некая логика, основанная на текущих значениях свойств персонажа, таким образом, он взаимодействует с классом Character. Его можно выделить в полностью самостоятельный класс, можно создать что-то типа CharacterModel и поместить туда вместе с другими методами обработки свойств персонажа...

Или ещё пример. Для построения удобочитаемых фраз имеем алгоритм подстановки в полученный кусок текста имени собственного в нужном падеже. Он получает фразу из XML, плюс "знает" что должно быть в него подставлено вместо *$a1. Другой метод получает на входе оценку двух частей сложносочинённого предложения и выдаёт связующий союз (типа "ему охота, и ей охота" и "ему охота, но ей не хочется"). Вроде метод тоже языковой... Имеет смысл объединять их вместе или нет? Какая логика? Не чувствую её.

caseyryan · 14.10.2017, 20:05

Чувствую, скоро дойдет до того, что нужен будет метод, который должен будет определять, написать "поребрик" или "бордюр" в зависимости от текущей локации игрока)
Для игры, которая не имеет целью учить игрока русскому языку, всё это абсолютно излишне. Лучше сделать хороший и интересный гейплей, чем сделать скучную и унылую игру, но зато с правильным правописанием диалогов. Которые, по многочисленным личным наблюдениям, всё равно почти никто не читает. Диалоги в играх вообще должны сводиться к минимуму, это наводит на игрока скуку. Меньше текста, больше действия. Все предложения должны быть максимально короткими и простыми

Appleman · 15.10.2017, 15:45

Цитата:

Сообщение от caseyryan

Чувствую, скоро дойдет до того, что нужен будет метод, который должен будет определять, написать "поребрик" или "бордюр" в зависимости от текущей локации игрока)

Ну, положим, петербуржца затроллить поребриком может каждый

, но вопрос-то мой был весьма серьёзный касательно организации создаваемых классов.

Цитата:

Меньше текста, больше действия. Все предложения должны быть максимально короткими и простыми

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

Пока сам надумал немного. Есть мысль №1 о том что поскольку условий может быть много, и точное их количество неизвестно для различных случаев, это должен быть некий массив, который будет передаваться на входе в метод-определитель доступности, чтобы он - метод - пробегал по всем и давал итоговое заключение на выходе: либо всё соблюдено, либо № элемента, который "не проходит". Мысль №2, что если у нас все характеристики персонажей (и не только персонажей) заданы через строковые идентификаторы типа "character.intelligence", то их можно и запихивать в массив с условиями, чтобы быстро обратиться за соответствующим значением. А вот всё остальное (запись и хранение целевых значений, операторов сравнения и т.п.) пока не находит ответов.

caseyryan · 16.10.2017, 06:32

Цитата:

Пока сам надумал немного. Есть мысль №1 о том что поскольку условий может быть много, и точное их количество неизвестно для различных случаев, это должен быть некий массив, который будет передаваться на входе в метод-определитель доступности, чтобы он - метод - пробегал по всем и давал итоговое заключение на выходе: либо всё соблюдено, либо № элемента, который "не проходит". Мысль №2, что если у нас все характеристики персонажей (и не только персонажей) заданы через строковые идентификаторы типа "character.intelligence", то их можно и запихивать в массив с условиями, чтобы быстро обратиться за соответствующим значением. А вот всё остальное (запись и хранение целевых значений, операторов сравнения и т.п.) пока не находит ответов.

Тут сам диалог получается как отдельная мини игра.
Не приходилось такого делать, но представляю это себе примерно так:
Диалог представляет из себя объект, приблизительно такого вида

Код AS3:

{
   dialog1: [{skillLevel: 1, textID: "walkInThePark"}, {skillLevel: 2, textID: "killDragon"}, { skillLevel: 100500, textID: "changeTheWorld" }]
}

Дальше игрок, допустим, подходит к какому-то NPC, которому прописан ID диалога. В данном случае dialog1 и этот NPC выбирает что сказать в зависимости от текущих возможностей игрока. В базовом классе NPC должен быть механизм определения

Код AS3:

 
public function showDialog(dialogID:):void {
    var playerSkillLevel:int = _gameModel.selectedCharacter.skillLevel;
    var dialogVersions:Array = DialogManager.getDialogVersionsByID(dialogID); // какое-то централизированное хранилище диалогов
    for each (var dialog:Object in dialogVersions) {
       if (dialog.skillLevel == playerSkillLevel) {
           showDialog(dialog.textID);
           return; // дальше выполнять метод нельзя, так как диалог найден
       }
    }
    showDialog(null); // если в цикле ничего не нашлось, показываем диалог-пустышку
}
private function showDialog(textID:String):void {
       if (textID) {
           trace(i18n.getTextByID(textID));   // "Иди, завали дракона, о игрок второго уровня!"
       } else {
           trace(i18n.getTextByID(DialogManager.NOTHING_TO_SAY)); // "Братуха, извини, но ты слишком крут для меня. Мне нечего тебе сказать"
       }
}

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

Appleman · 16.10.2017, 10:12

Цитата:

Сообщение от caseyryan

Тут сам диалог получается как отдельная мини игра.

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

Цитата:

Не приходилось такого делать, но представляю это себе примерно так:
Диалог представляет из себя объект, приблизительно такого вида

Код AS3:

{
   dialog1: [{skillLevel: 1, textID: "walkInThePark"}, {skillLevel: 2, textID: "killDragon"}, { skillLevel: 100500, textID: "changeTheWorld" }]
}

Что это за форма записи, когда внутри квадратных скобок (типа литерал, да?) ещё и блоки фигурных?