Características

En esencia, hay un proyecto padre que es un repositorio. Contiene submódulos, los cuales a su vez también son repositorios por derecho propio, con todas las características propias de un repositorio.

Dentro del repositorio que contenga un submódulo, habrá un archivo .gitmodules que define los submódulos.

¿Cómo crear y usar un submódulo desde cero?

• Crear un repositorio principal y el submódulo:

  git init super-proyecto

• Luego, crea el repositorio que será el submódulo:

  git init mi-submodulo

• o bien clónalo:

   git submodule add <url-del-submodulo>

Ahora hay dos opciones:

• Si lo has creado con git submodule add sobre un repositorio online que ya existe, te habrás bajado su contenido a local, y se habrá creado un archivo .gitmodules en el parent. Ya estás listo para hacer commits en el submódulo y subirlos.
• Si lo has iniciado manualmente, crea, el repositorio online y copia la url. Haz el primer commit, y pushea el repositorio que será un submódulo a su correspondiente repositorio online. Ahora deberás posicionarte en la carpeta/repositorio parent y añadir el repositorio como un submódulo. De esta manera crearás el archivo .gitmodules:

   git submodule add <url-del-submodulo>

• Finalmente, y de ahora en adelante, cuando hayas subido cambios al repositorio del submódulo, sube a la carpeta superior, en este caso super-proyecto, y haz lo mismo con los cambios del submódulo en el repositorio de super-proyecto. Esto es necesario porque ambos repositorios son distintos, aunque uno esté conectado dentro de otro.

Otras operaciones que podrías necesitar

• Clonar un repositorio con submódulos:

   git clone --recurse-submodules <url-del-repo>

• Actualizar submódulos:

   git submodule update --remote

Conclusión

Con los submódulos, puedes mantener tu código modular y reutilizable, utilizando repositorios como dependencias externas de otros repositorios.

Los filtros en Spring Boot son una forma de interceptar, redirigir y modificar las solicitudes HTTP antes de que lleguen a los controladores, y también para manipular las respuestas antes de que se envíen al cliente. Esto es útil para una variedad de tareas, como autenticación, logging, y modificación de solicitudes o respuestas. Pueden aplicarse a todas las urls, o a urls específicas.

En Spring Boot, los filtros se implementan generalmente mediante la interfaz Filter.

Cómo funciona

Actúa como un middleware entre el servidor web de spring, y el DispatcherServlet. Al realizar una solicitud, el cliente envía una solicitud al servidor del spring, y ahí entra en acción el filtro. Al terminar la cadena de filtros, el DispatcherServlet de Spring recibe la solicitud. Cada filtro de dicha cadena puede operar sobre la solicitud o la respuesta, por ejemplo modificando los encabezados o verificando la autenticación. El orden en que se aplican los filtros se puede especificar en la configuración de la aplicación. Si es una response, el proceso es exactamente igual, pero a la inversa.

Métodos

En versiones anteriores era obligatorio sobreescribir estos dos métodos, pero ahora son opcionales:

• init: Se sobreescribe la implementación por defecto cuando es necesaria alguna tarea previa, como acceso a algún recurso.
• destroy: Se sobreescribe la implementación por defecto cuando por ejemplo es necesario liberar recursos…
• doFilter: el filtro recibe como argumentos un objeto con la solicitud o la respuesta y la cadena de filtros.

Creación de un Filtro en Spring Boot

1. Implementa la interfaz Filter:
   Crea una clase que implemente la interfaz Filter. Aquí puedes definir el comportamiento que deseas aplicar a las solicitudes o respuestas.

   @Component
   public class CustomFilter implements Filter {

       @Override
       public void init(FilterConfig filterConfig) throws ServletException {
           // Inicialización del filtro, si es necesario
       }

       @Override
    public void doFilter(ServletRequest request, 
                         ServletResponse response, 
                         FilterChain chain)
            throws IOException, ServletException {
           // Código con la implementación de la lógica del filtro

           // Continúa con la siguiente entidad en la cadena de filtros
           chain.doFilter(request, response);

       }

       @Override
       public void destroy() {
           // Limpieza del filtro, si es necesario
       }
   }

2. Registrar el Filtro:
   Puedes registrar el filtro en tu aplicación Spring Boot de dos formas principales:

• Usando @Component: Si usas la anotación, como en el anterior ejemplo, el filtro se registrará automáticamente. En este caso, se aplicará a todas las peticiones.

