Так и происходит в играх с простой механикой, диктуемой как раз принципом декомпозиции. Но в реальной жизни-то это не так. Управление одним солдатом заключается в стрельбе и рукопашном бое, командир батальона управляет тактикой солдат по рации, а генерал, командующий армией, диктует стратегические приказы стенографистке (и при этом минимум 2/3 армии выполняет небоевые задачи). В играх посложнее это пытаются реализовать, с той или иной степенью успешности. Типа, сначала императорский флот захватил планету, потом там по ней AT-AT прошлись танковым строем, а потом за отдельного солдата можно поиграть.
Про то и речь, что отряд в виде группы клонированных юнитов - это жуткое упрощение игровой механики.
Если используемые навыки юнита зависят не от него самого, а от способа его применения, то это не очень соответствует принципам ООП. Более того, зачем вообще нужны "навыки юнита" на таком уровне абстракции? Для результата сражения между армиями не важна индивидуальная подготовка конкретных солдат.
Например, то, что поражающее действие связки меча и кинжала не равно сумме их применения по отдельности. Конечно, этим можно пренебречь для простоты игровой механики, но от принципиальной проблемы не уйдешь.
Тут проблема состоит в том, что поведение реального солдата в одиночку и поведение его же в составе боевого порядка - совершенно разные вещи. Поэтому композиция даёт далёкие от идеала результаты. Условно говоря, сражение двух армий не декомпозируется до множества драк в подворотне.
И для тестов был собран специальный стенд. Не говоря уже о том, что для софта верхнего уровня были специальные тестовые модули (эмуляторы), которые гнали туда заданный поток данных.
Да это всё понятно, но не гарантирует натурного результата.
Т.е. лучше когда непосредственно на орбите вылезет ошибка которую вы заранее не предусмотрели и с которой не знаете что делать? Серьезно?
Надёжно написанная программа предсказуемо работает даже при непредусмотренных ошибках.
Хорошо, когда есть такая возможность. Это обычно возможно в информационных системах и не всегда возможно в системах обработки измерительной информации и управления оборудованием в реальном времени.
Представьте, например, что вы проводите ядерное испытание на полигоне (или стреляете по противнику). Хорошо, конечно, что у вас останется дамп упавшего модуля, но потерянной информации это не восполнит. Адекватно протестировать заранее невозможно, а повторять запуск программы дороговато во всех смыслах.
У меня была программа, для отладки которой необходимо было включать бортовое оборудование космического аппарата в определённой точке орбиты. Тоже недешёвый манёвр.
Конечно. Но программа, тем не менее, должна ведь как-то работать и до момента когда её исправят. И желательно, чтобы ошибки в программе не рушили бизнес-процесс.
Всё верно, поэтому я и пишу, что ситуация редкая, а не невозможная.
Хотя rollback (или commit) скорее всего будет выполняться автоматически при уничтожении соединения по таймауту запуска GC. Но тут многое зависит от прикладной логики.
Я живу в Питере, и таких перекрёстков вокруг подавляющее большинство. Перенастройка светофоров подобным образом без строительства дорожной развязки вызовет транспортный коллапс, так как уменьшит пропускную способность.
Это цитата из стандарта на организацию движения. Он не имеет непосредственного действия на участников движения, в отличие от ПДД. Просто говорит о том, как надо сейчас оборудовать дороги.
Технические стандарты в РФ не имеют силы закона, в отличие от СССР.
Такое пересечение разрешено всегда, за исключением автомагистралей. Оно только иногда исключается специальной организацией движения на перекрестке, но это не имеет никакого отражения в дорожных знаках.
Так и происходит в играх с простой механикой, диктуемой как раз принципом декомпозиции. Но в реальной жизни-то это не так. Управление одним солдатом заключается в стрельбе и рукопашном бое, командир батальона управляет тактикой солдат по рации, а генерал, командующий армией, диктует стратегические приказы стенографистке (и при этом минимум 2/3 армии выполняет небоевые задачи). В играх посложнее это пытаются реализовать, с той или иной степенью успешности. Типа, сначала императорский флот захватил планету, потом там по ней AT-AT прошлись танковым строем, а потом за отдельного солдата можно поиграть.
Про то и речь, что отряд в виде группы клонированных юнитов - это жуткое упрощение игровой механики.
Всё верно. Кроме того, для автомобиля чисто геометрически выгоден широкий заход в поворот (на апексе).
Если используемые навыки юнита зависят не от него самого, а от способа его применения, то это не очень соответствует принципам ООП. Более того, зачем вообще нужны "навыки юнита" на таком уровне абстракции? Для результата сражения между армиями не важна индивидуальная подготовка конкретных солдат.
Например, то, что поражающее действие связки меча и кинжала не равно сумме их применения по отдельности. Конечно, этим можно пренебречь для простоты игровой механики, но от принципиальной проблемы не уйдешь.
Можно сказать и так, но тогда самому классу "оружие" будет сложно придать конкретное содержание. Между файрболом и мечом очень мало общего.
Так в том-то и проблема, что N юнитами по уму надо управлять совершенно по-другому, чем одним.
Что-то не прописалась ссылка, спасибо. https://habr.com/ru/articles/919190/
Тут проблема состоит в том, что поведение реального солдата в одиночку и поведение его же в составе боевого порядка - совершенно разные вещи. Поэтому композиция даёт далёкие от идеала результаты. Условно говоря, сражение двух армий не декомпозируется до множества драк в подворотне.
Справедливые замечания и ценные практические наблюдения. Похожие вещи, рассматривая их несколько под другим углом, я упоминал здесь.
Да это всё понятно, но не гарантирует натурного результата.
Надёжно написанная программа предсказуемо работает даже при непредусмотренных ошибках.
Хорошо, когда есть такая возможность. Это обычно возможно в информационных системах и не всегда возможно в системах обработки измерительной информации и управления оборудованием в реальном времени.
Представьте, например, что вы проводите ядерное испытание на полигоне (или стреляете по противнику). Хорошо, конечно, что у вас останется дамп упавшего модуля, но потерянной информации это не восполнит. Адекватно протестировать заранее невозможно, а повторять запуск программы дороговато во всех смыслах.
У меня была программа, для отладки которой необходимо было включать бортовое оборудование космического аппарата в определённой точке орбиты. Тоже недешёвый манёвр.
Конечно. Но программа, тем не менее, должна ведь как-то работать и до момента когда её исправят. И желательно, чтобы ошибки в программе не рушили бизнес-процесс.
Теория утверждает, что результаты практики должны соответствовать теории, но на практике это не так.
Для меня основной сценарий исключений - это обработка и автоматическое парирование ошибок в программе или аппаратуре.
Ну если логически рассуждать, то commit должен быть явным, а rollback - по умолчанию.
Всё верно, поэтому я и пишу, что ситуация редкая, а не невозможная.
Хотя rollback (или commit) скорее всего будет выполняться автоматически при уничтожении соединения по таймауту запуска GC. Но тут многое зависит от прикладной логики.
Я живу в Питере, и таких перекрёстков вокруг подавляющее большинство. Перенастройка светофоров подобным образом без строительства дорожной развязки вызовет транспортный коллапс, так как уменьшит пропускную способность.
Любой перекресток, построенный до введения в действие этого госта.
Это цитата из стандарта на организацию движения. Он не имеет непосредственного действия на участников движения, в отличие от ПДД. Просто говорит о том, как надо сейчас оборудовать дороги.
Технические стандарты в РФ не имеют силы закона, в отличие от СССР.
Не думаю, что в общем случае имеет смысл облегчать руками автоматическую работу GC.
Такое пересечение разрешено всегда, за исключением автомагистралей. Оно только иногда исключается специальной организацией движения на перекрестке, но это не имеет никакого отражения в дорожных знаках.