¿Los juegos minoristas usan "inversión de control" e "inyección de dependencia"?

Muchos de los desarrolladores de software más diligentes que conozco se están moviendo hacia la inversión de control y la inyección de dependencia para manejar referencias a objetos. Desde la perspectiva de los juegos Flash, no conozco todos los entresijos de los estudios AAA, entonces: ¿se usan en el mundo de los juegos minoristas?

Lo llamas "desarrollo de software diligente", lo llamo "ingeniería excesiva dolorosa". Eso no quiere decir que la inversión de control sea mala, de hecho, la definición básica de la misma es buena, pero la proliferación de marcos y métodos de trabajo completos para lograr todo esto es poco menos que una locura, especialmente combinada con la forma en que la gente está destrozando Interfaces perfectamente buenas y limpias para poder inyectar componentes intercambiables que el 99% del tiempo nunca intercambiarás. Es el tipo de cosas que solo pueden originarse en el entorno empresarial de Java y me alegro de que no tenga tanta influencia en otros lugares.

A menudo, el argumento es que, incluso si no intercambia componentes, desea poder probarlos de forma aislada con objetos simulados y similares. Sin embargo, me temo que nunca compraré el argumento de que vale la pena hinchar y complicar una interfaz para poder probarla mejor. Las pruebas prueban una sola cosa: que sus pruebas funcionen. Las interfaces limpias y mínimas, por otro lado, ayudan a demostrar que su código funciona.

Entonces, la respuesta corta: sí, pero no en la forma en que piensas. A veces, cuando necesita un comportamiento intercambiable, pasará un objeto a un constructor que dicta parte del comportamiento del nuevo objeto. Eso es todo.

Patrón de estrategia , composición , inyección de dependencia , están todos muy relacionados.

Dado que el Patrón de estrategia es una forma de inyección de dependencia, si observa motores como Unity, por ejemplo, se basan completamente en este principio. Su uso de Componentes (Patrón de Estrategia) está profundamente incrustado en todo su motor.

Uno de los principales beneficios, aparte de la reutilización de componentes, es evitar las temidas jerarquías de clases profundas.

Aquí hay un artículo de Mick West que habla sobre cómo introdujo este tipo de sistema en la serie de juegos Tony Hawk de Neversoft.

Evoluciona tu jerarquía

Hasta años relativamente recientes, los programadores de juegos han usado constantemente una jerarquía de clase profunda para representar las entidades del juego. La marea está comenzando a cambiar de este uso de jerarquías profundas a una variedad de métodos que componen un objeto de entidad de juego como una agregación de componentes ...

Parece haber mucha confusión sobre el patrón de Inversión de Control (IoC). Varias personas lo han equiparado con el Patrón de estrategia o un Modelo de componentes, pero esta comparación realmente no capta de qué se trata IoC. IoC realmente trata sobre cómo se obtiene una dependencia. Dejame darte un ejemplo:

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
    }
}

En lo anterior está claro que Sprite.Loadtiene una dependencia de a FileReader. Cuando desee probar el método, necesita lo siguiente:

1. Un sistema de archivos en su lugar
2. Un archivo de prueba para cargar desde el sistema de archivos
3. Capacidad para desencadenar errores comunes del sistema de archivos

Los dos primeros son obvios, pero si desea asegurarse de que su manejo de errores funcione como se espera, realmente también necesita el n. ° 3. En ambos casos, posiblemente haya ralentizado sus pruebas un poco, ya que ahora deben ir al disco y probablemente haya complicado su entorno de prueba.

El objetivo de IoC es desacoplar el uso del comportamiento de su construcción. Observe cómo esto difiere del patrón de Estrategia. Con el patrón de estrategia, el objetivo es encapsular una parte de comportamiento reutilizable para que pueda ampliarla fácilmente en el futuro; No tiene nada que decir sobre cómo se construyen las estrategias.