• Manualmente en una clase @Configuration, lo que permite más granularidad como definir urls específicas.

@Configuration
public class FilterConfig {

    @Bean
    public FilterRegistrationBean<CustomFilter> loggingFilter() {
        FilterRegistrationBean<CustomFilter> registrationBean = new FilterRegistrationBean<>();

        registrationBean.setFilter(new CustomFilter());
        registrationBean.addUrlPatterns("/api/*"); // URL donde se aplicará el filtro

        return registrationBean;
    }
}

OncePerRequestFilter

Hasta ahora, hemos visto cómo operan los filtros de Spring. Cuando ocurre una solicitud, esta pasa por una cadena de filtros hasta el DispatcherServlet. Si hay múltiples servlets, tener copias separadas del filtro para cada servlet puede llevar a ejecuciones redundantes de filtros. Para resolver esto, Spring ofrece una clase específica llamada OncePerRequestFilter. Esto previene posibles operaciones redundantes.

Orden de Ejecución de Filtros

En aplicaciones con múltiples filtros, el orden de ejecución puede ser importante. Puedes establecer el orden de los filtros:

• Usando el método setOrder(int order) en el FilterRegistrationBean si lo registras manualmente. Los filtros con un valor de orden más bajo se ejecutarán antes.

• Utilizando la anotación @Order(1), @Order(2)…

Multihilo

Es importante notar que, en un entorno multihilo, cada thread podría obtener una nueva instancia. Para asegurarse de que la operación sea thread safe, se deberá utilizar «syncronized».

Ejemplo de Singleton en Java

En general, hay 3 condiciones:

Se puede inicializar de dos maneras, Lazy o Eager.

• Hacer privado el constructor
• Asegurarse de que la variable con la instancia sea static
• Proveer un método public static

A continuación un ejemplo de cada una.

Singleton con Lazy Initialization

En este caso, la instancia de la clase Singleton se crea solo cuando es requerida, es decir, cuando se llama al método getInstance() por primera vez. Esto puede ser útil si la creación de la instancia es costosa en términos de recursos o tiempo.

public class SingletonLazy {

    // Instancia única de la clase, inicialmente nula
    private static SingletonLazy instancia;

    // Constructor privado para evitar instanciación desde fuera
    private SingletonLazy() {
        // Inicialización de recursos si es necesario
    }

    // Método público para obtener la instancia única de la clase
    public static SingletonLazy getInstance() {
        if (instancia == null) {
            instancia = new SingletonLazy();
        }
        return instancia;
    }

    // Método de ejemplo en la clase Singleton
    public void mostrarMensaje() {
        System.out.println("Hola desde Singleton con Lazy Initialization!");
    }
}

Uso del Singleton con Lazy Initialization:

public class Main {
    public static void main(String[] args) {
        SingletonLazy singleton = SingletonLazy.getInstance();
        singleton.mostrarMensaje();
    }
}

En este ejemplo, la instancia de SingletonLazy solo se crea cuando se llama al método getInstance() por primera vez. Si el método nunca es llamado, la instancia nunca se crea.

Singleton con Eager Initialization

En el caso de Eager Initialization, la instancia de la clase Singleton se crea en el momento en que se carga la clase. Esto asegura que la instancia esté disponible inmediatamente, pero también significa que se creará incluso si nunca se utiliza, lo que puede ser un desperdicio de recursos en algunos casos.

public class SingletonEager {

    // Instancia única de la clase, creada al cargar la clase
    private static final SingletonEager instancia = new SingletonEager();

    // Constructor privado para evitar instanciación desde fuera
    private SingletonEager() {
        // Inicialización de recursos si es necesario
    }

    // Método público para obtener la instancia única de la clase
    public static SingletonEager getInstance() {
        return instancia;
    }

    // Método de ejemplo en la clase Singleton
    public void mostrarMensaje() {
        System.out.println("Hola desde Singleton con Eager Initialization!");
    }
}

Uso del Singleton con Eager Initialization:

public class Main {
    public static void main(String[] args) {
        SingletonEager singleton = SingletonEager.getInstance();
        singleton.mostrarMensaje();
    }
}

En este ejemplo, la instancia de SingletonEager se crea en el momento en que la clase es cargada por el JVM, incluso si nunca se utiliza. Esto asegura que la instancia esté disponible inmediatamente, pero podría ser ineficiente si la instancia nunca es necesaria.

