|
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Полиморфизм строится на переопределении, а то о чем говоришь ты — наличие одних свойств и отсутствие других — не имеет к нему отношения.
Полиморфизм это когда и мальчик и девочка имеют метод piss(), но реализуют его по-разному. В твоем случае ты мог бы спокойно обращаться к .gender и вызывать этот метод, и если бы .gender хранил ссылку на экземпляр подкласса GenderMale, то выполнялся бы его метод, а GenderFemale делала бы это по-другому. И тебе НИГДЕ не нужно было бы разбираться, мальчик там или девочка. Добавлено через 20 минут И еще. Когда ты пишешь "Wolsh сказал делать так, Wolsh сказал делать сяк" — Wolsh отвечает на ТВОИ вопросы. Я же не знаю всю подноготную. Мне, например, не кажется полезным разделение Гендера на Мужской и Женский, вроде как 1 и 0 было достаточно (к тому же позволяет расшириться, введя 2, 3 и 100500). А если бы в игре были еще и расы? Эльфы там, с "длиной ушей", орки с клыками, гномы — женщин которых никто никогда не видел? Как справедливо заметил Кейси, и у женщины может быть борода, нет — значит ее длина ноль; и у мужчин есть и талия и грудь. Я бы не стал из-за ЭТИХ свойств делать разводку на два подкласса, НО. Я ведь не знаю предысторию этого разделения. Может как раз и подразумевалось переопределение методов в дальнейшем, чтобы мальчики и девочки делали одно и то же по-разному.
__________________
Reality.getBounds(this); |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Цитата:
Цитата:
Цитата:
|
|
|||||
Регистрация: Mar 2007
Сообщений: 319
|
Какая-то у вас товарищи абсурдная абстрактная задача Gender, никто в здравом уме не будет её таким образом решать. ООП не нужно делать ради ООП, нужно делать от задачи: удобства, расширяемости, управляемости, устойчивости, простоты, раскрепощенности, определенности, жесткости, все остальное лишь пыль, если не исполняет цели задачи
__________________
RocketJump Последний раз редактировалось Nooob; 25.09.2017 в 23:39. |
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Цитата:
Еще раз, этот мой спич касался полиморфизма. Полиморфизм это не всё ООП, это один из принципов, который можно также грубо переформулировать, как "класс-наследник может замещать суперкласс, используя свою реализацию". Наследник замещает суперкласс, но не наоборот! И если ты завел у наследника новые свойства и методы, для работы с ними ты должен обращаться с наследником конкретно, а не абстрактно. Возможно, ты как-то по-своему понял термин "расширяет", как будто наследник ИЗМЕНЯЕТ свой суперкласс, добавляя что-то к НЕМУ. Но нет, он добавляет только СЕБЕ, но добавляет к тому, что досталось ЕМУ в наследство, в этом смысле он "расширяет". Но "старая версия" остается как есть. Вобщем, из всего этого хотя бы вынеси понимание полиморфизма, уже плюс к скиллам
__________________
Reality.getBounds(this); |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Цитата:
Цитата:
Цитата:
Последний раз редактировалось Appleman; 28.09.2017 в 09:59. |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Други!
Возвращаюсь в эту тему с очередным концептуальным вопросом. Каждый раз, когда мне требуется реализовать очередную функцию, я дико мучаюсь, куда её, пардон, вставлять. С одной стороны, имеем понятие "single responsibility", что несомненно есть благо. Но в пределе такой подход означает - "один метод - один класс" (причём иногда именно так и происходит). Поэтому мой вопрос - о критериях выделения каких-то функций/методов в самостоятельные классы или, напротив, группировки их в один класс. И если с первым хоть как-то интуитивно понятно, то со вторым - полная каша в голове. Вот например, обсуждаем в соседней теме вопросы многоязычности приложения. Понятно, что весь функционал загрузки данных из XML лучше выделить в отдельный класс и наладить с ним простое как грабли взаимодействие: ты ему ID-шник, он тебе обратно - фразу (в моём случае массив фраз, но это неважно). Никаких вопросов. Но вот, например, есть функционал (также обсуждавшийся в этой теме выше) подбора словесных расшифровок для свойств персонажа, типа "дурак - умный - гениальный". Там уже не просто запрос варианта, но и некая логика, основанная на текущих значениях свойств персонажа, таким образом, он взаимодействует с классом Character. Его можно выделить в полностью самостоятельный класс, можно создать что-то типа CharacterModel и поместить туда вместе с другими методами обработки свойств персонажа... Или ещё пример. Для построения удобочитаемых фраз имеем алгоритм подстановки в полученный кусок текста имени собственного в нужном падеже. Он получает фразу из XML, плюс "знает" что должно быть в него подставлено вместо *$a1. Другой метод получает на входе оценку двух частей сложносочинённого предложения и выдаёт связующий союз (типа "ему охота, и ей охота" и "ему охота, но ей не хочется"). Вроде метод тоже языковой... Имеет смысл объединять их вместе или нет? Какая логика? Не чувствую её. |
|
|||||
Чувствую, скоро дойдет до того, что нужен будет метод, который должен будет определять, написать "поребрик" или "бордюр" в зависимости от текущей локации игрока)
Для игры, которая не имеет целью учить игрока русскому языку, всё это абсолютно излишне. Лучше сделать хороший и интересный гейплей, чем сделать скучную и унылую игру, но зато с правильным правописанием диалогов. Которые, по многочисленным личным наблюдениям, всё равно почти никто не читает. Диалоги в играх вообще должны сводиться к минимуму, это наводит на игрока скуку. Меньше текста, больше действия. Все предложения должны быть максимально короткими и простыми
__________________
Ко мне можно и нужно обращаться на ты) |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Цитата:
Цитата:
Пока сам надумал немного. Есть мысль №1 о том что поскольку условий может быть много, и точное их количество неизвестно для различных случаев, это должен быть некий массив, который будет передаваться на входе в метод-определитель доступности, чтобы он - метод - пробегал по всем и давал итоговое заключение на выходе: либо всё соблюдено, либо № элемента, который "не проходит". Мысль №2, что если у нас все характеристики персонажей (и не только персонажей) заданы через строковые идентификаторы типа "character.intelligence", то их можно и запихивать в массив с условиями, чтобы быстро обратиться за соответствующим значением. А вот всё остальное (запись и хранение целевых значений, операторов сравнения и т.п.) пока не находит ответов. |
|
|||||
Цитата:
Не приходилось такого делать, но представляю это себе примерно так: Диалог представляет из себя объект, приблизительно такого вида { dialog1: [{skillLevel: 1, textID: "walkInThePark"}, {skillLevel: 2, textID: "killDragon"}, { skillLevel: 100500, textID: "changeTheWorld" }] } 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)); // "Братуха, извини, но ты слишком крут для меня. Мне нечего тебе сказать" } }
__________________
Ко мне можно и нужно обращаться на ты) |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Ладно, это я уже в ответ троллить начал по части опции в диалоге в зависимости от скиллов.
На самом деле я тружусь над игрой в редком нынче жанре текстового квеста, как в Космических рейнджерах были. Мне явно пороху не хватит сейчас на более серьёзную реализацию. Поэтому вопрос качественных текстов имхо не менее важен, чем хорошие арты. Что это за форма записи, когда внутри квадратных скобок (типа литерал, да?) ещё и блоки фигурных? |
Часовой пояс GMT +4, время: 07:59. |
|
« Предыдущая тема | Следующая тема » |
|
|