Patron IoC e inyeccion de dependencia

[HiToGoRoShi]

Podrían explicarme para que sirven estos patrones y con que fin se usan .. con alguno ejemplo simple en PHP

Lo publico acá porque hay gurus en patrones de diseño

Estoy haciendo un trabajo en .NET, y nos mandaron a investigar esto pero no logro comprender bien su uso , yo se que dirán porque publicas esto acá, si lo tuyo es .NET ... pero los patrones de diseno son ambiguos no?, da igual en que lenguaje lo use

[GatorV]

El patrón de inyeccion de dependencias lo que busca es desacoplar aún más tu sistema, que tus clases no sean concretas, si no abstractas, y que cambien su comportamiento de forma dinámica dependiendo de los componentes bajo los que este atado.

Es decir, que tu clase, no sepa exactamente con que clase va a trabajar, si no que tenga una interfaz que solo garantice el contrato de funcionamiento de la clase.

Un ejemplo muy típico es un logger, el log recibe como parámetro (o como dependencia) un writer donde va a escribir las entradas del log, el writer como tal es una interfaz, y tiene muchas implementaciones (writer de memoria, en un archivo, por mail, una base de datos, etc), cada writer tiene su tarea específica, y el log no se preocupa por eso, el log lo que hace es crear la entrada y enviarla al writer que tenga especificado en su dependencia.

IoC es esto mismo, o sea tu clase no sabe con que componentes va a trabajar, simplemente sabe las dependencias que necesita (usando Interfaz), y el como se comporta, se hace al momento de usar tu aplicación (normalmente usando un archivo de configuración) donde se describe el comportamiento de la aplicación y es cuando se crean las instancias concretas de cada clase y se inyectan a los componentes que necesitan.

Saludos.

[HiToGoRoShi]

tu que eres lobo en zf este implementa estos patrones? ... podrias darme un ejemplo simple no mas en codigo?

Gracias

[GatorV]

Así es ZF2 implementa mucho IoC y DI, usando el ServiceManager.

Saludos.

[HiToGoRoShi]

Veamos si entendi para poder hacer mi tarea correctamente ....

Inyeccion de depedencia y IoC lo que intenta hacer es desacoplar la logica de tu proyecto, cosa que asi si en un futuro tu logica de negocio cambia ya no vas a tener que modificar todo, sino solo tu repositorio.

Lo cual e visto lo mismo con factory ... que me parecen casi identico

[pablofmorales]

Iniciado por HiToGoRoShi

Podrían explicarme para que sirven estos patrones y con que fin se usan .. con alguno ejemplo simple en PHP

Lo publico acá porque hay gurus en patrones de diseño

Estoy haciendo un trabajo en .NET, y nos mandaron a investigar esto pero no logro comprender bien su uso , yo se que dirán porque publicas esto acá, si lo tuyo es .NET ... pero los patrones de diseno son ambiguos no?, da igual en que lenguaje lo use

Arriba Gatarov explica que son y para que sirven. Este patron es una pata de los principio de SOLID

un ejemplo en php simple con un logger en PHP seria algo como

Código PHP:

  <?php
class Logger 
{
   public function write($message)
  {
      error_log($message);
  }
}

class Login
{
   private $_logger;
   public function setLogger($logger)
   {
      $this->_logger = $logger;
   }

   public function authenticate($user, $password)
   {
      if ($user == 'test' && $password == 'passwd') {
         return true;
      } else {
          $this->_logger->write('User can not be found');
          return false;
      }
   }
}

$logger = new Logger();
$login = new Login();
$login->setLogger($logger);

$login->authenticate('Juan', 'Password');   

Si en algun momento queremos cambiar nuestra clase logger por Monolog por ejemplo cambiamos solo cuando hacemos la inyeccion por ejemplo

Código PHP:

  $logger = new Monolog();
$login = new Login();
$login->setLogger($logger);

$login->authenticate('Juan', 'Password'); 
   

Y todo funciona bien :D

[HiToGoRoShi]

Okey, voy a poner mi ejemplo ...

Tengo mis carpetas así

Model
--datos
--------UsuarioMemory
--------UsuarioXML
--entities
--------Usuario
--interfaces
--------IUsuarioService
--UsuarioModel

Lo que e aplicado es la inyección de dependencia ... ya que mi aplicativo puede consumir ya sea de una base de datos, un XML, o de la memoria sin tener que cambiar su lógica de negocio, solo debe cambiar su repositorio, es decir la dependencia inyectada.

Las clases

model/Entities/Usuario

Código PHP:

class Usuario {
    private $_id;
    private $_nombre;
    private $_apellido;
    private $_dni;
    
    public function get_id() { return $this->_id; }
    public function get_nombre() { return $this->_nombre; }
    public function get_apellido() { return $this->_apellido; }
    public function get_dni() { return $this->_dni; }
    public function set_id($x) { $this->_id = $x; }
    public function set_nombre($x) { $this->_nombre = $x; }
    public function set_apellido($x) { $this->_apellido = $x; }
    public function set_dni($x) { $this->_dni = $x; }
}
 

model/Datos/UsuarioXML

Código PHP:

<?php
class UsuarioXML {
    
