¿Cómo hago que mi IDE PHP comprenda los contenedores de inyección de dependencia?

Question

Situación actual: tengo dependencias en mi proyecto que resuelvo mediante el uso de la inyección de dependencia. Quiero dar el siguiente paso lógico utilizando un contenedor de inyección de dependencia (DIC) para aliviar la gestión de mis dependencias y las clases de carga perezosa.

Miré Balde, Espinilla, y sfserviceContainer, realizó algunas pruebas y realmente aprecian cómo el trabajo de DIC. Probablemente iría por Pimple debido a su simplicidad y potencia cruda. Si no tuviera este problema:

Debido a la abstracción que ofrece DIC, la IDE que estoy usando (PhpStorm) ya no comprende lo que está sucediendo en mi código. No entiende que $ Container ['Mailer'] o $ Sc-> Mailer posee un objeto de clase. También probé NetBeans IDE: mismo problema.

Esto es realmente un problema para mí porque mi IDE se vuelve inútil. No quiero programar sin sugerencias de código, autocompletar y refactorizar herramientas al tratar con clases. Y no quiero que mi IDE encuentre todo tipo de falsos positivos al validar el código.

Entonces mi pregunta es: ¿alguien ha tratado con este problema y ha encontrado una solución?

Answer 1

Puede definir la clase de la variable 'manualmente':

/** @var YourClassType $mailer */
$mailer = $container['mailer'];

En phpstorm (y por estándares), use dos asteriscos y escriba el tipo de datos antes del nombre de la variable.

Puede escribir el tipo de datos sin el nombre de la variable (pero no el nombre sin el tipo de datos).

Answer 2

Si bien ciertamente puede decirle a su IDE el tipo de objeto sacado de su contenedor Cada vez que accedes a él Es mejor hacerlo una vez. Ambas soluciones siguientes implican subclasificar el contenedor. Acabo de comenzar a usar Pimple que recomienda hacer esto de todos modos.

Para contenedores que usan miembros de instancia a los que se accede con -> o expuesto a través de la magia __get Método, puede decirle a su IDE qué tipo tienen. Esto es genial porque no implica ningún análisis adicional cuando se ejecuta el código, solo el IDE se molesta.

/**
 * My container. It contains things. Duh.
 *
 * @property MyService $service
 * @property MyDao $dao
 */
class MyContainer extends Container { }

Para Pimple y otros contenedores que actúan como matrices, puede crear funciones de accesorios para los objetos de nivel superior que necesitará. Si bien significa más análisis cuando se crea el contenedor, debe hacerse una vez y mantenerse en APC. De todos modos, prefiero un método sobre el acceso a la matriz, ya que coloca la tecla de matriz fácil de olvidar dentro de un método automatizado.

class MyContainer extends Pimple
{
    /**
     * @return MyService
     */
    public function getMyService() {
        return $this['service'];
    }
}

Por cierto, para las variables en línea de inicio de tipo con @var en netbeans necesitas usar /* con un asterisco. Esto es no un comentario de bloques de documento y no funciona con /** o //. Además, el nombre viene antes del tipo.

public function foo() {
    /* @var $service MyService */
    $service = $container['service'];
    ...
}

Answer 3

Como los IDE no exectan el código, no lo saben y necesitan ayuda para usted. Sé que esto funciona para Eclipse y otros IDES también: sugiera el tipo de variable.

Ejemplo de netbeans / phpstorm / pdt / zendstudio

/* @var $mailer MailerInterface */
$mailer = $sc->mailer

El código completo comienza a funcionar nuevamente en $mailer.

Para PDT es importante que:

1. El comentario comienza con uno * solamente.
2. Primero el nombre de la variable, que la pista.

Variantes de comentarios alternativos

Como estaba sujeto a mucha discusión, puede diferir entre IDES. Sin embargo, la mayoría de las IDES admiten variables de insinción para las variables de código en línea en el camino anterior. Entonces, dependiendo del IDE, esto podría escribirse de manera diferente pero similar, como aquí con dos asteriscos en el frente:

/** @var $mailer MailerInterface */

Compatibilidad de phpdoc

Los analizadores de PHPDOC pueden tener un problema si imita el comment de DOC de clase VAR para el código en línea como así:

/** @var MailerInterface $mailer  */

Esa documentación se usa normalmente para variables de clase (@Var: documente el tipo de datos de una variable de clase). A PHPDOC luego le falta la definición de la variable de clase después del comentario que implica una carga para QA.

Sin embargo, algunos IDES ofrecerán finalización del código para variables simples también cuando se escriben en estilo PhPDOC CLAS-Variable. No sé si eso tiene efectos secundarios para la completación del código de la clase actual, ya que un nuevo miembro podría ser introducido que en realidad no existe.

Answer 4

Para los que vinieron aquí desde Google.

PhpStorm en realidad proporciona una forma de resolver este tipo de problema en lugar de escribir PHPDOC una y otra vez, creando y configurando .phpstorm.meta.php presentar en cierto modo descrito aquí Obtiene sin problemas que trabajan sin problemas e inspecciones de tipo autocompletos.

Answer 5

Sé que la pregunta es solo sobre DIC, pero hay un Silex Pimple Dumper Proveedor de servicios que arroja el contenedor a un archivo JSON. El mismo autor escribió un complemento para phpstorm que puede leer ese archivo y abrir el autocompletar con los nombres de servicio y su tipo (clase, cadena y etc.). Estoy usando esos dos componentes y puedo decir que son buenas opciones para la finalización automática para Silex/Pimple.

Answer 6

Pimple simplemente presente al Container Builder Principe. Si lo entiendes, ya no necesitas grano:

class Container
{
    private $shared = array();

    public function getService() {
        return new Service(
            this->getFirstDependence(),
            this->getSecondDependence()
        );
    }

    protected function getFirstDependence() {
        return new FirstDependence(
            this->getSecondDependence()
        );
    }

    protected function getSecondDependence() {
        return isset($this->shared[__METHOD__]) ? $this->shared[__METHOD__] : $this->shared[__METHOD__] =
        new SecondDependence(
        );
    }
}

De esta forma, Pimple no oculta el tipo de objeto en $ C mixta ['alguna clave']. Tendría sugerencias de autocompletar al editar su contenedor. PhpStorm puede autorizar el tipo de retorno del método de su código. Y tendrías un contenedor claro. Alguna vez puede anular el contenedor:

class TestContainer extends Container
{
    protected function getFirstDependence() {
        return new FirstDependenceMock(
        );
    }
}

Para ser honesto, el contenedor escrito en el Lanuage de 'Programación' es un camino incorrecto. La responsabilidad del contenedor es llevar un gráfico inicializado de objetos a la persona que llama. Tener acceso al 'lenguaje de programación' permite violar esa responsabilidad con fácil. Algunos DSL para configurar la dependencia son mejores. Además, la mayor parte de la información de dependencia original (Tipo de argumento de constructores) es simplemente ignorado por Pimple y SFDepenenceContainer, lo que hace que su configuración sea hinchada y frágil.