matlab - que - Inyección de dependencia sin marco

que es la inyección de dependencia

Question

Estoy escribiendo un programa de análisis de tamaño medio (5-10kloc) en MATLAB (no es mi decisión), y estoy tratando de usar la inyección de dependencia para hacer que mi código sea más comprobable. Creo que entiendo el modelo básico de inyección de objeto / constructor, pero estoy confundido sobre cómo se escala el gráfico de dependencia.

Por ejemplo, si tengo el objeto A, que tiene un objeto B que tiene un objeto C y el objeto C tiene una dependencia que necesita ser inyectada, ¿necesito pasarlo por toda la cadena? Eventualmente, dado que este es un programa de análisis de datos, básicamente todo vuelve a un objeto / método de AnalyzeData, ¿significa esto que ese objeto tiene que tener inyectadas todas las dependencias de todo el programa?

Quizás la respuesta sea simplemente usar ServiceFactory / ServiceProvider en este caso, pero me gustaría saber si es posible escalar muchas dependencias hasta un gran gráfico de objetos sin un marco.

Además, se fomentan las correcciones en mi pensamiento / redacción / fundamentos: básicamente he aprendido la mayor parte de esto a través de Google / HN / SO.

Answer 1

Haga rodar su propio contenedor IoC donde puede solicitar sus dependencias sin necesidad de inyectarlos, o use el patrón de puerta de enlace estática para obtener un singleton para crear clases dinámicamente utilizando una fábrica.

Este video me pareció una introducción realmente útil para estos temas: http://www.dnrtv.com/default.aspx?showNum=126

Answer 2

No sé nada sobre Matlab, pero supongo (según sus palabras) que hay objetos. Si es así, busque un Localizador de servicios en lugar de Inyección de dependencia. Los localizadores de servicios son muy simples de implementar, por lo que no requieren marcos.

Answer 3

Respuesta de Matlab-agnóstico:

Si (A necesita B) y (B necesita C), primero crea C, luego crea B y pasa de C a B. Luego crea A y pasa (B tiene C) a A.

Ahora, si C necesita una dependencia para ser inyectada, llámala D, aún puedes hacer esto luego de esta secuencia de eventos usando la inyección setter. Este sería el caso si la dependencia es opcional para C. De lo contrario, es probable que haya un error en la inicialización de su programa que C no se inyectó con D antes de pasarlo a B.

Si quieres usar la inyección de constructor para inyectar D en C después de que ya lo tienes (A tiene (B tiene C)), entonces tendrás que usar la inyección setter para pasar una nueva (C tiene D) a B, pero esta secuencia de eventos generalmente no es un escenario válido para DI.

Answer 4

Si entiendo tu pregunta correctamente, la respuesta puede depender de cómo estás creando las clases a partir de las cuales creas los objetos. Dentro de las versiones más recientes de MATLAB, las clases se pueden definir de dos maneras: una clase de "valor" o una clase de "control" (documentación de MATLAB aquí ). Citando de la documentación:

• Clase de valor: "Los objetos de clases de valor están asociados permanentemente con las variables a las que están asignados. Cuando se copia un objeto de valor, los datos del objeto también se copian y el nuevo objeto es independiente de los cambios en el objeto original. Las instancias se comportan como estándar MATLAB numeric y struct classes ".

• Manejar clase: "Las clases de objetos de manejo usan un control para hacer referencia a objetos de la clase. Un mango es una variable que identifica una instancia particular de una clase. Cuando se copia un objeto de control, se copia el mango, pero no los datos almacenados en las propiedades del objeto. La copia se refiere a los mismos datos que el original: si cambia el valor de una propiedad en el objeto original, el objeto copiado refleja el mismo cambio ".

El código de ejemplo siguiente proporciona algunos ejemplos de cómo interactuar con objetos "anidados" como los descritos anteriormente, tanto para objetos anidados de clase de valor como para objetos anidados de clase de manejo:

% For value classes:

objC = C(...);  % Make an object of class C, where "..." stands
                %   for any input arguments
objB = B(...,objC);  % Make an object of class B, passing it objC
                     %   and placing objC in field ''objC''
objA = A(...,objB);  % Make an object of class A, passing it objB
                     %   and placing objB in field ''objB''

% If the ''.'' operator (field access) is defined for the objects:

objA.objB.objC.D = 1;  % Set field ''D'' in objC to 1
objA.objB.objC = foo(objA.objB.objC,...);  % Apply a method that
                                           %   modifies objC and
                                           %   returns the new
                                           %   object

% For handle classes:

hC = C(...);  % Get a handle (reference) for a new object of class C
hB = B(...,hC);  % Get a handle for a new object of class B,
                 %   passing it handle hC and placing it in field ''hC''
hA = A(...,hB);  % Get a handle for a new object of class A,
                 %   passing it handle hB and placing it in field ''hB''

% If the ''.'' operator (field access) is defined for the objects:

hC.D = 1;  % Set field ''D'' to 1 for object referenced by hC; Note
           %   that hC and hA.hB.hC both point to same object, and
           %   can thus be used interchangably
foo(hC);  % Apply a method that modifies the object referenced by hC

% If instead using get/set methods for the handle object:

set(hC,''D'',1);
set(get(get(hA,''hB''),''hC''),''D'',1);  % If variable hC wasn''t made, get
                                    %   reference from nested objects
foo(hC);
foo(get(get(hA,''hB''),''hC''));

Como puede ver, el uso de una clase de control puede ayudarlo a evitar tener que encadenar llamadas a funciones y referencias de campo almacenando una copia del controlador (esencialmente un puntero) en otra variable. Las clases de control también eliminan la necesidad de sobrescribir copias antiguas de objetos con nuevos devueltos por métodos que operan en esos objetos.

Espero que esto ayude con lo que estabas preguntando.

Answer 5

Si haces la inyección de dependencia a mano, es mejor que no pases las dependencias. Simplemente crea C con su dependencia, crea B con C, crea A con B. No es necesario que A sepa algo sobre C o su dependencia. Simplemente conoce la interfaz de B y, por lo general, las dependencias no son parte de la interfaz de un objeto.

Answer 6

Descargo de responsabilidad: OO idioma agnóstico respuesta

No, no necesita pasar dependencias a través de un gráfico de objetos completos. No tener que instanciar tipos concretos o pasarlos como parámetros es el objetivo de DI. En general, tendrá alguna otra entidad, llamada Assembler por ejemplo, que inyectará estas dependencias. El ensamblador puede ser ad-hock, escrito a mano o puede ser un poco de marco DI.

Por ejemplo:

• Class ClsA tiene una propiedad de tipo interfaz IB.
• Class ClsB implementa IB y tiene una propiedad de tipo interfaz IC.
• Class ClsC implementa IC.

Your Assembler iniciará la aplicación y:

1. crear una instancia llamada oC de la clase ClsC
2. crear instancia llamada oB de ClsB e inyectarlo con oC
3. crear una instancia llamada oA e inyectarla con oB

Todos sus objetos de dominio solo conocen interfaces. El ensamblador conoce todo el objeto, pero su propósito es simplemente crear un gráfico de objetos y poner todo en movimiento. El ensamblador escrito a mano es perfectamente apropiado; algunas personas prefieren escribir código de cableado que usar archivos de configuración. No piense que vale la pena el problema de escribir assembler (DI framework) si no planea usarlo más de una vez. El punto es que tus clases están escritas en DI moda.

Eche un vistazo a este artículo: http://books.google.com/books?id=vRxAnRb3mb4C&pg=PP1&dq=Danijel+Arsenovski#PPA428,M1.