Бампаю приколами.
И хули ты забыл в /b/ макака?
*parent используй. /thread
Тут быстрее.
Нет, подробнее.
> даунина не знает про родителя
Чёт вголос мда...
>AbstractObject
Назови просто Object или лучше Entity.
>AirplaneObject
Просто Airplane. Пользователи твоего фреймворка и так поймут что все классы должны наследоваться от Object, так везде. Это слово Object тут просто не нужно.
>AbstractController
Если у тебя есть классы с названиями содержащими "Controller", "Manager", "Provider" и так далее, это признак плохого дизайна. Нужно переработать его так, чтобы все классы отражали какие-то ощутимые сущности.
У тебя пиздец там какой-то напридуман. Лучше выкинь это всё и сформулируй задачу на русском языке.
Назови просто Object или лучше Entity.
>AirplaneObject
Просто Airplane. Пользователи твоего фреймворка и так поймут что все классы должны наследоваться от Object, так везде. Это слово Object тут просто не нужно.
>AbstractController
Если у тебя есть классы с названиями содержащими "Controller", "Manager", "Provider" и так далее, это признак плохого дизайна. Нужно переработать его так, чтобы все классы отражали какие-то ощутимые сущности.
У тебя пиздец там какой-то напридуман. Лучше выкинь это всё и сформулируй задачу на русском языке.
Зачем тебе этот петушиный язык? Пиши на Джаве, будь илитным
Вот, даже примерную картинку набросал. Как сделать без перекастования AbstractObject в AirplaneObject?
Нахуя тебе в AbstractObject "контроллеры" для всех подклассов? Это же абстрактный объект, он ничего не должен знать о потомках. Не логичнее ли связывать контроллеры с конкретными дочерними классами.
Он быстрее. Если тут у меня 400 обновляющихся объектов дают 20 фпс, то на джаве 20фпс дают уже 100 обновляющихся объектов.
Из всех контроллеров можно выделить что-то абстракное. Например, я хочу выделить метод update(), который будет почти одинаковым для всех контроллеров.
Во-первых нельзя полиморфный объект передавать по значению, потому что у тебя копируется только та часть объекта, которая принадлежит к AbstractObject, а все члены, добавленные в AirplanObject у тебя отвалятся, что приведет к распидорашиванию памяти. Передавать надо по ссылке (AbstractObject& object, double delta). Алсо, всегда вместо float используй double.
> Пользователи твоего фреймворка и так поймут что все классы должны наследоваться от Object
Нет. AbstractObject - это объекты, которые будут присутствовать в игре. У них есть свой Entity и SceneNode, а так же набор контроллеров.
shootRockets
>launchMissiles, ёба
>launchMissiles, ёба
Ебло стяни, валет
Алсо вот исправленная версия. Недоглядел, когда первую рисовал. Может, ты это имел ввиду?ссылка со здёздочкой же
у АНГЛОГОВОРЯЩЕГО пилорахи ВОЗМУЩЕНИЕ
И вместо точки ->, конечно же.
Кароче блядь вот финальный вариант.
> пилорахи
Бедолага ты успокойся
Ато по клавишам уже не попадаешь
Хуйня какаято
Нет, это по указателю. По указателю тоже можно, но не желательно.
Не тонем.
Чет всё равно непонятна за дизайн.
Если есть АiroplaneСontroller и АbstrractController, в схеме нет ограничения, что АiroplaneСontroller будет только у Аiroplane. Чому Controller - внешний по отношению к Object?
Почему не желательно?до сегодняшнего дня думал, что ссылка и указатель - одно и то же
А за этим я буду следить сам. Другого дизайна не придумал. Может я долбоёб и изобретаю велосипед, когда всё сделано за меня?
Controller - это контроллер для объекта. Каким он ещё должен быть?
Заканчиваются приколы. Аноны, выручайте.
Ты объясни языком что тебе сделать надо, а то хуету какую-то лепишь, в крестах так никто не пишет.
>400 обновляющихся объектов дают 20 фпс
Охуеть какая у тебя неповоротливая хуета. Ты бы там посидел, пооптимизировал обновлялки своих самолетов с ракетами.
Ты, конечно - мудак. Но книгу посоветую: Приемы объектно-ориентированного проектирования. Паттерны проектирования.
Э. Гамма, Р. Хелм, Р. Джонсон и Д. Влиссидес
И да, описывай задачу не как ебанутый первак, которой ток на пашкале то и может писать. (ну или бейск, лол)
А почему не реализовывать контроллер этот твой внутри объекта?
Откуда эта пикча? Это ж биологичка наша бывшая
А если мне потребуется 2 разных контроллера для 2 AirplaneObject'ов?
А хули ещё нужно? Я даже набросал схему. По ней даже я всё понял.
Ну так перегрузи метод внутри класса или задай параметр, который модифицирует поведение контроллера, иначе какой смысл в объектах, если ты для них внешнее апи создаёшь?
Задать параметр, который модифицирует поведение контроллера? А если мне нужно будет в корне поменять это поведение? Через case чтоли все возможные варианты перечислять? Нет, лучше подключить другой контроллер.
UML учи. OMT... ну и вообще. Вигерс в помощью. Проектируй сначала, потом гавнокодь.
Русским языком задачу поставь, на грушах. Всем похуй на твои контроллеры.
Тебе нужна техника под названием double-dispatching.
Блядь. Есть дерево, на котором растут яблоки и груши. Червяки могут залезать как в яблоко, так и в грушу. Но для яблок свои червяки, а для груш - другие. У червяков можно взять абстрактную часть и вынести в отдельный класс. То есть все они являются членами класса AbstractChervyack. Для яблок YablokoChervyack, для груш - GrooshaChervyack. Груши с яблоками от этого охуели и решили избавиться от червяков. У червяка с классом YablokoChervyack есть метод UitiIzYablocka, а у червяка с классом GrooshaChervyack есть метод UitiIzGrooshi. Яблоки и груши не хотят кастовать класс AbstractChervyack в классы YablokoChervyack и GrooshaChervyack. Они хотят, чтоб было всё сразу заебись. Как избавиться от этого каста?
Прочитав эту хуету с грушами, у меня только один вопрос: что нетак с
абстрактчервяк.уйти(абстрактовощ)
Соответственно если у тебя овощ главный
абстрактовощ.избавитьсяот(абстрактчерваяк)
Из груши червяк уходит спокойно на лапахони у него есть а из яблока - пританцовывая. Эти методы в корне разные. И только червяки знают, как избавить от себя яблоки и груши.
Ну где же вы? Даже на грушах объяснил, всё равно нихуя никто не понял.
Блядь, последний прикол. Тонем.
Виртуально унаследуй UitiIzFrukta для червяков
Был такой вариант. Я его даже реализовал. Но потом мне захотелось, чтобы у объекта было несколько контроллеров. Один его, например, крутит, а второй двигает вперёд. Можно объеденить в 1, но можно и так.
Так сделай методы крутить и двигать для червей. Какие проблемы?
Нет, я хочу большой гибкости.
просто system error какая то, иисус-жид, гитлер ненавидел жидов, он знает толк в траленге
Хуй поймешь что тебе надо. Объясняй нормально.
Хочу, чтобы объект контролировался извне контроллерами, которые лежат в его массиве контроллеров.
Делай простые методы для червей (крутить-вертеть или что тебе там надо). Вызывай их в методе контроллера. Метод контроллера вызывай извне.
А как мне передавать в контроллер нужного червя? Я могу передавать только абстрактного.
Ебт. Написал же про виртуальные методы. Если не знаешь, что это, почитай. А крутить-вертеть можно без наследования (все черви одинаково крутятся).
*Без виртуализации
Прочитал тред и обзмеился с опа-дауна.
Таким даугам, с мозгом засраным хуетой в духе ПОТЕРНЫ ЕТА КРУТА ЧЕМ БОЛЬЛЕ ПОТЕРНОВ ТЕМ ГИБЧИ И АРХИТИКТУРНИИ
AbstractSingletobProxyFactoryBean не забудь имплементировать для каждого объекта сцены, только потом не удивляйся, что фпс упадет с 20 до 10, такова цена за гибкость.
Такой говнокод никогда не сможет работать быстро, тольет plain old data является cache-friendly для процессора. Погугли про data oriented design, вот так делают серьезные игры с хорошим бытродействием, в dice например.
Таким даугам, с мозгом засраным хуетой в духе ПОТЕРНЫ ЕТА КРУТА ЧЕМ БОЛЬЛЕ ПОТЕРНОВ ТЕМ ГИБЧИ И АРХИТИКТУРНИИ
AbstractSingletobProxyFactoryBean не забудь имплементировать для каждого объекта сцены, только потом не удивляйся, что фпс упадет с 20 до 10, такова цена за гибкость.
Такой говнокод никогда не сможет работать быстро, тольет plain old data является cache-friendly для процессора. Погугли про data oriented design, вот так делают серьезные игры с хорошим бытродействием, в dice например.
А чо, схема опа имеет права на жизнь. Пусть с ней все будет криво и будет тормозить, но работать будет. От кустов, оп, ты тут не отделаешься. В твоем случае предпочти динамик касты, потому что у тебя слаботипизированно получилось.
Опять я. У меня возникла проблема. Есть класс AbstractObject. От него наследуется класс AirplaneObject. У класса AirplaneObject есть метод shootRockets();. В классе AbstractObject есть массивvector AbstractController'ов. С помощью наследования от этого класса я хочу создавать контроллеры, которые потом буду подключать к объектам. Что-то вроде скриптов лол. В данном случае -хочу создать контроллер, который будет вызывать метод shootRockets(); каждые 5 секунд. Как мне сделать, чтобы я мог получить доступ к объекту из контроллера? Могу добавить в метод update аргумент с типом AbstractObject, но каждый раз кастовать его в нужный тип я заебусь. В джаве есть прекрасная возможность - generic types. Пишешь T extends AbstractObject и при наследовании указываешь, какой тип должен быть у T. И он обязательно должен быть расширенным от AbstractObject. Как реализовать такое в C++? Прочитал про шаблоны - с ними такого сделать нельзя.