Spring y Design Patterns

Introducción

En el mundo Java actual, es relativamente raro tener que escribir una funcionalidad técnica que sea completamente nueva. En su lugar, ensamblamos componentes ya construidos, basándonos en frameworks y librerías open source. Cada vez más se trata de implementar componentes funcionales reutilizables para agrupar y compartir los desarrollos tanto como sea posible. Por lo tanto, por una parte, debemos tener cuidado de no reinventar la rueda y, por otra, debemos esforzarnos por hacer que el código sea reutilizable.

De hecho, la mantenibilidad del código es un tema que se debe tomar en serio porque a menudo es un equipo el que codifica y otro el que posteriormente hace el mantenimiento. También es habitual que los proyectos sean a largo plazo y estén basados en software a gran escala desarrollado durante varios años, además de que los desarrolladores solo hacen parte de la aplicación que será reutilizada por otros, con lo que cada pieza de software desarrollada se debe considerar como parte de un framework más grande y reutilizable a voluntad. Por lo tanto, el código debe ser modular, bien estructurado, documentado con javadoc (con @snippet en Java 18) y también debe poder ser verificado (y probado).

En el capítulo Documentación Spring REST Docs, veremos que también es posible documentar su código y API usando metadatos...

El singleton en Java

Un singleton es un objeto único en un espacio dado. Se crea la primera vez que se usa y luego se reutiliza. Lo usamos cuando queremos compartir un recurso o cuando queremos aprovechar la reentrada del código para tener solo una copia de una secuencia de procesamiento para un objetivo determinado, es decir, un método único que varios procesos pueden utilizar, ya sea de manera secuencial en un sistema de un solo thread o de manera concurrente (simultánea), gracias a la reentrada en un sistema multi thread.

1. Objetivo

Históricamente, cuando necesitábamos una acción, la implementábamos en el objeto que la requería. Por lo tanto, para un procesamiento idéntico había una multitud de copias de estas acciones en las diversas instanciaciones de los objetos que lo utilizaban. Esto se debía a que, en un sistema orientado a objetos, los procesos se encapsulan en objetos junto con los datos.

Para las acciones que no se basan en el estado del objeto que lo tiene, se decidió cambiar la acción a la parte estática de la clase. De hecho, la parte estática se comparte entre todas las instancias de la clase. Por lo tanto, no hay más duplicación de código en la memoria.

Algunos servicios se separan de los datos que procesan y, a continuación, se agrupan en clases no instanciadas como clases masivamente estáticas. Existe un sistema que, por un lado, separa los datos del procesamiento con los POJO, es decir, objetos sin procesamiento con excepción de los mecanismos de gestión de instancias (como constructores y descriptores de acceso) y, por otro lado, realiza el procesamiento separado de los datos como se haría en C. Con este tipo de arquitectura, alcanzamos rápidamente los límites del sistema.

En ese momento se desarrolla el singleton. Se trata de una clase que solo se instancia una vez y después todos la reutilizan. Soporta todos los conceptos de programación orientada a objetos. Por lo tanto, tenemos la simplicidad de uso de una clase, pero sin copias innecesarias.

Los primeros singletons (antes de que hubiera enumeraciones) usaban un código parecido al siguiente (en un sistema de un solo thread):

class MiSingleton 
   private static MiSingleton UNIQUE = null; 
   private MiSingleton(){ ...

Inversión de control

Con el principio de IOC (Inversion of Control o inversión de control), ya no se instancian las clases que implementan las funciones de una librería, sino que la aplicación las llama directamente. El programa indica que necesita una librería y se le proporciona de forma automática. Es un mecanismo externo que hace que la clase esté disponible a través de un framework o mecanismo de plugins. Por ejemplo, con Spring, la aplicación indica que necesita un servicio con una API específica y Spring le proporciona el mejor candidato.

Spring permite especificar el servicio deseado, a través de una interfaz en los casos más comunes o a través de una clase cuando no hay interfaz. Para esto, generalmente utiliza una Factory de objetos que, en sí misma, es un desing pattern para hacer que el objeto esté disponible.

List<String> lista = new ArrayList<String>(); 
UsuarioDao dao = (UsuarioDao) 
factory.getBean("usuarioDao"); 

Una buena costumbre que se debe tener en general en Java es declarar un objeto usando la interfaz que mejor lo caracterice. En lugar de instanciar un objeto usted mismo, se deja que Spring encuentre la clase que mejor corresponda al objeto que se va a instanciar.

Se llama al mecanismo de IOC de inyección de dependencias y se utiliza la anotación @Autowired o @Inject. Más adelante veremos...

Proxy

Spring utiliza mucho este desing pattern para todo lo relacionado con la programación orientada a aspectos (AOP) y el acceso remoto.

El AOP se describe en detalle en el capítulo Programación orientada a aspectos con Spring.

Spring no da acceso directo a los objetos, sino que lo hace a través de un objeto intermedio llamado proxy, que permite a Spring modificar el comportamiento del objeto original.

interface Pojo3 { 
    public void foo(); 
} 
 
class SimplePojo3 implements Pojo3 { 
    public void foo() { 
        System.out.println("foo"); 
    } 
} 
 
class RetryAdvice implements AfterReturningAdvice { 
   public void afterReturning(Object returnValue, Method method, 
         Object[] args, Object target) throws Throwable { 
      System.out.println("Después "+method.getName()); 
   } 
} 
 
public class MainConAspect { 
    public static void main(String[] args) { 
        ProxyFactory factory = new ProxyFactory(new SimplePojo3()); 
        Class<?>...