Conclusión

• Lazy Initialization: La instancia se crea solo cuando es necesario, lo que puede ahorrar recursos si la instancia no siempre se usa.
• Eager Initialization: La instancia se crea tan pronto como se carga la clase, lo que asegura que esté disponible de inmediato, pero puede ser menos eficiente si la instancia no es utilizada.

Ejemplo de Singleton en Spring Boot

En Spring Boot, el patrón Singleton es implementado por defecto en los beans de Spring, ya que los beans son Singleton por defecto. Aquí tienes un ejemplo simple:

import org.springframework.stereotype.Service;

@Service
public class SingletonService {

    // Método de ejemplo en el bean Singleton
    public void mostrarMensaje() {
        System.out.println("Hola desde Singleton en Spring Boot!");
    }
}

Uso del Singleton en Spring Boot:

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.CommandLineRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class DemoApplication implements CommandLineRunner {

    @Autowired
    private SingletonService singletonService;

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }

    @Override
    public void run(String... args) throws Exception {
        singletonService.mostrarMensaje();
    }
}

En este ejemplo:

• La clase SingletonService es un bean administrado por Spring.
• La anotación @Service indica que esta clase es un servicio de Spring, y Spring la manejará como un Singleton.
• En la clase principal DemoApplication, el SingletonService se inyecta utilizando @Autowired, asegurando que la misma instancia se utiliza en todo el ciclo de vida de la aplicación.

Conclusión

El patrón Singleton es ampliamente utilizado cuando se necesita garantizar que una clase tenga una única instancia en toda la aplicación. En Java puro, se implementa de forma explícita, mientras que en Spring Boot, los beans ya son Singleton por defecto, lo que simplifica su uso y gestión.

S – Principio de Responsabilidad Única (Single Responsibility Principle)

Definición: Una clase debe tener una única razón para cambiar, es decir, solo una responsabilidad.
Ejemplo:

   class ReportGenerator {
       public void generateReport() {
           // Genera el reporte
       }
   }

   class ReportSaver {
       public void saveReport(String report) {
           // Guarda el reporte en un archivo
       }
   }

Aquí, ReportGenerator solo se encarga de generar el reporte y ReportSaver de guardarlo, siguiendo el principio de responsabilidad única.

O – Principio de Abierto/Cerrado (Open/Closed Principle)

Definición: El código debe estar abierto a la extensión, pero cerrado a la modificación.
Ejemplo:

   abstract class Shape {
       abstract double area();
   }

   class Circle extends Shape {
       private double radius;

       public Circle(double radius) {
           this.radius = radius;
       }

       @Override
       double area() {
           return Math.PI * radius * radius;
       }
   }

   class Rectangle extends Shape {
       private double width;
       private double height;

       public Rectangle(double width, double height) {
           this.width = width;
           this.height = height;
       }

       @Override
       double area() {
           return width * height;
       }
   }

Aquí, se pueden añadir nuevas formas extendiendo Shape, sin necesidad de modificar la clase base.

L – Principio de Sustitución de Liskov (Liskov Substitution Principle)

Definición: Los objetos de una clase derivada deben poder reemplazar objetos de la clase base sin alterar el comportamiento del programa.
Ejemplo:

   class Bird {
       public void fly() {
           // Acción de volar
       }
   }

   class Sparrow extends Bird {
       @Override
       public void fly() {
           System.out.println("Sparrow is flying");
       }
   }

   class Ostrich extends Bird {
       @Override
       public void fly() {
           throw new UnsupportedOperationException("Ostriches can't fly");
       }
   }

Aquí, Ostrich no debería heredar de Bird si no puede volar. En su lugar, podríamos tener una jerarquía separada para aves no voladoras.

I – Principio de Segregación de Interfaces (Interface Segregation Principle)

Definición: Una clase no debe estar obligada a implementar interfaces que no usa.
Ejemplo:

   interface Printer {
       void print();
   }

   interface Scanner {
       void scan();
   }

   class MultiFunctionDevice implements Printer, Scanner {
       @Override
       public void print() {
           System.out.println("Printing...");
       }

       @Override
       public void scan() {
           System.out.println("Scanning...");
       }
   }

Aquí, MultiFunctionDevice implementa solo las interfaces que necesita, evitando métodos innecesarios.

D – Principio de Inversión de Dependencias (Dependency Inversion Principle)

