266 votos

La inyección de dependencia vs patrón Factory

La mayoría de los ejemplos citados por el uso de la Inyección de Dependencia, se puede solucionar utilizando el patrón de fábrica así. Se parece a cuando se trata de uso/diseño de la diferencia entre la inyección de dependencia y la fábrica es borrosa o delgado.

Una vez alguien me dijo que su forma de usarlo que hace una diferencia!

He utilizado una vez StructureMap un contenedor de DI para resolver un problema, más tarde me rediseñado para trabajar con una simple fábrica y se han quitado las referencias a StructureMap.

¿Alguien puede decirme cuál es la diferencia entre ellos y donde el uso de lo que, ¿cuál es la mejor práctica aquí?

176voto

willcodejavaforfood Puntos 20365

Cuando se utiliza una fábrica el código sigue siendo realmente responsable para la creación de objetos. Por DI externalizar esa responsabilidad a otra clase o un marco, que está separado de su código.

132voto

Perpetualcoder Puntos 7381

Yo sugeriría para mantener los conceptos simple y llanamente. Inyección de dependencias es más de un patrón arquitectónico para el acoplamiento con los componentes de software libremente. Patrón de fábrica es sólo una forma de separar la responsabilidad de crear objetos de otras clases a otra entidad. Patrón de fábrica puede ser llamado como una herramienta para implementar DI. Inyección de dependencias se puede implementar en muchos sentidos como DI usando constructores, usando archivos de asignación xml etc..

65voto

Despertar Puntos 5365

Depency Inyección

En lugar de crear instancias de las partes de sí mismo que un coche le pregunta por las piezas que necesita para funcionar.

class Car
{
    private Engine;
    private SteeringWheel;
    private Tires tires;

    public Car(Engine engine, SteeringWheel wheel, Tires tires)
    {
        this.Engine = engine;
        this.SteeringWheel = wheel;
        this.Tires = tires;
    }
}

Fábrica

Coloca las piezas para formar un objeto completo y se esconde en qué tipo concreto de la persona que llama.

static class CarFactory
{
    public ICar BuildCar()
    {
        Engine engine = new Engine();
        SteeringWheel steeringWheel = new SteeringWheel();
        Tires tires = new Tires();
        ICar car = new RaceCar(engine, steeringWheel, tires);
        return car;
    }   
}

Resultado

Como se puede ver, las Fábricas y DI en realidad se complementan.

static void Main()
{
     ICar car = CarFactory.BuildCar();
     // use car
}

¿Te acuerdas de ricitos de oro y los tres osos? Además de la inyección de dependencia es de un tipo como ese. Aquí hay tres maneras de hacer la misma cosa.

void RaceCar() // example #1
{
    ICar car = CarFactory.BuildCar();
    car.Race();
}

void RaceCar(ICarFactory carFactory) // example #2
{
    ICar car = carFactory.BuildCar();
    car.Race();
}

void RaceCar(ICar car) // example #3
{
    car.Race();
}

Ejemplo #1 - Este es el peor porque es totalmente oculta la dependencia. Si usted miró el método como una caja negra que no tiene idea de que se requiere de un coche.

Ejemplo #2 - Este es un poco mejor, porque ahora sabemos que tenemos un coche ya que pasamos de una fábrica de coches. Pero esta vez estamos pasando demasiado ya que todos los métodos que realmente necesita es un coche. Estamos pasando de una fábrica, sólo para construir el coche cuando el coche podría ser construido fuera de el método y el pasado.

Ejemplo #3 - Este es el ideal ya que el método que pide exactamente lo que necesita. No demasiado, o demasiado poco. No tengo que escribir un MockCarFactory sólo para crear MockCars, me puede pasar el simulacro de recto. Es directa y la interfaz no miente.

Este Google Tech Talk por Misko Hevery es increíble y es la base de lo que deduje que mi ejemplo. http://www.youtube.com/watch?v=XcT4yYu_TTs

32voto

yfeldblum Puntos 42613

Hay problemas que son fáciles de resolver con la inyección de dependencias que no son tan fáciles de resolver, con un conjunto de fábricas.

Parte de la diferencia entre, por un lado, la inversión de control e inyección de dependencia (COI/DI), y, por otro lado, un servicio de localizador o de un conjunto de fábricas (de fábrica), es:

IOC/DI es un ecosistema completo de objetos de dominio y servicios de en y de sí mismo. Es todo lo configura de la manera que usted especifique. Su dominio de los objetos y servicios que se construyó el contenedor, y no se construye a sí mismo: por lo tanto, no tienen ninguna de las dependencias en el envase o en fábricas. IOC/DI los permisos de un alto grado de configurabilidad, con toda la configuración en un solo lugar (la construcción del recipiente) en la capa superior de la aplicación (la interfaz gráfica de usuario, el servidor Web front-end).

Fábrica de resúmenes de distancia de algunos de la construcción de su dominio de objetos y servicios. Pero el dominio de los objetos y servicios que están siendo responsable de averiguar cómo se construyen y cómo conseguir que todas las cosas dependen. Todos estos "activos" de las dependencias de filtrar todo el camino a través de todas las capas de la aplicación. No hay un solo lugar para ir a configurar todo.

16voto

Pup Puntos 3505

Gestión del ciclo de vida es una de las responsabilidades de la dependencia de los contenedores de asumir, además de la creación de instancias y de la inyección. El hecho de que el recipiente a veces mantener una referencia a los componentes después de la instanciación es la razón por la que es llamado un "contenedor", y no una fábrica. La inyección de dependencia contenedores generalmente de sólo mantener una referencia a los objetos que necesita para manejar los ciclos de la vida, o que se reutilizan para el futuro de las inyecciones, como los únicos o flyweights. Cuando se configura para crear nuevas instancias de algunos de los componentes para cada llamada al contenedor, el contenedor general, sólo se olvida de que el objeto creado.

De: http://tutorials.jenkov.com/dependency-injection/dependency-injection-containers.html

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by: