Используются ли в розничных играх «инверсия контроля» и «внедрение зависимостей»?

Многие из наиболее усердных разработчиков программного обеспечения, которых я знаю, переходят к инверсии управления и внедрению зависимостей для обработки ссылок на объекты. Исходя из перспективы Flash-игр, я не знаю все тонкости студий AAA, поэтому: используются ли они в мире розничных игр?

Вы называете это «усердной разработкой программного обеспечения», я называю это «болезненным переобучение». Это не значит, что инверсия контроля - это плохо - на самом деле, его базовое определение хорошо - но распространение целых структур и методов работы для достижения всего этого мало чем безумно, особенно в сочетании с тем, как люди уничтожают. отличные и чистые интерфейсы, позволяющие вводить сменные компоненты, которые в 99% случаев вы никогда не будете менять. Это то, что может происходить только из корпоративной среды Java, и я рад, что в других местах он не имеет такой опоры.

Часто аргументом является то, что даже если вы не обмениваетесь компонентами, вы хотите иметь возможность тестировать их изолированно с фиктивными объектами и тому подобным. Тем не менее, я боюсь, что никогда не куплю аргумент, что стоит вздутие живота и усложнить интерфейс, чтобы лучше его протестировать. Тестирование доказывает только одно - что ваши тесты работают. Чистые и минимальные интерфейсы, с другой стороны, имеют большое значение для доказательства того, что ваш код работает.

Итак, короткий ответ: да, но не так, как вы думаете. Иногда, когда вам нужно взаимозаменяемое поведение, вы передаете объект конструктору, который определяет часть поведения нового объекта. Вот и все.

Паттерн стратегии , состав , внедрение зависимостей - все это очень тесно связано.

Поскольку шаблон стратегии является формой внедрения зависимостей, если вы посмотрите, например, на движки типа Unity, они полностью основаны на этом принципе. Их использование компонентов (шаблон стратегии) ​​глубоко встроено в их весь движок.

Одним из основных преимуществ, помимо повторного использования компонентов, является избежание страшной глубокой иерархии классов.

Вот статья Мика Уэста, который рассказывает о том, как он ввел этот тип системы в серию игр Tony Hawk от Neversoft.

Развивайте свою иерархию

Вплоть до последних лет программисты игр последовательно использовали глубокую иерархию классов для представления игровых сущностей. Прилив начинает переходить от использования глубоких иерархий к множеству методов, которые составляют объект игровой сущности как совокупность компонентов ...

Кажется, существует большая путаница в отношении схемы инверсии контроля (IoC). Многие люди приравнивают его к шаблону стратегии или компонентной модели, но это сравнение на самом деле не отражает то, что представляет собой IoC. IoC действительно о том, как получается зависимость. Позволь мне привести пример:

class Game {
    void Load() {
        this.Sprite.Load(); // loads resource for drawing later
    }
}

class Sprite {
    void Load() {
        FileReader reader = new FileReader("path/to/resource.gif");
        // load image from file
    }
}

Из приведенного выше ясно, что Sprite.Loadзависит от FileReader. Когда вы хотите проверить метод, вам нужно следующее:

1. Файловая система на месте
2. Тестовый файл для загрузки из файловой системы
3. Возможность вызвать общие ошибки файловой системы

Первые два очевидны, но если вы хотите убедиться, что ваша обработка ошибок работает так, как ожидалось, вам действительно нужен №3. В обоих случаях вы потенциально немного замедлили свои тесты, поскольку теперь им нужно перейти на диск, и вы, вероятно, сделали вашу среду тестирования более сложной.

Цель IoC состоит в том, чтобы отделить использование поведения от его конструкции. Обратите внимание, как это отличается от шаблона стратегии. С помощью шаблона «Стратегия» цель состоит в том, чтобы инкапсулировать многократно используемый фрагмент поведения, чтобы вы могли легко расширить его в будущем; ему нечего сказать о том, как строятся стратегии.

Если бы мы переписали Sprite.Loadописанный выше метод, мы бы, скорее всего, получили :

class Sprite {
    void Load(IReader reader) {
        // load image through reader
    }
}

Теперь мы отделили конструкцию читателя от ее использования. Таким образом, во время тестирования можно поменять тест-ридер. Это означает, что ваша среда тестирования больше не нуждается в файловой системе, тестовых файлах и может легко моделировать события ошибок.

Обратите внимание, что я переписал две вещи. Я создал интерфейс, IReaderкоторый инкапсулировал некоторое поведение - то есть реализовал шаблон Стратегии. Кроме того, я перенес ответственность за создание правильного читателя в другой класс.

Может быть, нам не нужно новое имя шаблона для описания выше. Это выглядит как сочетание шаблонов Strategy и Factory (для контейнеров IoC). При этом я не уверен, на каком основании люди возражают против этого шаблона, поскольку ясно, что он решает реальную проблему, и, конечно, для меня не очевидно, как это связано с Java.

Я бы сказал, что это один из многих инструментов, и он иногда используется. Как сказал tenpn, любой метод, который вводит vtables (и, как правило, любую дополнительную косвенность), может иметь снижение производительности, но это то, о чем нам следует беспокоиться только для низкоуровневого кода. Для структурного кода высокого уровня это на самом деле не проблема, и IoC может иметь положительные преимущества. Что угодно, чтобы уменьшить зависимости между классами и сделать ваш код более гибким.

Должен согласиться с Килотаном на этот счет. «Внедрение зависимостей» - это уродливое Java-решение для уродливого Java-концептуального изъяна, и единственная причина, по которой кто-то вообще смотрит на него на других языках, заключается в том, что Java становится первым языком для многих людей, а в действительности это не следует.

Инверсия контроля, с другой стороны, является полезной идеей, которая существует уже давно, и очень полезна, когда все сделано правильно. (Не способ внедрения Java / Dependency Injection.) На самом деле, вы, вероятно, делаете это постоянно, если работаете на нормальном языке программирования. Когда я впервые прочитал об этом "МОК", о котором все жужжали, я был совершенно ошеломлен. Инверсия управления - это не что иное, как передача указателя функции (или указателя метода) на подпрограмму или объект, чтобы помочь настроить его поведение.

Эта идея существует с 1950-х годов. Он находится в стандартной библиотеке C (приходит на ум qsort) и везде в Delphi и .NET (обработчики / делегаты событий). Он позволяет старому коду вызывать новый код без необходимости перекомпиляции старого кода, и он все время используется в игровых движках.

Не в моем опыте. К сожалению, игровой код должен быть очень адаптируемым, и эти подходы определенно помогут.

Однако следует сказать, что оба метода в C ++ могут вводить виртуальные таблицы там, где их раньше не было, что приводит к соответствующему снижению производительности.

Я не профессиональный разработчик игр, и только однажды пытался реализовать IoC на C ++, так что это просто предположение.

Однако я подозреваю, что разработчики игр с подозрением относятся к IoC, потому что это означает:

1 / проектирование множества интерфейсов и множества небольших классов

2 / почти каждый вызов функции в последнее время связан

Теперь это может быть совпадением, но оба они, как правило, немного сложнее и / или проблематичны для производительности в C ++ (который широко используется в игре, не так ли?), Чем в Java, где IoC стал широко распространенным (вероятно, потому что это было относительно легко сделать, помогать людям проектировать более разумные иерархии объектов, и потому что некоторые полагали, что это может превратить написание приложения на Java в написание приложения на XML, но это еще одна дискуссия: P)

Я заинтересован в комментариях, если это не имеет никакого смысла вообще;)