Skip to content

Latest commit

 

History

History
85 lines (67 loc) · 10.7 KB

README.md

File metadata and controls

85 lines (67 loc) · 10.7 KB
Raw

Codigo Limpio

Pre-requisitos de la sesión en vivo

Actividad

  • 1.- Implementacion de un patron creacional dentro de la aplicacion.
  • 2.- Identificar el uso de un patron creacional dentro del framework de Spring.

Desafio para recordar el tema anterior

Los ejemplos que se vieron en clase se pueden encontrar dentro de la carpeta CreationalPatterns en este repositorio

  1. La actividad consiste en completar el ejemplo de Abstract Factory que se vio en la clase, agregando los elementos de Logo y Checkbox.
  2. Como actividad opcional para practicar, agregar un nuevo prototipo de avion al patron Prototype y crear clones.

Codigo de los patrones creacionales

  • En este repositorio encontraras un folder llamado "CreationalPatterns", el cual contiene la implementacion en codigo de cada patron creacional vistos en sesiones anteriores.
  • En el siguiente path src/main/java encontraras el codigo de los 5 patrones creacionales divididos en carpetas.

Estructura de los patrones

  • Cada patron de diseño esta estructurado de manera que tiene una clase llamada clase llamada Client.java, esta clase es la encargada de ejecutar el patron deseado.
  • Dependiendo de la complejidad de cada patron creacional, puede tener una o mas clases adicionales a la clase principal.

1. Singleton (Simulando una conexion a base de datos)

  • La clase DatabaseConfig muestra la implementacion del patron singleton.
  • La clase Client es encargada de obtener la instancia.

2. Prototype (Creando clones de aviones)

  • A partir de la interfaz PlaneMold se implementaran las clases requeridas para hacer los clones/prototipos.
  • Se crearon dos aviones MiG28Plane y MigG29Plane que implementan la interfaz indicada en el punto anterior.
  • Ahora la clase Cliente preguntara al usuario la cantidad de clones de tipo MiG28Plane a crear, finalmente se mostrara el hashCode de cada avion para corroborar que se crearon clones.

3. Factory Method (Enviando diferente tipo de notificaciones)

  • Dentro del folder notifications se encuentra una interfaz llamada Notification acompañada de otras clases que indican los tipos de notificaciones disponibles, para este ejemplo se utilzan notificaciones de tipo Email, Push y SMS, todas las notificaciones van a implementar a su padre la interfaz Notification, ya que compartiran cierta funcionalidad.
  • Dentro del folder factory se encuentra la clase NotificationFactory encargada de crear y regresar al cliente el tipo de notificacion deseada en base a un parametro, para este ejemplo una cadena de texto llamada "channel".
  • La clase Cliente simplemente llama a la fabrica de notificaciones indicandole el tipo de notificacion quiere enviar, delegandole a la fabrica todo el proceso de creacion.

4. Abstract Factory (Renderizado de una aplicacion)

  • En este ejemplo se busca simular la renderizacion de una aplicacion que sea compatible con los diferentes sistemas operativos Linux, Windows y MacOs. Para ello se necesitan crear tres fabricas que a su vez seran encargadas de crear los diferentes tipos de elementos a renderizar.
  • Dentro de la carpeta factories se encuentra una interfaz llamda GUIFactory y sus implementaciones correspondientes para cada OS.
  • La idea es que cada factory LinuxFactory, MacOSFactory y WindowsFactory implemente de la interfaz y sean las encargadas de crear los elementos que corresponden a ese OS.
  • Por ejemplo la fabrica de Windows sera encargada de crear el Button, Checkbox y Logo que sea compatible. Asi que se creara un folder llamado buttons con una interfaz Button la cual contendra la funcionalidad en comun de un boton.
  • Por lo que la clase Button tendra tres implementaciones LinuxButton, MacOsButton y WindowsButton, lo mismo se tendra que hacer para el Checkbox y Logo, y demas elementos que se quisieran agregar.
  • La clase Application es la encargada de llamar al factory deseado para renderizar la aplicacion, teniendo un constructor parametrizado se le indica el tipo de factory que se desea y se encargara de crear los elementos:
    public Application(GUIFactory factory) {
        button = factory.createButton();
        //Aqui se iran agregando los demas elementos como el checkbox y el logo
    }
  • Finalmente la clase Cliente recibe la entrada del usuario sobre la aplicacion que quiere renderizar, para Windows, MacOs o Linux y crea la instancia de esa fabrica para poder crear la aplicacion del tipo de OS deseado y pintarla.

5 Builder

  • Se consideraron dos implementaciones para el patron de builder, el ejemplo relacionado a la creacion de una casa es una implementacion que agrega un arquitecto o director que se encargara de construir la casa. Y el segundo ejemplo es una creacion de un usuario.

5.1 Builder (Casa)

  • Esta implementacion considera el tener un arquitecto/director que vas ser el encargado de indicarle al builder que construya la casa. Por lo que el Builder funcionara como constructor, ademas de agregar otros builders dependiendo del tipo de casa que se quiera crear.
  • Dentro de la carpeta rooms se encontraran los diferentes tipos de cuartos disponibles para construir la casa.
  • Finalmente el Cliente es quien se encargara de hablarle al director para que construya la casa dependiendo de los requerimientos que se le indiquen.

5.2 Builder (Usuario)

  • Este ejemplo es mas sencillo y mas utilizado dentro de la programacion, ya que nos indica como podemos crear un usuario con diferentes caracteristicas a partir de un Builder.
  • Dentro de la clase User estaran los atributos requeridos para la creacion de este, ademas se encontrara una clase interna llamada Builder, esta es otra manera de implementar el patron builder.
  • Ademas de que ya no estamos incluyendo un arquitecto o director para esta implementacion, esto dependera de las necesidades y requerimientos.
  • Al final en el Cliente se estan creando diferentes tipos de usuarios, ocultando la complejidad de la creacion.

📚 Para aprender mas

  • Book: Design Patterns: Elements of Reusable Object-Oriented Software

Material Autoestudio

- TDD vs BDD

- SOLID