Devdiaries

• El patrón de fábrica
  • Intención
  • Solución de problemas
  • Estructura del Patrón de fábrica
  • Patrón abstracto de fábrica
  • Implementación del Patrón de fábrica en primavera
  • Patrón de fábrica uso popular casos en el Marco de Primavera
• El patrón del constructor
  • Intención
  • Solución de problemas
  • Estructura del Patrón del Constructor
  • Implementación del patrón del constructor en primavera
• El patrón único
  • Intent
  • Solución de problemas
  • Estructura del Patrón Singleton
  • Patrón Singleton implementación ejemplar en primavera
  • Patrón Singleton vs Singleton Spring
• El patrón de prototipo
  • Intención
  • Solución de problemas
  • Estructura del Patrón de prototipo
  • Implementación de patrón de prototipo en primavera
• Conclusión

Los patrones de diseño creacional se ocupan de los mecanismos de creación de objetos, tratando de crear objetos de una manera adecuada a la situación. En este artículo, describiré los patrones más populares en esta categoría y cómo los usa Spring.

El patrón de fábrica

El resorte, en sí mismo, ya es una implementación de ejemplo del patrón de fábrica. El patrón se utiliza en todo el marco. Uno de los lugares principales que se utiliza es la clase BeanFactory.

Intent

• El patrón de fábrica permite la construcción de clases similares de diferentes tipos utilizando un método de fábrica
• La llamada al método crea el objeto para usted
• Los objetos creados son instancias de clases que comparten una interfaz o subclase

Solución de problemas

• Gracias al Patrón de diseño de fábrica, no tiene que preocuparse por la construcción de clases en más de un lugar.
• Le permite aprovechar la interfaz para operaciones repetitivas.
• Los errores de copiar y pegar son menos probables.

Estructura del patrón de fábrica

En primer lugar, debe crear una interfaz común que vaya a usar en la fábrica de objetos. Luego, debe crear una clase que cree instancias de su inteface. En esa clase, debe implementar un método que sirva clases concretas que luego implementará desde la propia interfaz. Así que, de nuevo, tenemos una clase que tiene un método que crea instancias de la interfaz cuando está bajo la cobertura de que realmente está creando instancias en la clase concreta.

Patrón de fábrica abstracto

El patrón de fábrica abstracto es un patrón muy similar al Patrón de fábrica. Se puede decir que es una Fábrica de fábricas. En pocas palabras, hay dos diferencias principales entre el Patrón de Fábrica y la Fábrica Abstracta:

• Patrón de diseño abstracto de fábrica crea Fábrica
• El patrón de diseño de fábrica crea productos

 public abstract class AbstractFactory { public abstract Product1Base CreateProduct1(); public abstract Product2Base CreateProduct2(); } class ConcreteFactory1 extends AbstractFactory{ @Override public Product1Base CreateProduct1() { return new ConcreteProduct1(); } @Override public Product2Base CreateProduct2() { return new ConcreteProduct2(); } } class ConcreteFactory2 extends AbstractFactory{ @Override public Product1Base CreateProduct1() { return new ConcreteAnotherProduct1(); } @Override public Product2Base CreateProduct2() { return new ConcreteAnotherProduct2(); } } 

La clase AbstractFactory es responsable de crear varios tipos diferentes (en contraste con el Patrón de fábrica). Como puede ver en el ejemplo anterior, cada una de las fábricas puede estar asociada con diferentes objetos dentro del mismo grupo (en este caso, productos).

Implementación de patrones de fábrica en primavera

Echemos un vistazo a la interfaz anterior:

 public interface Animal { void setName(String name); String getName(); String getType(); void makeASound(); }

Animal la interfaz tiene varios métodos que son comunes a todos los animales (cada animal tiene un tipo y un nombre). Por lo tanto, ahora necesita crear una nueva clase: AnimalFactory

 @Component public class AnimalFactory { public Animal createAnimal(String type) { switch (type) { case "bird": return new Bird(); case "cat": return new Cat(); default: throw new UnsupportedOperationException("Unsupported animal type!"); } } }

Agregué anotación @Component porque quiero que el Resorte administre esta fábrica. Hay un método (método de fábrica)que devuelve un animal – createAnimal. Es una fábrica muy sencilla que soporta solo dos tipos de animales (gato, pájaro). Si se proporciona otro tipo, se lanzará una excepción.

Vamos a crear un controlador de resorte- FactoryController:

 @RestController @RequestMapping("/") public class FactoryController { private AnimalFactory factory; @Autowired public FactoryController(AnimalFactory factory) { this.factory = factory; } @PostMapping("addAminal/{type}/{name}") public Animal addAnimal(@PathVariable String type, @PathVariable String name) { Animal animal = this.factory.createAnimal(type); animal.setName(name); animal.makeASound(); return animal; } }

Agregué un método @PostMapping, que pasaremos por el tipo @PathVariable y el nombre del animal. En respuesta, obtendremos el nuevo objeto animal creado por la fábrica. Probémoslo usando un cartero: Registros de aplicaciones:

Como puede ver, acabamos de crear un nuevo objeto: un pájaro usando nuestra fábrica.