    private $_sxe;
    
    public function __construct(){
        $this->_sxe = new SimpleXMLElement('usuario.xml', NULL, TRUE);
    }
    public function listar(){
        $usuarios = array();
        foreach($this->_sxe as $u){
            $usuario = new Usuario();
            
            $usuario->set_id((int)$u->id);
            $usuario->set_nombre((string)$u->nombre);
            $usuario->set_apellido((string)$u->apellido);
            $usuario->set_dni((string)$u->dni);
            
            $usuarios[] = $usuario;
        }
        
        return $usuarios;
    }
    public function registrar(Usuario $usuario){
        $u = $this->_sxe->addChild('usuario');
        
        $u->addChild('id', $this->_sxe->count() + 1);
        $u->addChild('nombre', $usuario->get_nombre());
        $u->addChild('apellido', $usuario->get_apellido());
        $u->addChild('dni', $usuario->get_dni());
        
        $this->save();
    }
    public function actualizar(Usuario $usuario){
        foreach($this->_sxe as $u){
            if($u->id == $usuario->get_id()){
                $u->nombre   = $usuario->get_nombre();
                $u->apellido = $usuario->get_apellido();
                $u->dni      = $usuario->get_dni();
                break;
            }
        }
        
        $this->save();
    }
    public function eliminar($id){
        $i = 0;
        foreach($this->_sxe as $k => $u){
            if($u->id == $id){
                $dom =dom_import_simplexml($u);
                $dom->parentNode->removeChild($dom);
                break;
            }
            $i++;
        }
        $this->save();
    }
    public function obtener($id){
        $usuario = new Usuario();
        foreach($this->_sxe as $u){
            if($u->id == $id){      
                $usuario->set_id((int)$u->id);
                $usuario->set_nombre((string)$u->nombre);
                $usuario->set_apellido((string)$u->apellido);
                $usuario->set_dni((string)$u->dni);
                break;
            }
        }
        
        return $usuario;
    }
    private function save(){
        $fo = fopen('usuario.xml','w');
        fwrite($fo, $this->_sxe->asXML());
        fclose($fo);
    }
}
 

model/interfaces/IUsuarioService

Código PHP:

interface IUsuarioService {
    public function setInjection($rp);
    
    public function listar();
    public function registrar(Usuario $usuario);
    public function actualizar(Usuario $usuario);
    public function eliminar($id);
    public function obtener($id);
}
 

model/UsuarioModel

Código PHP:

class UsuarioModel implements IUsuarioService {
 
    private $_Repossitory;
 
    public function setInjection($rp){
        $this->_Repossitory = $rp;
    }
 
    public function listar(){
        return $this->_Repossitory->listar();
    }
    public function registrar(Usuario $usuario){
        $this->_Repossitory->registrar($usuario);
    }
    public function actualizar(Usuario $usuario){
        $this->_Repossitory->actualizar($usuario);
    }
    public function eliminar($id){
        $this->_Repossitory->eliminar($id);
    }
    public function obtener($id){
        return $this->_Repossitory->obtener($id);
    }
 
}
 

Y ahora lo implemento asi

Código PHP:

$um = new UsuarioModel();
$um->setInjection(new UsuarioXML());
 
$usuarios = $um->listar();
 

En caso que nuestro proyecto ya no requiera el uso de los XML, simplemente cambiar su repositorio a UsuarioDB, o UsuarioTXT, o UsuarioMemoria

Esta bien lo que planteo?

[GatorV]

Exacto, esa es la idea, que puedas cambiar todo el funcionamiento desde un "bootstrap" o un archivo de configuración, en Java se usa mucho los .properties para describir el comportamiento de la aplicación.

[HiToGoRoShi]

aja, y actualmente todo los frameworks apuntan a eso ... lo que no tengo claro cual es la diferencia de IoC con inyeccion de dependencia, ya que por definicion me suena a lo mismo

[GatorV]

IoC es simplemente un paradigma de diseño, la idea es invertir el control en lugar de dependencias fijas a interfaces, ej:

Código PHP:

class Auto {
      public function __construct()
      {
              $this->motor = new Motor4cil();
              $this->puertas = new 2Puertas();
              $this->llantas = new LlantasDeInvierno();
      }
}
 

A usar interfaces abstractas:

Código PHP:

class Auto
{
         public function setMotor(InterfaceMotor $motor)
         {
                 $this->motor = $motor;
         }
 
         // etc
}
 
// Luego en algún bootstrap
$auto = new Auto();
$motor = Motor::factory('config.motor');
$auto->setMotor($motor);
 

Es decir el control es invertido, ya no lo tiene la clase Auto, si no lo tiene el archivo de configuración donde se describe el comportamiento de la aplicación.

Van de la mano porque necesitas hacer tu diseño se comporte en base a inyeccion de dependencias, y luego va más alla al usar IoC.

Saludos.

[masterpuppet]

La linea es fina, demasiado para mi gusto, dejo una referencia http://martinfowler.com/articles/injection.html y cito:

As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.

IMO, IoC es una técnica o practica y DI es una forma de conseguirlo al igual que lo es ServiceLocator(para algunos anti-pattern).

Saludos.