Вот проектируем мы объект, все чтоб по красоте было, удобно, инкапсуляшно, ооп-шно.
А объект этот — тряпка. Не в смысле слабохарактерного мужчины, а в прямом смысле — кусок ткани.
И хотим мы чтоб тряпка эта была ну прям как взаправдышная
Ну что мы в объект тряпки сунем? Ну, очевидно, какие-то физические и геометрические свойства, размеры, массу, плотность, гибкость и так далее. Все это — внутри тряпки. Шикарно и инкапсуляшно.
Далее для физической симуляции тряпки мы понимаем, что нам нужен… ВЕТЕР!! Но ветер блин вообще нифига не в тряпке. А без ветра вся физическая симуляция превращается в обвисшее недоразумение.
Где ж нам взять ветер? Ведь это должно быть свойство сцены. И если в сцене миллион тряпок, то поменяв одну единственную цифирьку в векторе направления ветра, все миллион тряпок должны начать двигаться иначе.
Неужели в каждой тряпке должна быть ссылка на сцену? Мы каждой тряпке должны это указывать?
Не, разумеется, проблемы нет. Но блин чо-то вся красота ООП-ти летит в задницу. В реальности тряпки не знают ничего про то, где они находятся.
Здравствуйте, T4r4sB, Вы писали:
Н>>Далее для физической симуляции тряпки мы понимаем, что нам нужен… ВЕТЕР!!
TB>Тряпке не надо знать про ветер TB>Тряпка не двигается сама по себе, её двигает бог (GodObject), а он знает и тряпку и ветер
+1
А у тряпки может быть свойство bool canFlutter() или интерфейс IРазвевабельное IFlutterable.
_____________________
С уважением,
Stanislav V. Zudin
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
Тряпка состоит из Molecule[], которые .Impact(молекула ветра), после чего тряпка пересчитывает свою геометрию.
Здравствуйте, Osaka, Вы писали:
Н>>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР??? O>Тряпка состоит из Molecule[], которые .Impact(молекула ветра), после чего тряпка пересчитывает свою геометрию.
То есть при смене направления ветра мы должны каждой тряпке это сказать?
Здравствуйте, Нomunculus, Вы писали:
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
А ты поступи, как Эйнштейн. Он же списал гравитационное поле на искажение пространства. А ты на искажение пространства ветер спиши. Вот так, ветра как такового нет, есть особенности законов геометрии, которые включают в себя действие ветра.
O>>Тряпка состоит из Molecule[], которые .Impact(молекула ветра), после чего тряпка пересчитывает свою геометрию. Н>То есть при смене направления ветра мы должны каждой тряпке это сказать?
В реальности же им узнать это больше неоткуда, gismeteo.ru они не читают.
Здравствуйте, Нomunculus, Вы писали:
Н>Вопрос в том кто про что должен знать. Расчеты трепыхания тряпки должны быть внутри тряпки? Но тогда тряпка должна знать о внешнем мире. И это криво
Ну или внешний мир должен знать про все тряпки, которые он трепещит.
Или у них должны быть pub-sub отношения: тряпка должна подписываться на трепыхания, производимые внешним миром.
Как бы то ни было, знать друг о друге они должны. Возможно путем знакомства в рантайме.
Здравствуйте, Нomunculus, Вы писали:
Н>Вопрос в том кто про что должен знать. Расчеты трепыхания тряпки должны быть внутри тряпки? Но тогда тряпка должна знать о внешнем мире. И это криво
Тряпка — субъект.
GodObject — манагер, который всем рулит
Тебе нужен объект КолыхательТряпки, который принимает коллекцию тряпок и занимается развеванием.
Будет ли он создаваться для каждого экземпляра тряпки или один на всех — зависит от задач.
Возможно для каждого уникального класса Тряпки нужен свой Колыхатель.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Нomunculus, Вы писали:
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
Ветер должен быть методом объекта тряпки.
И объект-хозяин (не обязательно сцена) должен при смене переменной "ветер"
у всех своих объектов (в том числе и не тряпок) дёрнуть метод "ветер".
Ну как Виджет примерно, когда ты ему resize делаешь.
Здравствуйте, Нomunculus, Вы писали:
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
Во-первых, определись, ты будешь моделировать частицы или эмерджентое явление? Если частицы, то ветер возникнет сам собой как перемещение частиц воздуха. Их физическое воздействие на частицы тряпки обеспечит и колыхание тряпки, и её перемещение из-за ветра. Но моделировать частицы через ООП жирно, слишком много накладных расходов. Обычно ООП моделирует как раз таки эмерджентные явления и объекты, или являются контейнерами для управления эмерджентными свойствами массивов частиц. У тебя будет объект тряпка и объект ветер. ООП — это не только про инкапсуляцию в объектах данных и поведения, но важная роль отводится и взаимодействию объектов. Алан Кэй, отец ООП, реализовал взаимодействие объектов через события. Например, ветер дует, это вызов метода. Дуновение влияет на тряпку. Значит, метод дуновения должен генерировать событие дуновения с параметром сила и направление. Фабрика тряпки при её создании подписывает тряпку на событие дуновения, в обработчике реализуется поведение тряпки на событие дуновения с соотв. силой и направлением.
Обрати внимание, ветер, генерируя событие дуновения, не знает, кто и сколько объектов подписаны на него. Это паттерн Наблюдатель.
Кури книгу банды четырех про ООП дизайн и паттерны, а также другие книги про паттерны, там ты найдешь все ответы. Ещё рекомендую thinking in patterns Шэллоуэя, она учит думать в парадигме ООП.
Ну, и куда сунуть ветер и тряпку. Это например объект сцена, или игра, или мир.
И кстати этот мир-обьект, паттерн Синглтон, тоже генерирует события, типа гейм стартед или гейм овер, и на них подписан рендерер меню игры. Это классика ООП-парадигмы MVC.
Здравствуйте, T4r4sB, Вы писали:
TB>Тряпка не двигается сама по себе, её двигает бог (GodObject), а он знает и тряпку и ветер
Работать будет, пока у программиста не переполнится голова, которая должна помнить о всех объектах.
То есть, довольно скоро. ООП для того и изобрели, чтобы уменьшить окно, в которое нужно смотреть одномоментно.
Здравствуйте, Нomunculus, Вы писали:
Н>Вот проектируем мы объект, все чтоб по красоте было, удобно, инкапсуляшно, ооп-шно.
Я бы применил для этого ECS.
Ветер это компонент некой entity, которая описывает область пространства.
Тряпки это entity, имеющие в себе компонент, описывающий их тряпочные параметры.
Колыхатель тряпок это система, которая для каждой тряпки определяет область пространства, где она находится, и если в этой области есть ветер, то соответственно колыхает тряпку.
В играх это отлично работает для подобных задач.
Здравствуйте, Нomunculus, Вы писали:
Н>Вот проектируем мы объект, все чтоб по красоте было, удобно, инкапсуляшно, ооп-шно.
Н>А объект этот — тряпка. Не в смысле слабохарактерного мужчины, а в прямом смысле — кусок ткани. Н>И хотим мы чтоб тряпка эта была ну прям как взаправдышная
Н>Ну что мы в объект тряпки сунем? Ну, очевидно, какие-то физические и геометрические свойства, размеры, массу, плотность, гибкость и так далее. Все это — внутри тряпки. Шикарно и инкапсуляшно.
Н>Далее для физической симуляции тряпки мы понимаем, что нам нужен… ВЕТЕР!! Но ветер блин вообще нифига не в тряпке. А без ветра вся физическая симуляция превращается в обвисшее недоразумение.
Н>Где ж нам взять ветер? Ведь это должно быть свойство сцены. И если в сцене миллион тряпок, то поменяв одну единственную цифирьку в векторе направления ветра, все миллион тряпок должны начать двигаться иначе.
Н>Неужели в каждой тряпке должна быть ссылка на сцену? Мы каждой тряпке должны это указывать? Н>Не, разумеется, проблемы нет. Но блин чо-то вся красота ООП-ти летит в задницу. В реальности тряпки не знают ничего про то, где они находятся.
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
Как вариант: ветер получает от тряпки ее текущую форму и передает тряпке поле сил действующее на нее со стороны ветра, тряпка опять меняет форму и передает ее ветру. И так по кругу, при каждом такте от таймера
Здравствуйте, Нomunculus, Вы писали:
Н>Не, разумеется, проблемы нет. Но блин чо-то вся красота ООП-ти летит в задницу. В реальности тряпки не знают ничего про то, где они находятся.
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
ООП не цель, а инструмент, потому, вопрос тут другой.
Если от программы ожидается симуляция физического процесса, то, казалось бы, следует отталкиваться от математической модели процесса, а не от объектной. Выбирая не ту модель, мы сильно рискуем не получить нужный результат. А для матмодели у нас и ветер не ветер и тряпка не тряпка. Размеры уйдут в координаты mesh-а, масса, плотность, гибкость и все такое в параметры формулы, описывающей движение узлов mesh-а. Ветер может быть задан векторным полем. В общем, сообщения между ветром и тряпкой тут вообще зачем, какую задачу они могли бы решать? В чем тут красота и удобство ООП?
ООП хорош, когда нам надо обобщить некий результат взаимодействия объектов, при множестве разных типов объектов и их поведений. Например, тряпка на ветру делает "Хлоп-хлоп", море — "ЩЩЩЩЩЩ", а гвоздь — молчит. Тряпка при воздействии молотком молчит, море — "буль", а гвоздь — "тюк". Вот тут ООП рулит.
А сколько их, этих ветров? Он, ненароком, не один на все тряпки? Если один, синглтон, то пусть все тряпки знают про него, и в методе "nextFrame" (когда идет пересчет мира) принимают его во внимание.
Если их много, передай его тряпке в конструкторе ("dependency injection") или воспользуйтся каким-нибудь ветер-локатором... тьфу, сервис-локатором.
