La estática es mala, pero ¿qué pasa con el patrón de fábrica?

Navega tus respuestas
13

Estoy en un proyecto de TDD, así que trato de mantener lo más posible las buenas prácticas involucradas en ese tipo de desarrollo. Uno de ellos es evitar tanto como sea posible estático y global.

Estoy enfrentando este problema: Tengo un objeto "artículo" que puede tener "opciones" ("artículos adicionales") vinculados a él.

No puedo encontrar la manera de tener un buen enfoque que no sea contraproducente o que genere demasiadas consultas porque estaría en una situación en la que todo está tan desacoplado que básicamente tendré que hacer una consulta por objeto. .

Desde mi perspectiva real, veo 3 opciones:

1) Construir dentro del artículo: 

class Article
{
    //[...]
    public function getArrOption(){
        //Build an array of Options instance.
        //return an array of Options.
    }
}

Pro: Directo hacia adelante

Const: Capacidad de mantenimiento: el objeto del artículo ahora contiene la lógica de construcción para el objeto Opción. Esto probablemente conducirá a la duplicación de código.

2) Usando un optionFactory 

class Article
{
    //[...]
    public function getArrOption(){
        return OptionFactory::buildFromArticleId($this->getId());
    }
}

Pro: La lógica de construcción no está fuera de la clase de artículo

Const: Estoy infringiendo la regla de "la estática es difícil de burlar", lo que hace que mi clase de artículo sea difícil de probar.

3) Separa todas las lógicas. 

//Build the array of Option instance in a controller somewhere, using a Factory:
$arrOption = OptionFactory::buildFromArticleId($article->getId());

Pro: El artículo solo maneja su propia responsabilidad, y no le importa el enlace de su "padre" a las opciones. Las cosas están realmente desacopladas.

Const: requerirá más código dentro del controlador cada vez que necesito acceder a las opciones. Eso significa que no debería nunca usar una Factory dentro de un objeto, y ese tipo de sonido me parece utópico ...

¿Cuál es la mejor manera de ir? (¿He echado de menos algo?) gracias.

Editar:

Por no mencionar que si no puedo llamar a la fábrica dentro de la clase, básicamente nunca puedo usar el patrón de inicialización lento ...

    
pregunta FMaz008 07.04.2011 - 21:28

2 respuestas

12

  1. La estática no es "mala", es inasignable. Aún puedes usarlo cuando la burla no tenga sentido.

  2. Eso no es un patrón de fábrica, parece un patrón de Repository, aunque puede que no lo sea. Factory es donde tiene varias clases con la misma interfaz / clase base y desea separar la lógica que decide qué clase devolver. El repositorio obtiene los datos de su repositorio, abstrayendo la implementación de ese repositorio (el artículo no necesita saber si sus opciones están almacenadas en la misma base de datos, otra, un archivo XML, un archivo CSV, lo que sea).

  3. Ha ignorado la posibilidad de darle a la clase de Artículos un objeto ObjectFactory (o Repository, o lo que sea) en el constructor en el que puede llamar al método buildFromArticle.

Mi PHP está oxidado, pero creo que se ve así: 

class Article
{
    private $_option_repository;

    public function __construct($option_repository) {
        $_option_repository = $option_repository;
    }

    //[...]

    public function getArrOption(){
        return $_option_repository->buildFromArticleId($this->getId());
    }
}

Creo que esto cumple con todas tus ventajas anteriores.

    
respondido por el pdr 07.04.2011 - 22:02
1

Aquí hay una cita del artículo que argumenta que nunca necesita métodos estáticos, que se ha demostrado que las fábricas abstractas son confusas y sugiere un ligero cambio de idioma hacia la inyección de dependencia como la solución.

  

El acoplamiento estrecho entre las instancias y sus clases rompe la encapsulación y, junto con la visibilidad global de los métodos estáticos, complica las pruebas. Al hacer que la inyección de dependencias sea una característica del lenguaje de programación, podemos eliminar por completo los métodos estáticos. Empleamos los siguientes cambios semánticos:

     

(1) Reemplace cada aparición de un global con un acceso a una variable de instancia;

     

(2) Deje que la variable de instancia se inyecte automáticamente en el objeto cuando se ejemplifique.

"Seuss: Desacoplar las responsabilidades de los métodos estáticos para una configurabilidad precisa"

Enlace de la máquina de Wayback

    
respondido por el nes1983 21.12.2012 - 11:52

Lea otras preguntas en las etiquetas

El mejor método para implementar una búsqueda filtrada Hacer un diagrama de arquitectura atractivo, pero a la vez técnico [cerrado]