design-patterns - method - patrones de diseño de software ejemplos

¿Por qué necesitamos un patrón de diseño de fábrica abstracto? (13)

La mayoría de la definición dice:

Una fábrica abstracta proporciona una interfaz para crear familias de objetos relacionados sin especificar sus clases concretas

¿Cuál es el uso de Abstract Factory Pattern ya que podemos lograr la tarea mediante la creación de objetos de la clase concreta en sí misma? ¿Por qué tenemos un método de fábrica que crea el objeto de la clase Concrete?

Por favor dame algún ejemplo de la vida real donde debo implementar el patrón de AbstractFactory?

¿Cuál es el uso de Abstract Factory Pattern ya que podemos lograr la tarea mediante la creación de objetos de la clase concreta en sí misma? ¿Por qué tenemos un método de fábrica que crea el objeto de la clase Concrete?

En ausencia de Abstract Factory , el Cliente debe conocer los detalles de las clases concretas. Este acoplamiento hermético se ha eliminado con Abstract Factory .

Ahora Factory Method expone un contrato, ese cliente tiene que usar. Puede agregar más productos a su fábrica agregando nuevos productos, que implementan la interfaz expuesta por Factory Method.

Consulte estas preguntas relacionadas de SE para una mejor comprensión:

¿Cuál es la diferencia básica entre Factory Factory y Abstract Factory Patterns?

Intención:

Proporcione una interfaz para crear familias de objetos relacionados o dependientes sin especificar sus clases concretas.

Puede comprender la intención, la estructura, la lista de verificación y las reglas sourcemaking del patrón Abstract Factory de este artículo de sourcemaking .

Lista de verificación:

Decida si los servicios de creación e independencia de la plataforma son la fuente actual de dolor.
Trace una matriz de plataformas versus productos .
Defina una interfaz de fábrica que consiste en un método de fábrica por producto.
Defina una clase derivada de fábrica para cada plataforma que encapsula todas las referencias al nuevo operador.
El cliente debe retirar todas las referencias a las nuevas y usar los métodos de fábrica para crear los objetos del producto .

Este patrón es particularmente útil cuando el cliente no sabe exactamente qué tipo crear. Como ejemplo, digamos que un Showroom que vende exclusivamente teléfonos celulares recibe una consulta para los teléfonos inteligentes fabricados por Samsung. Aquí no sabemos el tipo exacto de objeto que se creará (suponiendo que toda la información de un teléfono esté envuelta en forma de un objeto concreto). Pero sí sabemos que estamos buscando teléfonos inteligentes fabricados por Samsung. Esta información puede utilizarse realmente si nuestro diseño tiene una implementación abstracta de fábrica.

Comprender e implementar el patrón abstracto de fábrica en C #

Abstract Factory es un patrón de diseño muy central para Dependency Injection (DI). Aquí hay una lista de preguntas sobre el desbordamiento de pila donde la aplicación de Abstract Factory ha sido aceptada como la solución.

Según mi entender, estas preguntas representan preocupaciones o problemas reales que las personas tenían, por lo que deberían comenzar con algunos ejemplos de la vida real:

Creo que hay un lugar para el patrón de fábrica abstracto en lugar del patrón de fábrica simple en lugares donde sus instancias son muy complicadas, demasiado complicadas y feas para una sola fábrica y demasiado complicadas para que la interfaz de usuario las comprenda.

Digamos que esta es una marca TYPE_A, no una sola clase ... digamos que hay una familia de 100 tipos de clases similares de Tipo-A y necesita crear una instancia de un objeto a partir de ellos. Imagine que hay un detalle de información sofisticada necesaria para hacer el objeto correcto de una marca de muchos tipos similares de objetos, y en esta entidad de objeto necesita saber exactamente qué parámetros afinar y cómo ajustarlos.

En la fábrica especial para esta marca, los haremos diferenciar y obtener el objeto exacto para crear instancias y también cómo crear una instancia. lo sabremos de acuerdo con la información de la red (digamos qué color está disponible en la tienda en línea) y de otras aplicaciones y servicios que se ejecutan en segundo plano (parámetros que la interfaz de usuario no conoce).

Y tal vez mañana tendremos otra familia, digamos type_B y type_C para instanciar. Entonces, la IU tendrá el "si más" para saber si el usuario quiere un "tipo_A", "tipo_B" o "tipo_C" - pero las clases de las fábricas decidirán exactamente qué clase del tipo (de la familia) construir, y cómo ajustarlo: qué valores establecer para sus parámetros o enviar a su contratista. Todo esto, según muchos parámetros de los que la interfaz de usuario no tiene conocimiento. Todo esto será demasiado para una sola clase de fábrica.

Digamos que creas a.jar, y otra persona usa tu jar y quiere usar un nuevo objeto concreto en tu código. Si no está utilizando la fábrica abstracta, entonces ella tiene que modificar su código o sobrescribir su código. Pero si está utilizando una fábrica abstracta, puede proporcionarle una fábrica y pasarle el código, y todo está bien.