Definición: Las clases deben depender de abstracciones, no de clases concretas.
Ejemplo:

   interface Database {
       void connect();
   }

   class MySQLDatabase implements Database {
       @Override
       public void connect() {
           System.out.println("Connecting to MySQL...");
       }
   }

   class DataHandler {
       private Database db;

       public DataHandler(Database db) {
           this.db = db;
       }

       public void handleData() {
           db.connect();
       }
   }

Aquí, DataHandler depende de la abstracción Database, permitiendo cambiar la implementación concreta (como MySQLDatabase) sin modificar DataHandler.

Estos principios son la base para escribir código que sea más fácil de entender, mantener y escalar. ¡Implementarlos hará tu trabajo como desarrollador mucho más eficiente!

¿Cómo Funciona el Patrón Builder?

El patrón Builder se estructura generalmente en cuatro componentes clave:

1. Producto (Product): El objeto complejo que se va a construir.
2. Builder: Una interfaz que define los métodos necesarios para construir las partes del Producto.
3. Concrete Builder: Implementa la interfaz Builder y construye la representación concreta del Producto.Imaginemos que estamos construyendo una pizza con diferentes configuraciones, como Pizza Margarita y Pizza Pepperoni. Aquí se muestra cómo implementar el patrón Builder en Java para este caso:
4. Director: Controla el proceso de construcción, orquestando el orden en que se invocan los métodos del Builder.

Ejemplo Práctico: Construcción de una Pizza

Imaginemos que estamos construyendo una pizza con diferentes configuraciones, como Pizza Margarita y Pizza Pepperoni. Aquí se muestra cómo implementar el patrón Builder en Java para este caso:

Ventajas del uso de @Builder en Lombok:
Código más limpio y legible: No es necesario implementar manualmente el constructor, métodos setters o getters. Lombok se encarga de generar todo eso.
Inmutabilidad: Los objetos creados con el patrón Builder suelen ser inmutables, lo que aumenta la seguridad y consistencia en la gestión de datos.
Fluidez en la creación de objetos: Permite la creación de objetos de manera fluida, estableciendo solo los valores necesarios.

Explicación del Ejemplo

En este ejemplo, hemos construido una Pizza utilizando el patrón Builder.

• Producto: La clase Pizza representa el objeto complejo que queremos construir.
• Builder: La interfaz PizzaBuilder define los pasos necesarios para construir una pizza, como setMasa, setSalsa y setIngredientes.
• Concrete Builder: La clase PizzaMargaritaBuilder implementa la interfaz PizzaBuilder y construye una pizza específica, en este caso, una Pizza Margarita.
• Director: La clase PizzaDirector controla el proceso de construcción. En el método makeMargarita, se define cómo se construye una Pizza Margarita paso a paso.

El patrón Builder es un patrón de diseño creacional que permite construir objetos complejos paso a paso, proporcionando una interfaz fluida y flexible para configurar las propiedades de un objeto antes de su construcción final. Esto es particularmente útil cuando un objeto tiene muchos parámetros opcionales o configuraciones complejas, evitando la creación de múltiples constructores o un código con parámetros largos.

Implementación del patrón Builder con Lombok

Lombok es una biblioteca para Java que reduce el código repetitivo mediante anotaciones. En el caso del patrón Builder, Lombok proporciona la anotación @Builder, la cual simplifica la implementación de este patrón al generar automáticamente el código necesario.

Ejemplo de uso del patrón Builder con Lombok

import lombok.Builder;
import lombok.ToString;

@Builder
@ToString
public class Persona {
    private String nombre;
    private int edad;
    private String direccion;
}

Creación de un objeto con el patrón Builder

public class Main {
    public static void main(String[] args) {
        Persona persona = Persona.builder()
                                .nombre("Juan")
                                .edad(30)
                                .direccion("Calle Falsa 123")
                                .build();
    }
}

Explicación

• La anotación @Builder genera un builder para la clase Persona, permitiendo construir objetos con una sintaxis fluida.
• La anotación @ToString genera automáticamente el método toString(), que facilita la impresión de los valores del objeto.

Beneficios del Patrón Builder

• Flexibilidad: Puedes crear diferentes versiones de un objeto complejo usando el mismo código de construcción.
• Claridad: La separación de la construcción y la representación permite que el código sea más claro y manejable.
• Control: El Director garantiza que el objeto se construya de manera coherente y en el orden correcto

Código disponible en Github