Introduccion

1

Patrones de Diseño Creacionales en Software

2

Patrones Creacionales: Singleton, Factory, Abstract Factory, Builder, Prototype

Singleton

3

Patrón Singleton: Implementación y Uso en Programación Orientada a Objetos

4

Diagrama de Clases del Patrón Singleton en JavaScript

5

Diferencias entre JavaScript y TypeScript en patrones de diseño

6

Ventajas y desventajas del patrón Singleton en diseño de software

Factory

7

Patrones de Diseño: Introducción al Patrón Factory

8

Patrón Factory: Implementación y Detalles Esenciales

9

Implementación del Patrón Factory Method en JavaScript

10

Comparación del Patrón Factory en JavaScript y TypeScript

11

Patrón Factory: Ventajas y Desventajas en Desarrollo de Software

Abstract Factory

12

Patrón Abstract Factory: Estrategia para Múltiples Fábricas de Coches

13

Patrones de Diseño: Abstract Factory en Producción de Coches

14

Implementación del patrón Abstract Factory en JavaScript

15

Diferencias entre JavaScript y TypeScript en el patrón Abstract Factory

16

Patrón Abstract Factory: Ventajas y Desventajas

Builder

17

Patrón Builder: Diseño y Aplicación en Producción de Vehículos

18

Patrón Builder: Análisis de Diagrama y Clases Relacionadas

19

Implementación del Patrón Builder en Producción de Coches

20

Comparación del Patrón Builder en JavaScript vs TypeScript

21

Patrón Builder: Ventajas, Desventajas y Aplicaciones Prácticas

Prototype

22

Patrón Prototype: Clonación de Objetos en Diseño de Software

23

Patrón Prototype en JavaScript y TypeScript

24

Implementación del Patrón Prototype en JavaScript

25

Comparación de Prototype en JavaScript y TypeScript

26

Patrón Prototype: Ventajas y Desafíos en Diseño de Software

Conclusiones

27

Patrones Creacionales en Diseño de Software

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Patrón Factory: Implementación y Detalles Esenciales

8/27
Recursos

¿Qué es el Patrón Factory?

El Patrón Factory es un diseño comúnmente utilizado en programación orientada a objetos para instanciar objetos sin especificar su clase concreta. Este enfoque permite a las aplicaciones ser más flexibles y fáciles de mantener. En el mundo de la fabricación de software, este patrón garantiza que el proceso de creación de objetos sea uniforme, independientemente de su tipo concreto.

¿Cuáles son los pasos para implementar el Patrón Factory?

  1. Declarar una clase o interfaz producto base: Esta clase puede tener ciertas operaciones y atributos comunes. Sirve como el punto de referencia para todas las subclases o implementaciones que se derivarán de ella.

    interface Producto {
        void algunasOperaciones();
    }
    
  2. Implementar subclases de productos concretos: Estas subclases heredan o implementan la clase o interfaz producto base, redefiniendo métodos comunes si es necesario para cumplir con la naturaleza polimórfica.

    class ProductoA implements Producto {
        public void algunasOperaciones() {
            // Implementación específica para ProductoA
        }
    }
    
    class ProductoB implements Producto {
        public void algunasOperaciones() {
            // Implementación específica para ProductoB
        }
    }
    
  3. Declarar una clase o interfaz Factory: Esta clase tiene como objetivo retornar objetos que coincidan con el tipo base del producto, no con las subclases concretas.

    abstract class Factory {
        abstract Producto makeProduct();
    }
    
  4. Implementar las clases Factory concretas: Estas clases son responsables de retornar productos concretos en su método de fábrica. La clase concreta decide qué instancia de la clase producto base crear.

    class ConcreteFactoryA extends Factory {
        Producto makeProduct() {
            return new ProductoA(); // Devuelve un nuevo ProductoA
        }
    }
    
    class ConcreteFactoryB extends Factory {
        Producto makeProduct() {
            return new ProductoB(); // Devuelve un nuevo ProductoB
        }
    }
    

¿Cómo se gestionan las dependencias en el Patrón Factory?

En el Patrón Factory, es inevitable tener algunas dependencias entre las fábricas concretas y los productos concretos. Por ejemplo, si el nombre de ProductoA cambia, se necesitará ajustar el código en ConcreteFactoryA. Sin embargo, se deben minimizar estas dependencias para mantener el sistema flexible y escalable.

