Здравствуйте, Нomunculus, Вы писали:
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
Ооо, опять земля.копайся.
Нет у вас никакого объекта "тряпка". И объекта "ветер" тоже нет.
ООП — оно про обязанности и поведение.
Поведение в данном случае одно: по состоянию мира в момент времени T и промежутку t построить состояние мира в момент времени T+t.
Всё. Физика именно так и работает. Флаг не обменивается никакими сообщениями с ветром и флагштоком.
Если вы посмотрите внутрь ПО по моделированию физических процессов (вроде https://www.comsol.com/), то там предмет исследования не будет ООП-объектом.
Так что если вы хотите моделировать поведение флага в окружающей среде — то надо физику.
А если вас интересуют практические вещи, то "физика" у вас будет ограничена набором макро-правил.
Очень хорошая серия на эту тему есть у Эрика Липперта.
То есть опять же, не будет у флага метода "отреагировать на ветер".
У вас будет набор правил вида "под действием ВЕТРА тканевые объекты начинают развеваться", "мокрые объекты не могут развеваться", "под воздействием ВОДЫ тканевые объекты становятся мокрыми".
Каждое правило будет объектом определённого класса; у вас будет тот самый главный GodObject, который трансформирует мир под действием этих правил.
Так что если игрок кастует "заклинание штормового ветра", в локации начинает "действовать ВЕТЕР" и срабатывают все правила про действие ветра на все предметы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Нomunculus, Вы писали:
Н>Вот проектируем мы объект, все чтоб по красоте было, удобно, инкапсуляшно, ооп-шно.
Я бы применил для этого ECS.
Ветер это компонент некой entity, которая описывает область пространства.
Тряпки это entity, имеющие в себе компонент, описывающий их тряпочные параметры.
Колыхатель тряпок это система, которая для каждой тряпки определяет область пространства, где она находится, и если в этой области есть ветер, то соответственно колыхает тряпку.
В играх это отлично работает для подобных задач.
O>>Тряпка состоит из Molecule[], которые .Impact(молекула ветра), после чего тряпка пересчитывает свою геометрию. Н>То есть при смене направления ветра мы должны каждой тряпке это сказать?
В реальности же им узнать это больше неоткуда, gismeteo.ru они не читают.
Здравствуйте, Нomunculus, Вы писали:
Н>Вопрос в том кто про что должен знать. Расчеты трепыхания тряпки должны быть внутри тряпки? Но тогда тряпка должна знать о внешнем мире. И это криво
Тряпка — субъект.
GodObject — манагер, который всем рулит
Тебе нужен объект КолыхательТряпки, который принимает коллекцию тряпок и занимается развеванием.
Будет ли он создаваться для каждого экземпляра тряпки или один на всех — зависит от задач.
Возможно для каждого уникального класса Тряпки нужен свой Колыхатель.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Нomunculus, Вы писали:
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
Ветер должен быть методом объекта тряпки.
И объект-хозяин (не обязательно сцена) должен при смене переменной "ветер"
у всех своих объектов (в том числе и не тряпок) дёрнуть метод "ветер".
Ну как Виджет примерно, когда ты ему resize делаешь.
Здравствуйте, Нomunculus, Вы писали:
Н>Не, разумеется, проблемы нет. Но блин чо-то вся красота ООП-ти летит в задницу. В реальности тряпки не знают ничего про то, где они находятся.
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
ООП не цель, а инструмент, потому, вопрос тут другой.
Если от программы ожидается симуляция физического процесса, то, казалось бы, следует отталкиваться от математической модели процесса, а не от объектной. Выбирая не ту модель, мы сильно рискуем не получить нужный результат. А для матмодели у нас и ветер не ветер и тряпка не тряпка. Размеры уйдут в координаты mesh-а, масса, плотность, гибкость и все такое в параметры формулы, описывающей движение узлов mesh-а. Ветер может быть задан векторным полем. В общем, сообщения между ветром и тряпкой тут вообще зачем, какую задачу они могли бы решать? В чем тут красота и удобство ООП?
ООП хорош, когда нам надо обобщить некий результат взаимодействия объектов, при множестве разных типов объектов и их поведений. Например, тряпка на ветру делает "Хлоп-хлоп", море — "ЩЩЩЩЩЩ", а гвоздь — молчит. Тряпка при воздействии молотком молчит, море — "буль", а гвоздь — "тюк". Вот тут ООП рулит.
Здравствуйте, Нomunculus, Вы писали:
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
Точно не в тряпку иначе ты приходишь к тому, что ветер потому, что листья на деревьях шевелятся.
Здравствуйте, Нomunculus, Вы писали:
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
Во-первых, определись, ты будешь моделировать частицы или эмерджентое явление? Если частицы, то ветер возникнет сам собой как перемещение частиц воздуха. Их физическое воздействие на частицы тряпки обеспечит и колыхание тряпки, и её перемещение из-за ветра. Но моделировать частицы через ООП жирно, слишком много накладных расходов. Обычно ООП моделирует как раз таки эмерджентные явления и объекты, или являются контейнерами для управления эмерджентными свойствами массивов частиц. У тебя будет объект тряпка и объект ветер. ООП — это не только про инкапсуляцию в объектах данных и поведения, но важная роль отводится и взаимодействию объектов. Алан Кэй, отец ООП, реализовал взаимодействие объектов через события. Например, ветер дует, это вызов метода. Дуновение влияет на тряпку. Значит, метод дуновения должен генерировать событие дуновения с параметром сила и направление. Фабрика тряпки при её создании подписывает тряпку на событие дуновения, в обработчике реализуется поведение тряпки на событие дуновения с соотв. силой и направлением.
Обрати внимание, ветер, генерируя событие дуновения, не знает, кто и сколько объектов подписаны на него. Это паттерн Наблюдатель.
Кури книгу банды четырех про ООП дизайн и паттерны, а также другие книги про паттерны, там ты найдешь все ответы. Ещё рекомендую thinking in patterns Шэллоуэя, она учит думать в парадигме ООП.
Ну, и куда сунуть ветер и тряпку. Это например объект сцена, или игра, или мир.
И кстати этот мир-обьект, паттерн Синглтон, тоже генерирует события, типа гейм стартед или гейм овер, и на них подписан рендерер меню игры. Это классика ООП-парадигмы MVC.
Здравствуйте, Нomunculus, Вы писали: Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
Я всегда всем говорю, что в программировании мозгов не нужно, но все упорно это отрицают и пытаются умствовать. Программирование это как чукотская песня — что вижу, то и пою. Если у тебя ветер не вписывается в тряпку, значит модель не полна и ее нужно дополнять. Дополняем модель какой-нибудь фигней, которая сломает существующее положение дел и смотрим.
В данном случае дополняем модель двумя параллельными близко стоящими зданиями и перпендикулярным им ветром. Даже чукче понятно, что каков бы не был ветер в сцене, между домами он параллелен домам. Соответственно нужный нам для тряпки ветер это не ветер сцены, а свойство точки на сцене. Собственно, как и тряпка.
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, T4r4sB, Вы писали:
Н>>Далее для физической симуляции тряпки мы понимаем, что нам нужен… ВЕТЕР!!
TB>Тряпке не надо знать про ветер TB>Тряпка не двигается сама по себе, её двигает бог (GodObject), а он знает и тряпку и ветер
+1
А у тряпки может быть свойство bool canFlutter() или интерфейс IРазвевабельное IFlutterable.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Osaka, Вы писали:
Н>>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР??? O>Тряпка состоит из Molecule[], которые .Impact(молекула ветра), после чего тряпка пересчитывает свою геометрию.
Опасный совет — щас он пронаследует молекулу, у нас же ООП — значит надо всё от всего наследовать, впихнет туда через DI сто зависимостей, и скажет что де идея не палит, т.к. модель не влазит в память.
Здравствуйте, Нomunculus, Вы писали:
Н>Вот проектируем мы объект, все чтоб по красоте было, удобно, инкапсуляшно, ооп-шно.
ооп-шно не надо. вообще тащить везде ооп это какое-то старперство из 90х.
не приведено никаких требований по симуляции — что должно быть результатом симуляции?
в первую очередь надо решить задачу математически, отталкиваясь от того, какие данные нужны на выходе.
выделить сущности (данные, не объекты!) и взаимоотношения между ними (операции).
а потом прикинуть как это все удобнее всего накинуть на тот ооп-язык, который есть. но удобнее для решения задачи, а не для удовлетворения "ооп-шности".
наверное, какое-то дискретное изменение величины ветра должно триггерить изменения состояния тряпки, на выходе получаем снапшот сцены.
как-то очевидно, что с математической точки зрения это считается по формулам (некий внешний вычислитель), тряпка и ветер для которых это входные данные.
поэтому ни тряпка ни ветер друг про друга ничего не знают и смысла им знать нет.
Вот проектируем мы объект, все чтоб по красоте было, удобно, инкапсуляшно, ооп-шно.
А объект этот — тряпка. Не в смысле слабохарактерного мужчины, а в прямом смысле — кусок ткани.
И хотим мы чтоб тряпка эта была ну прям как взаправдышная
Ну что мы в объект тряпки сунем? Ну, очевидно, какие-то физические и геометрические свойства, размеры, массу, плотность, гибкость и так далее. Все это — внутри тряпки. Шикарно и инкапсуляшно.
Далее для физической симуляции тряпки мы понимаем, что нам нужен… ВЕТЕР!! Но ветер блин вообще нифига не в тряпке. А без ветра вся физическая симуляция превращается в обвисшее недоразумение.
Где ж нам взять ветер? Ведь это должно быть свойство сцены. И если в сцене миллион тряпок, то поменяв одну единственную цифирьку в векторе направления ветра, все миллион тряпок должны начать двигаться иначе.
Неужели в каждой тряпке должна быть ссылка на сцену? Мы каждой тряпке должны это указывать?
Не, разумеется, проблемы нет. Но блин чо-то вся красота ООП-ти летит в задницу. В реальности тряпки не знают ничего про то, где они находятся.
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
Тряпка состоит из Molecule[], которые .Impact(молекула ветра), после чего тряпка пересчитывает свою геометрию.
Здравствуйте, Osaka, Вы писали:
Н>>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР??? O>Тряпка состоит из Molecule[], которые .Impact(молекула ветра), после чего тряпка пересчитывает свою геометрию.
То есть при смене направления ветра мы должны каждой тряпке это сказать?
Здравствуйте, Нomunculus, Вы писали:
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
А ты поступи, как Эйнштейн. Он же списал гравитационное поле на искажение пространства. А ты на искажение пространства ветер спиши. Вот так, ветра как такового нет, есть особенности законов геометрии, которые включают в себя действие ветра.
Здравствуйте, Нomunculus, Вы писали:
Н>Вопрос в том кто про что должен знать. Расчеты трепыхания тряпки должны быть внутри тряпки? Но тогда тряпка должна знать о внешнем мире. И это криво
Ну или внешний мир должен знать про все тряпки, которые он трепещит.
Или у них должны быть pub-sub отношения: тряпка должна подписываться на трепыхания, производимые внешним миром.
Как бы то ни было, знать друг о друге они должны. Возможно путем знакомства в рантайме.
Здравствуйте, T4r4sB, Вы писали:
TB>Тряпка не двигается сама по себе, её двигает бог (GodObject), а он знает и тряпку и ветер
Работать будет, пока у программиста не переполнится голова, которая должна помнить о всех объектах.
То есть, довольно скоро. ООП для того и изобрели, чтобы уменьшить окно, в которое нужно смотреть одномоментно.
Здравствуйте, Нomunculus, Вы писали:
Н>Вот проектируем мы объект, все чтоб по красоте было, удобно, инкапсуляшно, ооп-шно.
Н>А объект этот — тряпка. Не в смысле слабохарактерного мужчины, а в прямом смысле — кусок ткани. Н>И хотим мы чтоб тряпка эта была ну прям как взаправдышная
Н>Ну что мы в объект тряпки сунем? Ну, очевидно, какие-то физические и геометрические свойства, размеры, массу, плотность, гибкость и так далее. Все это — внутри тряпки. Шикарно и инкапсуляшно.
Н>Далее для физической симуляции тряпки мы понимаем, что нам нужен… ВЕТЕР!! Но ветер блин вообще нифига не в тряпке. А без ветра вся физическая симуляция превращается в обвисшее недоразумение.
Н>Где ж нам взять ветер? Ведь это должно быть свойство сцены. И если в сцене миллион тряпок, то поменяв одну единственную цифирьку в векторе направления ветра, все миллион тряпок должны начать двигаться иначе.
Н>Неужели в каждой тряпке должна быть ссылка на сцену? Мы каждой тряпке должны это указывать? Н>Не, разумеется, проблемы нет. Но блин чо-то вся красота ООП-ти летит в задницу. В реальности тряпки не знают ничего про то, где они находятся.
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
Как вариант: ветер получает от тряпки ее текущую форму и передает тряпке поле сил действующее на нее со стороны ветра, тряпка опять меняет форму и передает ее ветру. И так по кругу, при каждом такте от таймера
А сколько их, этих ветров? Он, ненароком, не один на все тряпки? Если один, синглтон, то пусть все тряпки знают про него, и в методе "nextFrame" (когда идет пересчет мира) принимают его во внимание.
Если их много, передай его тряпке в конструкторе ("dependency injection") или воспользуйтся каким-нибудь ветер-локатором... тьфу, сервис-локатором.
Здравствуйте, Нomunculus, Вы писали:
Н>Ну что мы в объект тряпки сунем? Ну, очевидно, какие-то физические и геометрические свойства, размеры, массу, плотность, гибкость и так далее. Все это — внутри тряпки. Шикарно и инкапсуляшно.
Это если заниматься инкапсулизмом. А для ООП нужно определиться, какое решение будете моделивать. Т.е. вам нужна вычислительная модель до, а не после.
Какое состояние, какие методы должен поддерживать этот класс зависит от того, как вы смоделировали решение. Например, это может быть двумерный или трехмерный массив точек и дополнительные параметры. А ветер это будет свойство сцены.
Н>Неужели в каждой тряпке должна быть ссылка на сцену? Мы каждой тряпке должны это указывать? Н>Не, разумеется, проблемы нет. Но блин чо-то вся красота ООП-ти летит в задницу. В реальности тряпки не знают ничего про то, где они находятся.
Здравствуйте, Osaka, Вы писали:
Н>>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР??? O>Тряпка состоит из Molecule[], которые .Impact(молекула ветра), после чего тряпка пересчитывает свою геометрию.
Как будет пересчитываться геометрия — нужно определиться до того, как вводим объекты ветер и тряпка. А когда определились — тогда и вводим абстракции.
Может окажется так, что не будет никакой тряпки, а будет просто игровой объект с капабилити 'точки' и 'свойства', его мы отдаем калькулятору геометрии, и применяем полученные изменения.
Здравствуйте, Нomunculus, Вы писали:
Н>>>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР??? O>>Тряпка состоит из Molecule[], которые .Impact(молекула ветра), после чего тряпка пересчитывает свою геометрию.
Н>То есть при смене направления ветра мы должны каждой тряпке это сказать?
А как вы хотели? Если тряпка из молекул, то нужно пересчитать геометрию.
Здравствуйте, Нomunculus, Вы писали:
Н>Вопрос в том кто про что должен знать. Расчеты трепыхания тряпки должны быть внутри тряпки? Но тогда тряпка должна знать о внешнем мире. И это криво
Это зависит от вашего решения. На самом деле важно решение с минимальной сложностью и высокой maintainability.
Простые вычисления ветра и никто кроме тряпки с ветром не взаимодействует — суньте в тряпку.
Появятся еще объекты, которые гнутся под ветром — добавьте класс ветер.
Вычисления сложные, типа дифуры, новье-стокса — выделите класс WindCalculator, а тряпка и ветер будут просто набор капабилитей.
Можно даже сделать тряпку тряпкой, и не хранить в ней никаких точек, пусть отрисовывается полу-рандомный трепыхающийся объект. Тоже как вариант.
Важно, что у вас пока нет решения, а вы уже инкапсулизмом занимаетесь
Место ООП — перевод готового решения в код и управление сложностью итогового кода.
Здравствуйте, Нomunculus, Вы писали: Н>Где ж нам взять ветер? Ведь это должно быть свойство сцены. И если в сцене миллион тряпок, то поменяв одну единственную цифирьку в векторе направления ветра, все миллион тряпок должны начать двигаться иначе.
ветер сам по себе сложный обьект. это поле — то бишь 3д вектор в каждый точке, который как-то меняется со временем. он может, например, уметь интерполирвать между известными точными знаниями чтобы не держать вектор для точки или просто сбрасываться в константу везде. и доступ к нему можно да просто через синглтон сделать, если неохота никуда пробрасывать. вот и вся проблема.
тряпка имеет геометрию и свойства геометрии. есть физический движок, который умеет геометрию обсчитывать с учетом того же ветра. сама тряпка ничего не считает
Тряпка это физическая система, в ней есть внутренние процессы, есть процессы вызванные внешними (граничиными) силами/условиями. Ветер одно из них, другое может быть человек, который эту тряпку носит или солнце, которое ее сушит в каких-то местах и вызывает градиент плотности (в первом приближении), от чего происходит какая-то динамика. Соответственно, ветер в каком-то сцен менеджере проходится по всем тряпкам и, если взаимодействует с ними, выставляя скорости / импульсы частиц/треугольников, с которыми он взамодействует.
Здравствуйте, Нomunculus, Вы писали:
Н>Вот проектируем мы объект, все чтоб по красоте было, удобно, инкапсуляшно, ооп-шно.
Н>А объект этот — тряпка. Не в смысле слабохарактерного мужчины, а в прямом смысле — кусок ткани. Н>И хотим мы чтоб тряпка эта была ну прям как взаправдышная
Н>Ну что мы в объект тряпки сунем? Ну, очевидно, какие-то физические и геометрические свойства, размеры, массу, плотность, гибкость и так далее. Все это — внутри тряпки. Шикарно и инкапсуляшно.
Н>Далее для физической симуляции тряпки мы понимаем, что нам нужен… ВЕТЕР!! Но ветер блин вообще нифига не в тряпке. А без ветра вся физическая симуляция превращается в обвисшее недоразумение.
Н>Где ж нам взять ветер? Ведь это должно быть свойство сцены. И если в сцене миллион тряпок, то поменяв одну единственную цифирьку в векторе направления ветра, все миллион тряпок должны начать двигаться иначе.
Н>Неужели в каждой тряпке должна быть ссылка на сцену? Мы каждой тряпке должны это указывать? Н>Не, разумеется, проблемы нет. Но блин чо-то вся красота ООП-ти летит в задницу. В реальности тряпки не знают ничего про то, где они находятся.
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
Здравствуйте, Нomunculus, Вы писали:
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
Потому что объекты реального мира это не всегда реальные классы. Тряпка описывается некоторыми точками в пространстве, а ветер это некоторый алгоритм трансформаций над этими точками. В принципе, это может быть отдельный класс, а может быть и простая функция.
Некоторый псевдокод
class Tryapka:
vector dots
color c = RED
transform(Transformation as alg) -> bool
foreach dot in dots
alg(dot)
class Veter implements Transformation:
define call(dot)
apply dx, dy on dot
main -> void
Transformation alg = Veter(2m/s)
Tryapka traypka
traypka.transform(alg)
Можно не использовать Veter как класс, а просто как функцию которая принимает массив точек. В сложном случае всё скатится до двойной диспетчеризации и шаблона Visitor
P.S.Поищи сообщения Sinclar, он много дельного писал на тему ООП.
Здравствуйте, Sinclair, Вы писали:
S>То есть опять же, не будет у флага метода "отреагировать на ветер".
Но флаг как некоторый объект в мире будет присутствовать или это будет набор данных который задаёт геометрические параметры внутри сцены?
Здравствуйте, Нomunculus, Вы писали:
Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
Куда суётся — туда и суйте Вы формулируете вопрос таким образом, как будто есть сложности с поиском решения. На самом деле проблема с вашей постановкой задачи. Процесс дизайна — это построение системы неравенств, которая описывает разные аспекты "как мы точно делать не будем". Чем больше требований, тем больше неравенств, тем более чёткая картина получается. В какой-то момент всё приходит к тому, что в систему укладывается буквально полтора решения, плюсы и минусы которых совсем не очевидны — и из которых можно выбрать любое.
Требования, которые нужно учитывать — это и критерий успеха (как выглядит успех, сколько времени займёт решение, уложимся ли в бюджет), и жизненный цикл (это мы развлекаемся за завтраком — и дальше всё, или пишем коммерческий игровой движок, который нужно будет поддерживать и развивать), и т.д. И где-то там на 1482-м месте технические вопросы типа "знает ли тряпка про ветер, или ветер про тряпку"
Есть более простая задача — при объектно-ориентированном дизайне геометрических фигур — должен ли прямоугольник наследоваться от квадрата, или квадрат от прямоугольника, или никто ни от кого?
Здравствуйте, Kernan, Вы писали: K>Но флаг как некоторый объект в мире будет присутствовать или это будет набор данных который задаёт геометрические параметры внутри сцены?
В упрощённой модели — будет. Но это будет "anemic object", просто коллекция свойств с наследованием. То есть, флаг будет относиться к "тканевым объектам", а меч — к "оружию".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Нomunculus, Вы писали:
Н>Вот проектируем мы объект, все чтоб по красоте было, удобно, инкапсуляшно, ооп-шно. Н>А объект этот — тряпка. Не в смысле слабохарактерного мужчины, а в прямом смысле — кусок ткани. Н>И хотим мы чтоб тряпка эта была ну прям как взаправдышная Н>Ну что мы в объект тряпки сунем? Ну, очевидно, какие-то физические и геометрические свойства, размеры, массу, плотность, гибкость и так далее. Все это — внутри тряпки. Шикарно и инкапсуляшно.
Н>Далее для физической симуляции тряпки мы понимаем, что нам нужен… ВЕТЕР!! Но ветер блин вообще нифига не в тряпке. А без ветра вся физическая симуляция превращается в обвисшее недоразумение. Н>Где ж нам взять ветер? Ведь это должно быть свойство сцены. И если в сцене миллион тряпок, то поменяв одну единственную цифирьку в векторе направления ветра, все миллион тряпок должны начать двигаться иначе. Н>Неужели в каждой тряпке должна быть ссылка на сцену? Мы каждой тряпке должны это указывать? Н>Не, разумеется, проблемы нет. Но блин чо-то вся красота ООП-ти летит в задницу. В реальности тряпки не знают ничего про то, где они находятся. Н>Вопрос на миллион — КУДА СУНУТЬ ВЕТЕР???
Да вроде ничего сложного с ветром
using System.Collections.Generic;
using System.Numerics;
interface ISumulation
{
void Step();
}
abstract class BasePhysicalObject: ISumulation
{
public Vector3 Position { get; protected set; }
public float Mass { get; }
Matrix4x4 positionTransform = Matrix4x4.Identity;
protected void AddPositionTransform(Matrix4x4 transform)
{
positionTransform = positionTransform * transform;
}
public abstract void ApplyWind(Vector3 wind);
public void Step()
{
Position = Vector3.Transform(Position, positionTransform);
}
}
class Rag: BasePhysicalObject
{
public override void ApplyWind(Vector3 wind)
{
this.AddPositionTransform(/* преобразование ветра в нужную матрицу в зависимости от позиции, массы и всего остального*/);
}
}
class SimulationEnvironment: ISumulation
{
private List<BasePhysicalObject> objects = new();
public IReadOnlyList<BasePhysicalObject> Objects => objects.AsReadOnly();
public Vector3 Wind { get; set; }
public void AddObject(BasePhysicalObject o) => objects.Add(o);
public void Step()
{
foreach (var o in objects)
{
// ...
o.ApplyWind(Wind);
// ...
o.Step();
}
}
}
Как раз задачи симуляции независимых объектов решаются хорошо в рамках ООП.
плохо начинается тогда, когда надо в рамках "сцены" взаимодействовать между собой. Например в рамках симуляции надо просчитывать коллизии. Этот расчет будет разным в зависимости от разных пары типов объектов в сцене. Причем сам расчет будет зависеть от некоторых внутренних свойств объектов. В классическом Java-подобном ООП это красиво никак не сделать. Или визиторы городить, или код копипастить.
В современном C# это можно сделать с помощью паттерн-матчинга, но все равно накладывает ограничения на изменения типов объектов в будущем (ломает принцип OCP).
Здравствуйте, Нomunculus, Вы писали:
Н>То есть при смене направления ветра мы должны каждой тряпке это сказать?
А почему нет? Свойства тряпки — это её текстура (цвет, фактура волокон, всякие пятна-дырки-подпалины). А вот ветер уже является модификатором. Причем если упороться по архитектуре, то модификатор не будет сам менять тряпку, ведь источников ветра может быть несколько: ветер природный (ambient), его отражение от препятствий на сцене, локальный ветер от вентилятора, который есть на нашей сцене (или винт самолёта, турбина и т.п.). Будет внешний объект-композер, который сможет посчитать равнодействующую этих модификаторов и применить к тряпке (и тут мы можем разделить отдельно модели, и отдельно вью-модели той же тряпки, ветра и т.п.)
Здравствуйте, alpha21264, Вы писали:
A>Ветер должен быть методом объекта тряпки.
Не обязательно. Особенно если мы говорим про анемичный подход — зачем сущности "тряпка" сооружать усложнение с ветром? его порывы, направление, сила (которые могут быть меняющимися по разным принципам, исходя из контекста а-ля "открыли форточку — закрыли форточку")
Здравствуйте, Mr.Delphist, Вы писали:
Н>>То есть при смене направления ветра мы должны каждой тряпке это сказать?
MD>А почему нет? Свойства тряпки — это её текстура (цвет, фактура волокон, всякие пятна-дырки-подпалины). А вот ветер уже является модификатором. Причем если упороться по архитектуре, то модификатор не будет сам менять тряпку, ведь источников ветра может быть несколько: ветер природный (ambient), его отражение от препятствий на сцене, локальный ветер от вентилятора, который есть на нашей сцене (или винт самолёта, турбина и т.п.). Будет внешний объект-композер, который сможет посчитать равнодействующую этих модификаторов и применить к тряпке (и тут мы можем разделить отдельно модели, и отдельно вью-модели той же тряпки, ветра и т.п.)
Мне нравится идея. Как при расчёте света, только ещё интереснее, потому что ветер — это движение воздуха с его потоками, местами простоя и завихрениями и ни в 2D а в 3D (если время отбросить ).
Здравствуйте, Нomunculus, Вы писали: Н>А объект этот — тряпка. Н>Вопрос — КУДА СУНУТЬ ВЕТЕР???
Ветер это "контроллер", он модифицирует внутреннее состояние "модели" тряпка. Чтобы инкапсулировать код "ветра" на все модели надо задать интерфейс "модель качаемая ветром", но это наверное будет нереально, т.к. "тряпки" и "не тряпки" качаются сильно по разному и контроллер "ветер" получит для каждой существенно разной модели свою реализацию метода. Для метода "ветра качающего тряпку" надо задать интерфейс доступа к внутреннему состоянию "модель тряпки качаемая ветром".
===