Si tuviéramos que reescribir el Sprite.Loadmétodo anterior, probablemente terminaríamos con:

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

Ahora, hemos desacoplado la construcción del lector de su uso. Por lo tanto, es posible intercambiar un lector de prueba durante la prueba. Esto significa que su entorno de prueba ya no necesita un sistema de archivos, archivos de prueba y puede simular fácilmente eventos de error.

Tenga en cuenta que hice dos cosas en mi reescritura. Creé una interfaz IReaderque encapsulaba algún comportamiento, es decir, implementé el patrón de Estrategia. Además, trasladé la responsabilidad de crear el lector adecuado a otra clase.

Tal vez no necesitamos un nuevo nombre de patrón para describir lo anterior. Me parece una combinación de los patrones de Estrategia y Fábrica (para contenedores IoC). Dicho esto, no estoy seguro de por qué las personas se oponen a este patrón, ya que está claro que resuelve un problema real y, ciertamente, no es obvio para mí lo que esto tiene que ver con Java.

Yo diría que es una herramienta entre muchas, y se usa en ocasiones. Como dijo tenpn, cualquier método que introduzca vtables (y generalmente cualquier indirección adicional) puede tener una penalización de rendimiento, pero esto es algo de lo que solo debemos preocuparnos por el código de bajo nivel. Para el código estructural de alto nivel que realmente no es un problema, y ​​la IoC puede tener beneficios positivos. Cualquier cosa para reducir las dependencias entre clases y hacer que su código sea más flexible.

Tengo que estar de acuerdo con Kylotan en este caso. La "inyección de dependencia" es una solución fea de Java para un defecto conceptual feo de Java, y la única razón por la que alguien lo está mirando en otros idiomas es porque Java se está convirtiendo en el primer idioma para mucha gente, cuando realmente no debería.

La inversión del control, por otro lado, es una idea útil que ha existido durante mucho tiempo y es muy útil cuando se hace correctamente. (No es la forma de inyección de Java / Dependencia). De hecho, probablemente lo haga todo el tiempo si está trabajando en un lenguaje de programación sensato. Cuando leí por primera vez todo este asunto del "COI" sobre el que todos hablaban, me sentí completamente decepcionado. La inversión de control no es más que pasar un puntero de función (o puntero de método) a una rutina u objeto para ayudar a personalizar su comportamiento.

Esta es una idea que existe desde la década de 1950. Está en la biblioteca estándar de C (qsort viene a la mente) y está en todas partes en Delphi y .NET (controladores / delegados de eventos). Permite que el código antiguo llame a código nuevo sin necesidad de volver a compilar el código antiguo, y se usa todo el tiempo en los motores de juego.

No en mi experiencia. Lo cual es una pena, ya que el código de los juegos debe ser muy adaptable, y estos enfoques definitivamente ayudarían.

Sin embargo, debe decirse que ambos métodos podrían, en C ++, introducir tablas virtuales donde no las había antes, trayendo consigo un éxito adecuado en el rendimiento.

No soy un desarrollador profesional de juegos, y solo intenté implementar IoC en C ++ una vez, así que esto es solo especulación.

Sin embargo, sospecho que los desarrolladores de juegos sospecharían de IoC porque significa:

1 / diseño de muchas interfaces y muchas clases pequeñas

2 / teniendo casi todas las llamadas a funciones vinculadas últimamente

Ahora, puede ser una coincidencia, pero ambos tienden a ser un poco más complicados y / o problemáticos para las actuaciones en C ++ (que se usa ampliamente en el juego, ¿no?) Que en Java, donde IoC se generalizó (probablemente porque era relativamente fácil de hacer, ayudar a las personas a diseñar jerarquías de objetos más sanas, y porque algunos creían que podría convertir escribir una aplicación en Java en escribir una aplicación en XML, pero ese es otro debate: P)

Me interesan los comentarios si eso no tiene ningún sentido;)