¿Qué considerar al implementar el Patrón Factory?

  • Abstracción sobre implementación: Le proporciona al desarrollador la flexibilidad de cambiar la implementación de las subclases sin modificar el código que usa dichas clases.

  • Polimorfismo: Permite a las clases concretas implementar métodos de una manera que sea específica a sus necesidades, garantizando así que el sistema general sea coherente.

  • Relación de dependencia: Entender que cada fábrica concreta depende de una implementación específica de producto, lo cual es una parte intrínseca del diseño.

Reflexión y comentarios

Tras entender el diagrama y el proceso de implementación del Patrón Factory, resulta útil reflexionar sobre cómo podría este patrón mejorar los procesos de desarrollo en tus proyectos actuales. ¿Te resultó claro el diagrama una vez que comprendiste los pasos? Participa en la discusión y comparte tus experiencias para aprender juntos.

Aportes 13

Preguntas 1

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

En resumen, se deben tener dos abstracciones: una para fábricas, para poder crear distintas fábricas, y otra para productos, para poder crear diferentes tipos de productos. Cada fábrica concreta puede crear productos concretos dependiendo de las relaciones entre ellas.

No entendi nada wey

Mi explicación

Voy a dividir los 4 pasos en 2: (1 y 2) y (3 y 4).

Pasos 1 y 2

Creamos una super clase/interfaz Product que definirá la estructura base de todos los productos. Todas las sub clases/implementaciones de la super clase/interfaz Product se consideran de tipo Product también, pues comparten la misma estructura (no sé si sería bueno mencionar las relaciones de herencia/implementación vistas en el curso anterior).

Pasos 3 y 4

Creamos una super clase/interfaz Factory que devuelva objetos que sean de tipo Product. No importa cuál.
Por último, creamos fabricas concretas (o también fabricas especificas) para cada producto en particular. Estas fabricas concretas heredan/implementan de la super clase/interfaz Factory.
.
De esta forma, todos nuestros productos siguen una estructura base, y todas nuestras fabricas siguen una estructura base también.

Esto me toma más tiempo porque estoy llevando los digramas a texto en vim. Lulz.

Yo tuve que ver esta clase tres veces y ejemplificar con modelos reales para entender el diagrama 😅

Yo lo veo de esta forma el diagrama:

Product -> Pizza
ProductA -> Pizza hawaiana
ProductB -> Pizza con champiñones

Factory -> Fabrica de pizzas
ConcreteFactoryA -> Solicitud de hacer una pizza hawaiana
ConcreteFactoryB -> Solicitud de hacer una pizza con champiñones

Comentame si tienes algun cambio a mi propuesta del ejemplo o si tienes otro ejemplo modelado, ¡Será un placer leerte!

A mi se me hace más fácil entender el diagrama considerando todos los Product’s como interfaces, ya que en ese sentido, las Factories deben cumplir con ese contrato.
Eso para mi es mucho más sencillo de entender, porque si Product’s es tomado como clases, lo encuentro un poco más complicado

Gracias profesor, el diagrama explica mucho dondé y porqué se utiliza la POO para el diseño del sistema y su programación
Buenísima explicación, entendí todo, gracias :D
les recominedo mucho este recurso para entender correctamente el diagrama: <https://refactoring.guru/es/design-patterns/factory-method>
nunca habia vistoo este patron formalmente, pero me hace mucho sentido , es como si cuando vi poo este ubierea sido el ejemplo con el que me explicaron como interactuan las clases y subclases
Pues aqui un ejemplo de como seria en java: ```java public class Main {    public static void main(String\[] args) {        Factory factoryA = new ConcreteFactoryA();        Factory factoryB = new ConcreteFactoryB();         Product productA = factoryA.makeProduct();        Product productB = factoryB.makeProduct();         System.out.println(productA.doProductOperation());        System.out.println(productB.doProductOperation());    }} interface Product {    String doProductOperation();} interface Factory {    Product makeProduct();} class ProductA implements Product {    @Override    public String doProductOperation() {        return "making a ProductA product...";    }} class ProductB implements Product {    @Override    public String doProductOperation() {        return "making a ProductB product...";    }} class ConcreteFactoryA implements Factory {    @Override    public Product makeProduct() {        return new ProductA();    }} class ConcreteFactoryB implements Factory {    @Override    public Product makeProduct() {        return new ProductB();    }} ```

si, fue claro! ♥