Versión refinada: Considere el siguiente escenario: alguien más escribió un marco. El marco utiliza una fábrica abstracta y algunas fábricas de hormigón para crear muchos objetos en tiempo de ejecución. De modo que puede registrar fácilmente su propia fábrica en el marco existente y crear sus propios objetos. El marco está cerrado a modificaciones y aún es fácil de ampliar debido al patrón abstracto de fábrica.

Encuentro el patrón Abstract Factory sobrevalorado.

En primer lugar, no sucede tan a menudo que tenga un conjunto de tipos interrelacionados que quiera crear una instancia.

En segundo lugar, el nivel de indirección (abstracción) proporcionado por las interfaces normalmente es suficiente cuando se trabaja con inyección de dependencia.

El ejemplo típico de WindowsGui vs MacGui vs ... donde tendría un WindowsButton, MacButton, WindowsScrollBar, MacScrollbar, etc. a menudo es más fácil de implementar definiendo botones concretos , barras de desplazamiento, etc. utilizando el patrón de visitante y / o intérprete para proporcionar comportamiento real

Es fácil, imaginando que tienes un código que funciona con la abstracción, debes crear abstracciones y no clases concretas.

Siempre debe trabajar contra las abstracciones porque puede modificar el código mejor.

Este es un buen ejemplo: http://en.wikipedia.org/wiki/Abstract_factory_pattern#C.23

Las fábricas abstractas son geniales para soportar múltiples plataformas mientras mantienen unificada su base de código. Supongamos que tiene un gran programa Qt o GTK + o .NET / Mono que desea ejecutar en Windows, Linux y OSX. Pero tiene una característica que se implementa de forma diferente en cada plataforma (quizás a través de la API kernel32 o una característica POSIX).

public abstract class Feature { public abstract int PlatformSpecificValue { get; } public static Feature PlatformFeature { get { string platform; // do platform detection here if (platform == "Win32") return new Win32Feature(); if (platform == "POSIX") return new POSIXFeature(); } } // platform overrides omitted }

Con esta Abstract Factory, su UI no necesita saber nada sobre la plataforma actual.

Feature feature = Feature.PlatformFeature; Console.WriteLine(feature.PlatformSpecificValue);

Para responder directamente a su pregunta, probablemente pueda escapar sin utilizar un patrón de diseño de este tipo.

Sin embargo, tenga en cuenta que la mayoría de los proyectos en el mundo real evolucionan y desea proporcionar algún tipo de extensibilidad para que su proyecto sea a prueba del futuro.

Según mi propia experiencia, la mayoría de las veces se implementa una fábrica y, a medida que el proyecto crece, se transforma en patrones de diseño más complejos, como Abstract Factory.

Se trata de dependencias. Si no te preocupa el acoplamiento y las dependencias estrechas, entonces no necesitas una fábrica abstracta. Pero importará tan pronto como escriba una aplicación que necesita mantenimiento.

Si entiendo bien, la pregunta es, ¿por qué tenemos tanto el método Factory como los patrones abstractos de fábrica? Necesita una fábrica abstracta cuando las diferentes clases polimórficas tienen un procedimiento de creación de instancias diferente. Y desea que algún módulo cree instancias y las use, sin conocer ningún detalle de la inicialización de objetos. Por ejemplo, desea crear objetos Java haciendo algunos cálculos. Pero algunos de ellos son parte de la aplicación, mientras que el bytecode de otro debe leerse desde el DB. Por otro lado, ¿por qué necesitamos un método de fábrica? De acuerdo, esa fábrica abstracta se superpone. Pero en algunos casos, es mucho menos código para escribir, tener menos clases e interfaces hace que el sistema sea más fácil de comprender.

Si observa los patrones de diseño, casi todos pueden ser redundantes. Pero qué patrón significa un enfoque comúnmente utilizado para una solución a un tipo similar de problemas. Un patrón de diseño le proporciona un enfoque de nivel de diseño o solución a un conjunto de tipo similar de problema de diseño. El uso de patrones de diseño lo ayudará a resolver su problema y, por lo tanto, a entregarlo más rápido.

Un ejemplo de la vida real para el uso del patrón Abstract Factory es proporcionar acceso a los datos a dos fuentes de datos diferentes (por ejemplo, una base de datos SQL y un archivo XML). Tiene dos clases de acceso a datos diferentes (una puerta de enlace al almacén de datos). Ambos heredan de una clase base que define los métodos comunes que se implementarán (por ejemplo, Cargar, Guardar, Eliminar).

La fuente de datos que se utilizará no debe cambiar la forma en que el código del cliente recupera su clase de acceso a datos. Su Abstract Factory sabe qué fuente de datos se utilizará y devuelve una instancia apropiada a petición. La fábrica devuelve esta instancia como el tipo de clase base.