ViewHelper dilema newable / inyectable

Question

Estoy tratando de diseñar una aplicación siguiente ideas Misko Heverys . Es un experimento interesante y un reto. Actualmente estoy luchando con mi aplicación ViewHelper.

El ViewHelper desacopla el modelo de la vista. En mi aplicación que envuelve el modelo y proporciona la API para la vista de su uso. Estoy usando PHP, pero espero que la implementación sea legible para todos:

class PostViewHelper {
    private $postModel;

    public function __construct(PostModel $postModel) {
         $this->postModel = $postModel;
    }

    public function title() {
         return $this->postModel->getTitle();
    }
}

En mi plantilla (ver) presentar este podría ser llamado como esto:

<h1><?php echo $this->post->title(); ?></h1>

Hasta aquí todo bien. El problema que tengo es cuando quiero conectar un filtro a los viewhelpers. Quiero tener los plugins que filtran la salida de la llamada del título (). El método podría ser como la siguiente:

public function title() {
    return $this->filter($this->postModel->getTitle());
}

Necesito conseguir observadores en allí, o un manejador de sucesos, o cualquier servicio (en lo que veo como un newable, por lo que debe ser pasado a través de la pila). ¿Cómo puedo hacer esto siguiendo los principios de Misko Hevery? Sé lo que puedo hacer esto sin él. Estoy interesado en la forma para que pueda tomar y actualmente no veo una solución. ViewHelper podría ser un inyectable también, pero a continuación, obtener el modelo existe el problema.

Answer 1

no he encontrado el blog al que hizo referencia muy interesante o profundo.

Lo que usted describe parece más a un decorador que nada que ver con la inyección de dependencia. La inyección de dependencia es ¿Cómo a construir su gráficos de objetos, no su Estado una vez construida.

Dicho esto, yo sugeriría tomar su patrón decorador y correr con él.

interface PostInterface
{
    public function title();
}

class PostModel implements PostInterface
{
    public function title()
    {
        return $this->title;
    }
}

class PostViewHelper implements PostInterface
{
    public function __construct(PostInterface $post)
    {
        $this->post = $post;
    }

    public function title()
    {
        return $this->post->title();
    }
}

class PostFilter implements PostInterface
{
    public function __construct(PostInterface $post)
    {
        $this->post = $post;
    }

    public function title()
    {
        return $this->filter($this->post->title());
    }

    protected function filter($str)
    {
        return "FILTERED:$str";
    }
}

Se podría simplemente utilizar cualquier marco DI usted tiene que construir este gráfico de objetos de esta manera:

$post = new PostFilter(new PostViewHelper($model)));

A menudo utilizo este enfoque en la construcción de objetos anidados complejos.

Uno de los problemas que podría encontrarse es la definición de "demasiados" funciones en su PostInterface. Puede ser un dolor tener que aplicar estos en cada clase decoradora. Aprovecho las funciones mágicas PHP para evitar esto.

interface PostInterface
{
    /**
     * Minimal interface. This is the accessor
     * for the unique ID of this Post.
     */
    public function getId();
}


class SomeDecoratedPost implements PostInterface
{
    public function __construct(PostInterface $post)
    {
        $this->_post = $post;
    }

    public function getId()
    {
        return $this->_post->getId();
    }

    /**
     * The following magic functions proxy all 
     * calls back to the decorated Post
     */
    public function __call($name, $arguments)
    {
        return call_user_func_array(array($this->_post, $name), $arguments);
    }

    public function __get($name)
    {
        return $this->_post->get($name);
    }

    public function __set($name, $value)
    {
        $this->_post->__set($name, $value);
    }

    public function __isset($name)
    {
        return $this->_post->__isset($name);
    }

    public function __unset($name)
    {
        $this->_post->__unset($name);
    }
}

Con este tipo de decorador en uso, puedo anular selectivamente cualquier método que necesito para proporcionar la funcionalidad decorado. Cualquier cosa que no anulan se pasa de nuevo al objeto subyacente. Múltiples decoraciones pueden ocurrir todo ello manteniendo la interfaz del objeto subyacente.