Patrón de fábrica casos de uso populares en Spring Framework

El marco de resorte utiliza el patrón de diseño de fábrica para la creación de los objetos mediante dos enfoques:

• Contenedor de fábrica de flor de resorte (p. ej. org.springframework.beans.factory.BeanFactory): Es el contenedor más simple en el marco de resorte que proporciona el soporte básico para DI
• Contenedor de texto de aplicación de resorte (p. ej.g ) – t es otro contenedor presente en el contenedor spring que agrega funciones adicionales específicas de la empresa, como publicar eventos de aplicaciones en los oyentes de eventos atentos o cargar mensajes desde un archivo de propiedades.

Como puede ver, todo el resorte ya es una implementación de ejemplo del patrón de fábrica (el contexto de aplicación de cualquier aplicación de resorte es solo una fábrica gigante)

El patrón del constructor

Otro patrón de creación común es el patrón del constructor. El uso popular de Builder en la primavera es ResultAction. Esta clase es parte del MockMcv – usado para probar aplicaciones web.

Intent

• Cada método devuelve la referencia de objeto desde la que se llama.
• Hay un método build() que devuelve un objeto completamente con estructura (basado en todas las llamadas intermedias).

Solución de problemas

• Mejora la legibilidad del código cuando la creación de objetos tiene muchos parámetros.
• Útil cuando algunos o todos los parámetros son opcionales.

Estructura del patrón del constructor

En primer lugar, debe definir una clase base con todo el constructor args. Luego, debe crear una clase de constructor con atributos y configuradores para cada argumento de la clase base. Cada armador debe devolver el constructor. Luego, necesita crear un build() methid que construirá y devolverá el objeto de la clase base.

Implementación de patrón de constructor en primavera

Comencé mi implementación con una clase Java simple – Employee.java:

 public class Employee { private String firstName; private String lastName; private String employeeId; private String email; public Employee(String firstName, String lastName, String employeeId, String email) { this.firstName = firstName; this.lastName = lastName; this.employeeId = employeeId; this.email = email; } public Employee() { } public String getFirstName() { return firstName; } public String getLastName() { return lastName; } public String getEmployeeId() { return employeeId; } public String getEmail() { return email; } }

Hay un par de atributos, contructor y captadores generados automáticamente. Es hora de implementar el patrón de constructor! Para ello, cree la clase EmployeeBuilder con los mismos campos que la clase Employee. Generar setters-uno para cada uno de nuestros campos. Si genera setters por IDE, debe recordar cambiar el tipo devuelto por setter (void) a EmployeeBuilder.

 public class EmployeeBuilder { private String firstName; private String lastName; private String employeeId; private String email; // Each setter returns EmployeBuilder object. public EmployeeBuilder setFirstName(String firstName) { this.firstName = firstName; return this; } public EmployeeBuilder setLastName(String lastName) { this.lastName = lastName; return this; } public EmployeeBuilder setEmployeeId(String employeeId) { this.employeeId = employeeId; return this; } public EmployeeBuilder setEmail(String email) { this.email = email; return this; } public Employee buildEmployee() { return new Employee(firstName,lastName, employeeId, email); } }

Al final utilizo el método public Employee buildEmployee() que crea al empleado. La ventaja de esta solución es que si alguno de nuestros campos null, null pobladas. No tenemos que pensar en dónde van los nulos. Echemos un vistazo a la acción. Creé el controlador de resorte BuilderController que tiene dos extremos. El primero crea un empleado con todos los campos, el segundo crea un empleado sin un correo electrónico:

 @RestController @RequestMapping("/builder") public class BuilderController { @GetMapping("employee1") public Employee getEmployee1() { return new EmployeeBuilder() .setEmployeeId("1234") .setEmail("[email protected]") .setFirstName("John") .setLastName("smith") .buildEmployee(); } @GetMapping("employee2") public Employee getEmployee2() { return new EmployeeBuilder() .setEmployeeId("4321") .setFirstName("Jeff") .setLastName("Freeman") .buildEmployee(); } }

Como es de esperar, la solicitud GET en el primer edpoint devuelve:

El segundo extremo devuelve al empleado con un valor nulo como correo electrónico:

El patrón Singleton

Singleton es un patrón utilizado por todos los desarrolladores de Java que usan Spring. Cada frijol es por defecto un singleton. Su propósito es proporcionar la posibilidad de crear solo un objeto de una clase dada y proporcionar acceso global a él.

Intent

• Solo hay un constructor privado.
• La clase almacena la referencia a la instancia de sí misma.
• Existe el método getInstance () que devuelve una referencia de instancia de clase singleton o construye un nuevo objeto si no se construye.

En el patrón Singleton, Java new Class nunca se llama en la clase, excepto en el caso getInstance. Debe envolver este método con alguna funcionalidad de bloqueo para garantizar la seguridad de múltiples hilos.

Solución de problemas

Singleton se puede usar en casos:

• La creación de objetos es cara.
• La clase que almacena la configuración de la aplicación. Desde cualquier parte del sistema, podemos modificarlo y queremos que los cambios sean visibles desde cualquier lugar. Al mismo tiempo, no podemos permitir que se mantengan diferentes versiones de configuraciones en el sistema.
• Debe almacenar el estado estático de varias partes de la aplicación.
• Necesita controlar quién tiene acceso a un objeto (control de concurrencia).

Estructura del patrón Singleton

Hay muchas maneras de implementar un singleton, pero todas se pueden reducir a tres puntos principales:

• Primero tiene que crear un constructor privado en su clase Singleton
• Luego, crear un identificador de instancia que se almacena en la clase
• Crear método estático getInstance() que utiliza un bloque sincronizado en el objeto para reducir el riesgo de seguridad del subproceso.

Implementación ejemplar de patrón Singleton en primavera

En el siguiente ejemplo, implementaremos nuestro propio Singleton. Luego demostraremos que los componentes de resorte son singletones por defecto. Comencemos con la creación de un par de clases. La primera que vamos a crear es la clase Singleton.java que será un singleton tradicional (descrito en el punto anterior):

public class Singleton { private static Singleton instance; private Singleton(){} public static Singleton getInstance() { if(null == instance){ synchronized (Singleton.class){ if(null==instance) { instance = new Singleton(); } } } return instance; } }

Ahora, cree una clase simple Spring @Component sin lógica:

@Component public class SpringSingleton { }

A continuación, probemos si nuestros singletons se aseguran de que solo se cree un objeto. Utilicé la prueba JUnit (generada automáticamente al crear un proyecto de arranque de resorte en Spring Initializer):

@RunWith(SpringRunner.class) @SpringBootTest public class SpringDesignPatternsApplicationTests { @Autowired SpringSingleton springSingleton1; @Autowired SpringSingleton springSingleton2; @Test public void singletonObjectsShouldBeEquals() { Singleton singleton1 = Singleton.getInstance(); Singleton singleton2 = Singleton.getInstance(); // Checking if the Singleton objects are definitely one, the same object Assert.assertSame(singleton1, singleton2); // Checking if the spring components are definitely singletons Assert.assertSame(springSingleton1, springSingleton2); } }

assertSame() método comprueba si los argumentos son los mismos objetos. Resultado de la prueba: aprobado, todo fue igual. Así es como puedes escribir singletons tradicionales o singletons en primavera.

Patrón de monoplazas vs Monoplazas de resorte

Hay una cosa más que debe saber. Como escribí, todos los frijoles de primavera son individuales por defecto. Sin embargo, estos no son los mismos singletons que los singletons tradicionales. El patrón Singleton tradicional asume que solo hay una instancia de una clase dada en el espacio administrado por Java classloader. En primavera, solo hay una instancia de Bean para cada instancia de contexto dado (_org.springframework.context.ApplicationContext). Por lo tanto, si tiene más de un contexto, todo administrado por el mismo cargador de clases Java, probablemente tendrá más de una instancia de un bean.

El patrón de prototipo

El prototipo es un patrón cuyo propósito es copiar objetos del objeto padre. En el patrón de prototipo, se crea un nuevo objeto clonando un objeto existente. En Java, el método clone() es una implementación de este patrón de diseño.

Intent

• La instancia se clona en tiempo de ejecución para dar instancias nuevas que tienen el mismo estado
• En Java Se hace con la interfaz Cloneable /

Solución de problemas

El prototipo se puede utilizar en casos:

• Debe crear muchas instancias de objetos iguales o similares, y la clonación es más eficiente que crear instancias de objetos con la nueva palabra clave Java.
• Útil con objetos que deben ser seguros para hilos y deben almacenar el estado (e.g carritos de compras: donde desea tener el mismo comportamiento, pero los artículos individuales en el carrito son diferentes)

Estructura del patrón Prototipo

• Crear una clase base abstracta que implemente Cloneable.
• Extender la clase abstracta en instancias de prototipo.
• Anule el método clone() en esas instancias de prototipo: agregue el comportamiento específico de la clase.

PrototypePattern implementación en primavera

No implementaré el prototipo Java tradicional. Sin embargo, te mostraré cómo crear un prototipo de frijol en primavera. Creé una clase tonta: SpringPrototype.java

 public class SpringPrototype { }

En la clase de aplicación principal en primavera, definí un nuevo prototipo de frijol ajustando @Scope a prototipo:

 @Bean @Scope("prototype") public SpringPrototype prototype(){ return new SpringPrototype(); }

Prueba de JUnit:

 @Autowired SpringPrototype prototype1; @Autowired SpringPrototype prototype2; @Test public void prototypeObjectsShouldNotBeEquals() { Assert.assertNotSame(prototype1, prototype2); }

Inyecté dos instancias de la clase SpringPrototype con @Autowired. Al igual que en el ejemplo de Singleton, usé el método estático de Assert para verificar que las instancias creadas no sean las mismas. Mi prueba es verde. Es una prueba de que hay dos instancias diferentes del mismo objeto.

Conclusión

Espero que os haya gustado el post. Tenemos que conocer los patrones de creación más importantes utilizados en primavera. En el próximo post, aprenderemos sobre los patrones estructurales en Spring Framework!