En este artículo vamos a construir una pequeña aplicación de gestión de tareas utilizando Arquitectura Hexagonal (Ports & Adapters) con Java y Spring Boot.

La idea es aislar completamente la lógica de negocio (nuestro dominio) del framework y detalles de infraestructura (como el acceso a base de datos o los controladores REST). Esto nos permite tener un dominio limpio, fácil de testear y muy adaptable.

En este ejemplo, se han separado los casos de uso tanto en la capa de 'infraestructure' (entrada - RestControllers) como en la capa de 'application'. Se utiliza un servicio específico para cada caso de uso: uno dedicado a la creación de tareas (createTask) y otro encargado de la obtención de todas las tareas (getAllTasks). Esta separación permite una mayor modularidad y separación de responsabilidad en cada componente, facilitando el mantenimiento, la escalabilidad y las pruebas unitarias. Al aislar cada caso de uso, evitamos mezclas innecesarias de lógica y conseguimos una arquitectura más alineada con los principios de diseño limpio y la responsabilidad única.

En este ejemplo utilizaremos una B.D. en memoria H2.

En este ejemplo no vamos a utilizar DDD (Domain Driven Design) para no complicar demasiado y centrarnos directamente en las ventajas que aporta la Arquitectura Hexagonal. El uso de DDD en la Arquitectura Hexagonal es opcional y se recomienda su uso cuando el dominio tiene bastante lógica. Cuando las entidades de dominio actúan casi en su totalidad como DTOs (Data Transfer Objects) y no tienen lógica, se suele obviar el uso de DDD y se dice que el proyecto tiene un Dominio Anémico.

Separación entre el modelo de dominio y el modelo de base de datos:

Se debe mantener separado el modelo de dominio (la clase 'Task' que representa la lógica del negocio) del modelo de persistencia ('TaskEntity', usado por JPA). Aunque puedan parecer similares, tienen responsabilidades distintas: el dominio expresa reglas y conceptos del negocio, mientras que la definición de la entidad de persistencia depende de como se guardan los datos físicamente en B.D. Esto se ve más claramente si se utilizase DDD ya que la entidad de dominio 'Task' tendría lógica y se diferenciaría cláramente de la entidad de persistencia que carecería de dicha lógica.

Esta separación evita que detalles técnicos (como anotaciones JPA, IDs autogenerados o relaciones) contaminen la lógica del negocio. También nos permite modificar la persistencia sin tocar el núcleo de la aplicación, e incluso cambiar de base de datos o usar almacenamiento alternativo sin afectar al dominio. Esto mejora mucho la cohesión, claridad y mantenibilidad del proyecto a largo plazo.

Separación de SpringBoot en la infraestructura:

En la siguiente ejemplo se ha estructurado el código para que todas las anotaciones y configuraciones específicas de Spring Boot (como @Component, @RestController, @Bean, etc.) estén contenidas exclusivamente en la capa de infraestructura. Esto no es casual: forma parte del principio de independencia del dominio que promueve la 'Arquitectura Hexagonal'.

Gracias a esta separación, las capas de dominio y aplicación no dependen de ningún framework ni librería externa, lo que las hace más testeables, reutilizables y desacopladas. Podríamos usar exactamente el mismo núcleo de negocio en una app de consola, escritorio, REST o eventos, simplemente conectando adaptadores distintos. El resultado es un sistema más flexible y sostenible a largo plazo.

Estructura de paquetes:

src/
└── main/
    └── java/
        └── net/atopecode/todo/
            ├── domain/
            │   ├── model/
            │   │   └── Task.java
            │   └── port/
            │       ├── TaskRepository.java
            │       ├── CreateTaskService.java
            │       └── ListTasksService.java
            ├── application/
            │   ├── create/
            │   │   └── CreateTaskServiceImpl.java
            │   └── list/
            │       └── ListTasksServiceImpl.java
            ├── infrastructure/
            │   ├── input/
            │   │   └── rest/
            │   │       ├── create/
            │   │       │   └── CreateTaskController.java
            │   │       └── list/
            │   │           └── ListTasksController.java
            │   └── output/
            │       └── persistence/
            │           ├── TaskEntity.java
            │           ├── JpaTaskRepositoryAdapter.java
            │           └── SpringDataTaskRepository.java
            └── MainApplication.java

pom.xml

<modelVersion>4.0.0</modelVersion>

<groupId>net.atopecode</groupId>
<artifactId>todo-hexagonal</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>

<properties>
    <java.version>17</java.version>
    <spring-boot.version>3.2.0</spring-boot.version>
</properties>

<dependencies>
    <!-- Spring Boot Starter Web -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

    <!-- Spring Boot Starter Data JPA -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jpa</artifactId>
    </dependency>

    <!-- H2 In-Memory Database -->
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
        <scope>runtime</scope>
    </dependency>

    <!-- Test -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </depend

application.properties

# Configuración de la base de datos H2 en memoria
spring.datasource.url=jdbc:h2:mem:todo-db;DB_CLOSE_DELAY=-1
spring.datasource.driverClassName=org.h2.Driver
spring.datasource.username=sa
spring.datasource.password=

# JPA / Hibernate
spring.jpa.database-platform=org.hibernate.dialect.H2Dialect
spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true

# Consola H2 habilitada (opcional para desarrollo)
spring.h2.console.enabled=true
spring.h2.console.path=/h2-console

1. Capa de Dominio:

package net.atopecode.todo.domain.model;

public class Task {
    private String id;
    private String description;
    private boolean completed;

    public Task(String id, String description, boolean completed) {
        this.id = id;
        this.description = description;
        this.completed = completed;
    }

    public String getId() { return id; }
    public String getDescription() { return description; }
    public boolean isCompleted() { return completed; }

    public void setCompleted(boolean completed) {
        this.completed = completed;
    }
}

package net.atopecode.todo.domain.port;

import net.atopecode.todo.domain.model.Task;
import java.util.List;

public interface TaskRepository {
    void save(Task task);
    List<Task> findAll();
}

package net.atopecode.todo.domain.port;

public interface CreateTaskService {
    void createTask(String description);
}

package net.atopecode.todo.domain.port;

import net.atopecode.todo.domain.model.Task;
import java.util.List;

public interface ListTasksService {
    List<Task> getAllTasks();
}

2. Capa de Aplicación:

package net.atopecode.todo.application.create;

import net.atopecode.todo.domain.model.Task;
import net.atopecode.todo.domain.port.CreateTaskService;
import net.atopecode.todo.domain.port.TaskRepository;

import java.util.UUID;

public class CreateTaskServiceImpl implements CreateTaskService {

    private final TaskRepository repository;

    public CreateTaskServiceImpl(TaskRepository repository) {
        this.repository = repository;
    }

    @Override
    public void createTask(String description) {
        Task task = new Task(UUID.randomUUID().toString(), description, false);
        repository.save(task);
    }
}

package net.atopecode.todo.application.list;

import net.atopecode.todo.domain.model.Task;
import net.atopecode.todo.domain.port.ListTasksService;
import net.atopecode.todo.domain.port.TaskRepository;

import java.util.List;

public class ListTasksServiceImpl implements ListTasksService {

    private final TaskRepository repository;

    public ListTasksServiceImpl(TaskRepository repository) {
        this.repository = repository;
    }

    @Override
    public List<Task> getAllTasks() {
        return repository.findAll();
    }
}

3. Capa de Infraestructura:

package net.atopecode.todo.infrastructure.input.rest.create;

import net.atopecode.todo.domain.port.CreateTaskService;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/tasks")
public class CreateTaskController {

    private final CreateTaskService createTaskService;

    public CreateTaskController(CreateTaskService createTaskService) {
        this.createTaskService = createTaskService;
    }

    @PostMapping
    public ResponseEntity<Void> create(@RequestBody CreateTaskDto dto) {
        createTaskService.createTask(dto.getDescription());
        return ResponseEntity.ok().build();
    }

    public static class CreateTaskDto {
        private String description;
        public String getDescription() { return description; }
        public void setDescription(String description) { this.description = description; }
    }
}

package net.atopecode.todo.infrastructure.input.rest.list;

import net.atopecode.todo.domain.model.Task;
import net.atopecode.todo.domain.port.ListTasksService;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

import java.util.List;
import java.util.stream.Collectors;

@RestController
@RequestMapping("/tasks")
public class ListTasksController {

    private final ListTasksService listTasksService;

    public ListTasksController(ListTasksService listTasksService) {
        this.listTasksService = listTasksService;
    }

    @GetMapping
    public ResponseEntity<List<TaskDto>> list() {
        List<Task> tasks = listTasksService.getAllTasks();
        List<TaskDto> dtos = tasks.stream()
                .map(task -> new TaskDto(task.getId(), task.getDescription(), task.isCompleted()))
                .collect(Collectors.toList());
        return ResponseEntity.ok(dtos);
    }

    public static class TaskDto {
        private String id;
        private String description;
        private boolean completed;

        public TaskDto(String id, String description, boolean completed) {
            this.id = id;
            this.description = description;
            this.completed = completed;
        }

        public String getId() { return id; }
        public String getDescription() { return description; }
        public boolean isCompleted() { return completed; }
    }
}

package net.atopecode.todo.infrastructure.output.persistence;

import jakarta.persistence.*;
import net.atopecode.todo.domain.model.Task;

@Entity
@Table(name = "tasks")
public class TaskEntity {

    @Id
    private String id;
    private String description;
    private boolean completed;

    public TaskEntity() {}

    public TaskEntity(Task task) {
        this.id = task.getId();
        this.description = task.getDescription();
        this.completed = task.isCompleted();
    }

    public Task toDomain() {
        return new Task(id, description, completed);
    }

    // Getters y setters
    public String getId() { return id; }
    public void setId(String id) { this.id = id; }

    public String getDescription() { return description; }
    public void setDescription(String description) { this.description = description; }

    public boolean isCompleted() { return completed; }
    public void setCompleted(boolean completed) { this.completed = completed; }
}

package net.atopecode.todo.infrastructure.output.persistence;

import org.springframework.data.jpa.repository.JpaRepository;

public interface SpringDataTaskRepository extends JpaRepository<TaskEntity, String> {
}

package net.atopecode.todo.infrastructure.output.persistence;

import net.atopecode.todo.domain.model.Task;
import net.atopecode.todo.domain.port.TaskRepository;
import org.springframework.stereotype.Component;

import java.util.List;

@Component
public class JpaTaskRepositoryAdapter implements TaskRepository {

    private final SpringDataTaskRepository repository;

    public JpaTaskRepositoryAdapter(SpringDataTaskRepository repository) {
        this.repository = repository;
    }

    @Override
    public void save(Task task) {
        repository.save(new TaskEntity(task));
    }

    @Override
    public List<Task> findAll() {
        return repository.findAll()
                .stream()
                .map(TaskEntity::toDomain)
                .toList();
    }
}

4. Main

package net.atopecode.todo;

import net.atopecode.todo.application.create.CreateTaskServiceImpl;
import net.atopecode.todo.application.list.ListTasksServiceImpl;
import net.atopecode.todo.domain.port.CreateTaskService;
import net.atopecode.todo.domain.port.ListTasksService;
import net.atopecode.todo.domain.port.TaskRepository;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;

@SpringBootApplication(scanBasePackages = "net.atopecode.todo")
public class MainApplication {

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

    @Bean
    public CreateTaskService createTaskService(TaskRepository taskRepository) {
        return new CreateTaskServiceImpl(taskRepository);
    }

    @Bean
    public ListTasksService listTasksService(TaskRepository taskRepository) {
        return new ListTasksServiceImpl(taskRepository);
    }
}

Conclusión

La Arquitectura Hexagonal sirve para organizar el código de forma limpia, mantenible y flexible. En este artículo hemos visto cómo separar el núcleo de negocio del resto de la infraestructura, permitiendo que nuestra lógica sea independiente de frameworks como SpringBoot o de detalles técnicos como la base de datos.

Esta forma de estructurar aplicaciones facilita la escalabilidad, el testing aislado y la evolución del sistema facilitando el refactoring y la posiblidad de añadir nuevas funcionalidades sin esfuerzo.
Aunque al principio pueda parecer que este enfoque añade complejidad, con el tiempo se convierte en un diseño más robusto, ideal para proyectos medianos y grandes.

Los controladores, repositorios o incluso Spring Boot son adaptadores, lo importante es que el 'dominio' (core) de tu aplicación sea simple, enfocado en el negocio y libre de acoplamientos innecesarios.

Artículos relacionados:

La Arquitectura Hexagonal, también conocida como Ports and Adapters, fue propuesta por Alistair Cockburn con el objetivo de crear aplicaciones independientes de frameworks, bases de datos, interfaces gráficas o cualquier elemento externo. Su principal motivación es aislar el dominio de las dependencias externas.

Componentes Clave

• Dominio (Core): Contiene la lógica de negocio pura. No depende de nada externo.
• Puertos (Ports): Interfaces que definen cómo se comunica el dominio con el exterior.
• Adaptadores (Adapters): Implementaciones concretas de los puertos, como controladores REST, repositorios, UIs, etc.

  [REST Controller]         [CLI]
           \                  /
          [Entrada (Input Port)]
                   |
               [Dominio]
                   |
          [Salida (Output Port)]
           /              \
[Base de Datos]       [API externa]

En algunas ocasiones también se le llama a los 'Input Port' como 'Puertos Primarios' y a los 'Output Port' como 'Puertos Secundarios'. Pero no son más que nombres distintos para el mismo concepto.

Capas:

• Domain: Contiene el corazón del negocio: entidades, lógica pura e interfaces (puertos) que definen qué necesita el dominio para funcionar. Esta capa no conoce ni depende de ninguna tecnología, ni sabe nada sobre controladores, frameworks o bases de datos.
• Application: Orquesta los casos de uso: coordina las operaciones del dominio usando las interfaces (puertos) que este expone. Esta capa depende del dominio, pero no sabe nada de la infraestructura (como REST, JPA o controladores).
• Infraestructure: Contiene los adaptadores concretos que implementan lo que el dominio necesita (como persistencia o entrada de datos). Aquí viven los controladores REST y los repositorios JPA. Esta capa sí depende de las anteriores, ya que necesita conocer los puertos del dominio para implementarlos, pero el flujo de dependencias no va al revés.

Esta separación garantiza un código modular, desacoplado, fácil de probar y de evolucionar sin romper el núcleo del negocio.

Como norma se establece que las capas superiores pueden utilizar clases de las capas inferiores pero no al revés, dando por hecho que la capas ordenadas de inferior a superior son 'domain', 'application' e 'infraestructure'.

• En la capa de 'domain' no se debe utilizar ninguna clase de las capas superiores 'application' e infraestructure'.
• En la capa de 'application' sí se puede utilizar clases de la inferior capa 'domain' pero no de la capa superior 'infraestructure'.
• En la capa de 'infraestructure' como es la capa superior, puede utilizar clases de las capas inferiores 'domain' y 'application'.

Ejemplo en Java - Gestión de Tareas:

Vamos a crear una aplicación simple que gestiona tareas (ToDo). Usaremos Java puro sin frameworks (como SpringBoot), para centrarnos en la estructura.

Simularemos la B.D. con un 'ArrayList' en memoria.

Tampoco vamos a utilizar DDD (Domain Driven Design) para no complicar el ejemplo y centrarnos directamente en las ventajas que aporta la Arquitectura Hexagonal. El uso de DDD en la Arquitectura Hexagonal es opcional y se recomienda su uso cuando el dominio tiene bastante lógica. Cuando las entidades de dominio actúan casi en su totalidad como DTOs (Data Transfer Objects) y no tienen lógica, se suele obviar el uso de DDD y se dice que el proyecto tiene un Dominio Anémico.

Estructura de paquetes:

src/
└── main/
    └── java/
        └── net/atopecode/todo/
            ├── domain/
            │   ├── model/
            │   └── port/
            ├── application/
            ├── infrastructure/
            │   ├── input/
            │   └── output/
            └── MainApplication.java

1. Capa de Dominio:

package net.atopecode.todo.domain.model;

public class Task {
    private String id;
    private String description;
    private boolean completed;

    public Task(String id, String description, boolean completed) {
        this.id = id;
        this.description = description;
        this.completed = completed;
    }

    // Getters y setters
    public String getId() { return id; }
    public String getDescription() { return description; }
    public boolean isCompleted() { return completed; }

    public void setCompleted(boolean completed) {
        this.completed = completed;
    }
}

package net.atopecode.todo.domain.port;

import net.atopecode.todo.domain.model.Task;
import java.util.List;

public interface TaskRepository {
    void save(Task task);
    List<Task> findAll();
}

2. Capa de Aplicación:

package net.atopecode.todo.application;

import net.atopecode.todo.domain.model.Task;
import java.util.List;

public interface TaskService {
    void createTask(String description);
    List<Task> getAllTasks();
}

package net.atopecode.todo.application;

import net.atopecode.todo.domain.model.Task;
import net.atopecode.todo.domain.port.TaskRepository;

import java.util.List;
import java.util.UUID;

public class TaskServiceImpl implements TaskService {

    private final TaskRepository repository;

    public TaskServiceImpl(TaskRepository repository) {
        this.repository = repository;
    }

    @Override
    public void createTask(String description) {
        Task task = new Task(UUID.randomUUID().toString(), description, false);
        repository.save(task);
    }

    @Override
    public List<Task> getAllTasks() {
        return repository.findAll();
    }
}

3. Capa de Infraestructura:

package net.atopecode.todo.infrastructure.output;

import net.atopecode.todo.domain.model.Task;
import net.atopecode.todo.domain.port.TaskRepository;

import java.util.ArrayList;
import java.util.List;

public class InMemoryTaskRepository implements TaskRepository {

    private final List<Task> tasks = new ArrayList<>();

    @Override
    public void save(Task task) {
        tasks.add(task);
    }

    @Override
    public List<Task> findAll() {
        return new ArrayList<>(tasks);
    }
}

package net.atopecode.todo.infrastructure.input;

import net.atopecode.todo.application.TaskService;
import net.atopecode.todo.domain.model.Task;

public class ConsoleAdapter {

    private final TaskService taskService;

    public ConsoleAdapter(TaskService taskService) {
        this.taskService = taskService;
    }

    public void run() {
        taskService.createTask("Aprender Arquitectura Hexagonal");
        taskService.createTask("Publicar en atopecode.net");

        for (Task task : taskService.getAllTasks()) {
            System.out.println("- " + task.getDescription());
        }
    }
}

4. Main:

package net.atopecode.todo;

import net.atopecode.todo.application.TaskService;
import net.atopecode.todo.application.TaskServiceImpl;
import net.atopecode.todo.domain.port.TaskRepository;
import net.atopecode.todo.infrastructure.input.ConsoleAdapter;
import net.atopecode.todo.infrastructure.output.InMemoryTaskRepository;

public class Main {
    public static void main(String[] args) {
        TaskRepository repository = new InMemoryTaskRepository();
        TaskService taskService = new TaskServiceImpl(repository);
        ConsoleAdapter console = new ConsoleAdapter(taskService);

        console.run();
    }
}

Conclusión

Este ejemplo muestra cómo aplicar Arquitectura Hexagonal en un proyecto Java sin frameworks, organizando las clases en:

• El dominio es independiente del resto. Contiene la lógica de negocio y las interfaces.
• Las interfaces definen contratos, no implementaciones. Orquesta los casos de uso del negocio.
• Las implementaciones concretas (adaptadores) se pueden cambiar sin tocar la lógica de negocio. Se comunica con el exterior (UI, persistencia, etc.).

Lo interesante es que puedes cambiar los adaptadores (por ejemplo, una consola por una API REST) sin modificar la lógica de negocio.

Artículos relacionados:

En el mundo del desarrollo de software, uno de los principios clave para crear aplicaciones robustas, mantenibles y escalables es la cohesión. La cohesión mide cuán estrechamente están relacionados los elementos dentro de una clase o módulo. La alta cohesión es un objetivo esencial en el diseño de clases y módulos en lenguajes de programación orientados a objetos como Java.

¿Qué es la Alta Cohesión?

En términos simples, alta cohesión significa que las responsabilidades de una clase o módulo están bien definidas y están estrechamente relacionadas entre sí. Una clase con alta cohesión tiene un propósito claro y está encargada de un conjunto limitado de tareas que están directamente relacionadas.

Por el contrario, una clase con baja cohesión tiene responsabilidades dispersas, lo que la hace difícil de entender, mantener y extender. Las clases altamente cohesionadas, en cambio, son más fáciles de comprender, probar y modificar, ya que sus métodos y atributos están fuertemente relacionados con un solo propósito.

Características de la Alta Cohesión:

1. Responsabilidad única: La clase tiene una única razón para cambiar.
2. Relación entre métodos y atributos: Los métodos y atributos de la clase están relacionados con la misma funcionalidad.
3. Facilidad de mantenimiento: Las clases con alta cohesión son más fáciles de modificar sin afectar otras partes del sistema.
4. Mayor reutilización: Las clases cohesionadas pueden ser reutilizadas más fácilmente en diferentes contextos, ya que su funcionalidad está claramente definida.

¿Por qué es importante la Alta Cohesión?

Mantener alta cohesión dentro de las clases tiene varios beneficios clave:

• Mejora la legibilidad: Cuando una clase tiene un propósito claro y sus métodos son coherentes entre sí, es mucho más fácil de leer y entender.
• Facilita las pruebas unitarias: Las clases con alta cohesión son más fáciles de probar porque se centran en una sola responsabilidad, lo que simplifica la creación de pruebas.
• Simplifica el mantenimiento: Los cambios en una clase cohesionada son menos propensos a afectar otras partes del sistema.
• Fomenta el diseño modular: Al tener clases que se encargan de responsabilidades bien definidas, se facilita la modularización y la separación de preocupaciones, lo que mejora la escalabilidad del sistema.

Ejemplo de Baja Cohesión

Supongamos que tienes una clase que maneja tanto la persistencia de datos como la lógica de negocio. Esta clase estaría haciendo varias cosas no relacionadas, lo que resulta en una baja cohesión.

public class UsuarioManager {

    // Método para gestionar la lógica de negocio de los usuarios
    public void registrarUsuario(String nombre, String email) {
        // Lógica para registrar al usuario
        System.out.println("Usuario registrado: " + nombre);
    }

    // Método para persistir los datos en la base de datos
    public void guardarUsuarioEnBaseDeDatos(String nombre, String email) {
        // Lógica para guardar en base de datos
        System.out.println("Usuario guardado en la base de datos: " + nombre);
    }

    // Método para enviar un correo al usuario
    public void enviarCorreoDeBienvenida(String email) {
        // Lógica para enviar correo
        System.out.println("Correo de bienvenida enviado a: " + email);
    }
}

En este ejemplo, la clase UsuarioManager está manejando múltiples responsabilidades: lógica de negocio, persistencia y comunicaciones (correo). Esto genera una baja cohesión, ya que no está centrada en un solo propósito. Si decidimos cambiar la forma en que enviamos correos, afectaría a la clase entera, lo que hace que el mantenimiento sea más complicado.

Ejemplo de Alta Cohesión

Ahora, veamos cómo mejorar la cohesión dividiendo las responsabilidades en clases más pequeñas y específicas.

public class UsuarioRegistrador {
    public void registrarUsuario(String nombre, String email) {
        // Lógica para registrar al usuario
        System.out.println("Usuario registrado: " + nombre);
    }
}

public class UsuarioRepositorio {
    public void guardarUsuarioEnBaseDeDatos(String nombre, String email) {
        // Lógica para guardar en base de datos
        System.out.println("Usuario guardado en la base de datos: " + nombre);
    }
}

public class CorreoDeBienvenida {
    public void enviarCorreo(String email) {
        // Lógica para enviar correo
        System.out.println("Correo de bienvenida enviado a: " + email);
    }
}

En este ejemplo, hemos dividido las responsabilidades en tres clases:

1. UsuarioRegistrador: Se encarga exclusivamente de la lógica de negocio relacionada con el registro de usuarios.
2. UsuarioRepositorio: Se ocupa de la persistencia de los usuarios en la base de datos.
3. CorreoDeBienvenida: Se encarga de enviar los correos electrónicos de bienvenida.

Cada clase tiene una responsabilidad clara y bien definida, lo que hace que el código sea más fácil de mantener y extender. Si, por ejemplo, necesitamos cambiar la manera en que se envían los correos electrónicos, solo necesitaremos modificar la clase CorreoDeBienvenida sin tocar las otras clases.

Beneficios:

• Facilidad de mantenimiento: Cada clase tiene un propósito claro, lo que reduce la posibilidad de introducir errores cuando realizamos cambios.
• Mayor modularidad: Si queremos agregar nuevas funcionalidades, como un sistema de notificaciones, podemos hacerlo sin afectar el resto del código.
• Mejor testabilidad: Al estar bien separadas las responsabilidades, se facilita la escritura de pruebas unitarias.

Cómo Lograr Alta Cohesión en Java

Para lograr alta cohesión en Java, hay varias estrategias que puedes seguir:

1. Aplicar el principio de responsabilidad única (SRP): Cada clase debe tener una única razón para cambiar, lo que implica que debe centrarse en una sola tarea.
2. Refactorizar cuando sea necesario: Si una clase empieza a asumir demasiadas responsabilidades, es momento de refactorizarla en clases más pequeñas y especializadas.
3. Usar clases pequeñas y enfocadas: Asegúrate de que cada clase tenga un único propósito y que todos sus métodos estén relacionados con esa responsabilidad.
4. Composición sobre herencia: A menudo, es más eficiente componer objetos con responsabilidades bien definidas que intentar heredarlas de una clase base con múltiples responsabilidades.

Conclusión

En resumen, la alta cohesión es un principio esencial para crear software bien estructurado y fácil de mantener. Al seguir este principio, podemos crear clases en Java que sean claras, modulares y fáciles de probar, lo que a su vez facilita la evolución del sistema sin generar complicaciones innecesarias.

Recuerda, una clase con alta cohesión tiene un propósito claro, se enfoca en tareas específicas y reduce la probabilidad de errores al hacer cambios.

En el mundo del desarrollo de software, uno de los principios más importantes es el bajo acoplamiento. En este artículo, exploraremos cómo este concepto se aplica en Java, sus beneficios y las mejores prácticas para lograrlo. Un diseño con bajo acoplamiento no solo mejora la mantenibilidad del código, sino que también facilita la escalabilidad y la reutilización de componentes.

¿Qué es el Bajo Acoplamiento?

El bajo acoplamiento se refiere a la interdependencia mínima entre diferentes módulos o componentes de un sistema. En términos simples, significa que un cambio en un componente debería afectar lo menos posible a otros componentes. Este principio es fundamental en la programación orientada a objetos, donde se busca crear clases y objetos que sean lo más independientes posible.

Beneficios del Bajo Acoplamiento en Java

1. Facilidad de Mantenimiento: Un sistema con bajo acoplamiento es más fácil de modificar. Los desarrolladores pueden realizar cambios en una parte del código sin temor a romper otras partes.
2. Reutilización de Código: Las clases con bajo acoplamiento son más fácilmente reutilizables en otros proyectos. Esto ahorra tiempo y esfuerzo en el desarrollo.
3. Escalabilidad: A medida que los proyectos crecen, un diseño de bajo acoplamiento permite agregar nuevas funcionalidades sin complicar el sistema existente.
4. Pruebas Más Efectivas: Las unidades de código menos acopladas son más sencillas de probar de manera independiente, lo que mejora la calidad del software.

Estrategias para Lograr Bajo Acoplamiento en Java

1. Uso de Interfaces

Las interfaces en Java permiten definir contratos que las clases pueden implementar. Esto promueve el bajo acoplamiento, ya que las clases pueden interactuar a través de estas interfaces sin necesidad de conocer la implementación específica.

public interface Animal {
    void hacerSonido();
}

public class Perro implements Animal {
    @Override
    public void hacerSonido() {
        System.out.println("Guau");
    }
}

public class Gato implements Animal {
    @Override
    public void hacerSonido() {
        System.out.println("Miau");
    }
}

2. Inyección de Dependencias

La inyección de dependencias es una técnica que permite desacoplar clases al inyectar sus dependencias desde el exterior en lugar de crearlas internamente. A continuación, se muestra cómo se puede implementar utilizando la interfaz Animal:

public interface Animal {
    void hacerSonido();
}

public class Perro implements Animal {
    @Override
    public void hacerSonido() {
        System.out.println("Guau");
    }
}

public class Gato implements Animal {
    @Override
    public void hacerSonido() {
        System.out.println("Miau");
    }
}

public class ServicioAnimal {
    private Animal animal;

    public ServicioAnimal(Animal animal) {
        this.animal = animal;
    }

    public void hacerSonidoDelAnimal() {
        animal.hacerSonido();
    }
}

// Uso de la inyección de dependencias
public class Main {
    public static void main(String[] args) {
        Animal perro = new Perro();
        ServicioAnimal servicio = new ServicioAnimal(perro);
        servicio.hacerSonidoDelAnimal(); // Imprime: Guau

        Animal gato = new Gato();
        ServicioAnimal servicioGato = new ServicioAnimal(gato);
        servicioGato.hacerSonidoDelAnimal(); // Imprime: Miau
    }
}

3. Patrón de Diseño Observador

El patrón de diseño observador permite que un objeto notifique a otros objetos sobre cambios en su estado, reduciendo así la dependencia directa entre ellos.

public interface Observador {
    void actualizar();
}

public class Sujeto {
    private List observadores = new ArrayList<>();

    public void agregarObservador(Observador observador) {
        observadores.add(observador);
    }

    public void notificarObservadores() {
        for (Observador observador : observadores) {
            observador.actualizar();
        }
    }
}

Conclusión

El bajo acoplamiento es un principio esencial en la programación orientada a objetos, especialmente en Java. Al implementar estrategias como el uso de interfaces, la inyección de dependencias y patrones de diseño como el observador, los desarrolladores pueden crear aplicaciones más mantenibles, escalables y fáciles de probar. Adoptar estos enfoques no solo mejorará la calidad de tu código, sino que también optimizará el proceso de desarrollo a largo plazo.

En este artículo vamos a ver como levantar un servidor de B.D. MongoDB junto con otro servicio llamado 'Mongo-Express' que nos permitirá acceder a la B.D. mediante una UI desde el navegador web.

Después de haber visto varias opciones para utilizar algún cliente UI de MongoDB, me he encontrado con que la mayoría son de pago o he tenido problemas para instalarlos en Linux.

MongoExpress es de código abierto y cumple perfectamente con su cometido, por lo que es una opción a tener en cuenta cuando desarrollamos con MongoDB.

En el artículo anterior vimos como instalar 'docker-componse' en Linux.
Vamos a ver a continuación el contenido del archivo 'docker-compose.yml' que contrendrá el servicio de nuestra B.D. MongoDB y el cliente web MongoExpress.

docker-componse.yml:

Como puedes ver en el archivo .yml el user y password para nuestra B.D. MongoDB es 'root'/'example'. Los puedes cambiar por otros valores pero ten en cuenta que también hay que cambiarlos en la sección 'environment' del servicio 'mongo-express' para que se pueda conectar correctamente contra la B.D.

Además el servicio 'mongo' tiene 2 volúmenes definidos de tal forma que el contenido de la B.D. y su configuración se guardarán respectivamente en las carpetas './mongodb_data' y './mongodb_config' en el mismo path donde está nuestro archivo 'docker-compose.yml'.

Levantando nuestros servicios con docker-compose:

Dentro de la misma carpeta donde hemos copiado el archivo 'docker-compose.yml' ejecutamos el siguiente comando:
> docker-compose up -d

A continuación podemos ejecutar el siguiente comando para comprobar que ambos contenedores se están ejecutando correctamente:
> docker ps
> docker-compose ps

Cuando queramos detener ambos servicios y destruir sus contenedores podemos escribir (dentro de la misma carpeta del archivo docker-compose.yml):
> docker-compose down

Si por algún motivo nuestros contenedores no se han llegado a levantar y necesitamos consultar los logs para ver que ha sucedido podemos utilizar los comandos:
> docker logs mongo
> docker logs mongodb_mongo-express_1

Accediendo a nuestra B.D. desde MongoExpress:

Una vez que nuestros servicios están ejecutándose correctamente, vamos a acceder a nuestra B.D. por medio de 'MongoExpress'.
Para ello abrimos nuestro navegador favorito y accedemos a través de la url:
http://127.0.0.1:8081/
o
http://localhost:8081/

A gusto del consumidor :)

Desde 'MongoExpress' podemos crear, eliminar y consultar nuestras Bases de Datos.
Como ves en el ejemplo yo he añadido una nueva B.D. llamada 'SharingCoders'.

Haciendo click en la B.D. accedemos a la gestión de las Colecciones, donde podremos crear, eliminar y consultar el contenido de cada una de ellas.
Dentro de la B.D. 'SharingCoders' he añadido una nueva colección llamada 'Issue':

Haciendo click en cada Colección, podremos ver su contenido directamente desde la web o incluyo ejecutar querys para consultarlas más en detalle.

Conclusión:

En este artículo hemos visto como podemos ejecutar nuestro servidor de B.D. 'MongoDB' utilizando Docker/docker-compose y gestionarlo desde nuestro navegador por medio de 'MongoExpress'.

Espero que haya sido de utilidad ya que no es fácil encontrar un cliente UI para MongoDB en Linux que cumpla nuestras necesidades.

Un saludo.
A Tope Codear!!!

Enlaces de relacionados:

GitHub - mongo-express/mongo-express: Web-based MongoDB admin interface, written with Node.js and express

Web-based MongoDB admin interface, written with Node.js and express - GitHub - mongo-express/mongo-express: Web-based MongoDB admin interface, written with Node.js and express

GitHubmongo-express

¿Qué es MongoDB? - Datademia

Aprende análisis de datos, ciencia de datos e ingeniería de datos.

DatademiaDatademia

En el post anterior vimos como instalar Docker en linux.

En este artículo vamos a indicar los pasos para instalar 'docker-componse'.
Docker-compose es una herramienta que utiliza Docker y nos permite automatizar y manejar de forma simple la creación y ejecución de nuestros contenedores.

Nos ahorra tener que utilizar los comandos 'docker build ... ', 'docker run ...',
Podemos definir en único archivo .yml la configuración de cada contenedor (imagen, puertos, redes, volúmenes...) y con un solo comando se crearán y ejecutarán todos los contenedores con la configuración especificada.

Es realmente útil, sobre todo en el caso de que necesitemos levantar más de 1 contenedor a la vez en nuestra máquina. Por ejemplo, nuestra Api REST en SpringBoot y una B.D. PostgreSQL, en este caso necesitaríamos gestionar la creación de ambos contenedores con su correspondiente configuración y ejecutar los comandos docker necesarios de forma manual cada vez que que necesitemos crear/ejecutar cada contenedor.

Con docker-compose nos ahorramos todo este trabajo, definimos la construcción de cada contenedor en el archivo 'docker-compose.yml' una única vez y ejecutando en la misma carpeta el comando:
> docker-compose up

se crearán y levantarán los contenedores que hemos definido previamente en el archivo .yml.

Para detener (y destruir) los contenedores en ejecución, debemos escribir en la misma carpeta donde está nuestro archivo ''docker-compose-yml':
> docker-compose down

Así de fácil y sencillo.
Este no es un artículo para aprender a utilizar docker-compose, solo para ver como podemos instalarlo en Linux, así que vamos al lío:

Instalación en Linux (v1.29.2):

Ejecutar desde la terminal los siguientes comandos:

> sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

> sudo chmod +x /usr/local/bin/docker-compose

> sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

Para comprobar que se ha instalado correctamente:
> docker-compose
Se mostrará el siguiente mensaje:
Define and run multi-container applications with Docker.
A continuación se muestra la ayuda de como se debe utilizar el comando y todas las opciones disponibles.

Enlaces relacionados:

Si quieres instalar la última versión a día de hoy (v2.20.3):

Install Compose standalone

How to install Docker Compose - Other Scenarios

Docker Documentation

Para aprender un poco más sobre el uso de 'docker-compose':

Tutorial Docker Compose - Ander Fernández

En este post te explico, paso a paso, los principales componentes de Docker Compose, cómo funcionan y cómo usarlos.

Ander FernándezAnder Fernández Jauregui

Despliegue de aplicaciones con Docker-Compose - Adictos al trabajo

Vamos a aprender a desplegar nuestros proyectos en contenedores Docker de manera sencilla y rápida, utilizando docker-compose.

Adictos al trabajoNicolae Alexandru Molnar

A día de hoy si eres Desarrollador Backend, Docker es una herramienta casi imprescindible.

En este artículo vamos a explicar como se instalar Docker en Linux Ubuntu.

Se da por supuesto que ya sabes lo que es Docker y tienes conocimientos básicos de su funcionamiento (imágenes, dockerfile, contenedores...).

Instalación:

1: Primero vamos a actualizar la lista de paquetes de nuestro S.O.:

> sudo apt update

2: Instalamos paquetes necesarios para poder utilizar el comando 'apt' a través de una conexión Https:

> sudo apt install apt-transport-https ca-certificates curl software-properties-common

3: Añadimos la clave de GPG para el repositorio oficial de Docker en nuestro sistema:

> curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

4: Añadimos el repositorio de Docker a las fuentes de 'apt':

> sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"

5: Volvemos a actualizar la lista de paquetes de nuestro S.O. después de haber añadido el repositorio de Docker:

> sudo apt update

6: Este comando es opcional pero podemos ejecutarlo para asegurarnos que la versión candidata para instalar, es la del repositorio de Docker y no del repositorio predeterminado de Ubuntu.

> apt-cache policy docker-ce

Después de ejecutar el comando se muestra la versión de 'docker-ce' Candidate y se puede comprobar en la lista que la url para esa versión es la de: https://download.docker.com/linux/ubuntu.

7: Por fin podemos instalar Docker:

> sudo apt install docker-ce

8: Podemos comprobar que la instalación a finalizado correctamente y que el servicio (daemon) de Docker se está ejecutando en nuestro sistema con el comando:

> sudo systemctl status docker

Si todo ha salido correctamente, se indicará que el servicio 'docker.service' tiene estado 'Active: active'.

Configurar Docker para que se ejecute al arrancar el Sistema

Para hacer que el servicio de Docker se ejecute automáticamente cada vez que se inicia nuestro S.O. Linux, debemos utilizar los siguientes comandos:

> sudo systemctl enable docker.service
> sudo systemctl enable containerd.service

Si queremos deshacer los cambios anteriores y preferimos arrancar el servicio de Docker de forma manual, debemos utilizar:

> sudo systemctl disable docker.service
> sudo systemctl disable containerd.service

Y para arrancar el servicio de docker de forma manual:

> sudo systemctl start docker
> sudo systemctl status docker

Utilizar docker como SuperUsuario:

Por defecto, el comando docker solo puede ser ejecutado por el usuario root o un usuario del grupo docker, (que se crea automáticamente durante el proceso de instalación de Docker).
Si se intenta ejecutar docker sin el comando sudo o sin formar parte del grupo docker, se obtiene el siguiente error:

Output
docker: Cannot connect to the Docker daemon. Is the docker daemon running on this host?.
See 'docker run --help'.

Para evitar el uso de sudo cada vez que utilicemos el comando docker vamos a seguir los siguientes pasos:


1: Creamos el grupo 'docker', en teoría ya debería de estar creado después de la instalación de Docker, pero por si acaso, ejecutamos:

> sudo groupadd docker

2: Añadimos nuestro usuario al grupo docker:

> sudo usermod -aG docker $USER

O si estamos logueados con un usuario en concreto y queremos añadir otro usuario (username) al grupo docker:

> sudo usermod -aG docker username

3: Activamos los cambios realizados en el grupo docker:

> newgrp docker
> su - ${USER}

4: Para comprobar que podemos ejecutar el comando docker de forma correcta escribimos:

> docker run hello-world

Con este comando, docker se baja una imagen de test y crea un contenedor a partir de ella. Arranca el contenedor mostrando los correspondientes mensajes y a continuación se detiene.

Si depués de ejecutar el comando anterior aparece el siguiente mensaje:

WARNING: Error loading config file: /home/user/.docker/config.json -
stat /home/user/.docker/config.json: permission denied

Puede ser debido a que en algún momento se ejecutó el comando docker con sudo antes de añadir el usuario al grupo docker.
Para solucionarlo hay que modificar el propietario y los permisos de la carpeta '~/.docker/' para que nuestro usuario tenga acceso:

> sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
> sudo chmod g+rwx "$HOME/.docker" -R

Conclusión:

En este artículo hemos visto como instalar Docker en Linux Ubuntu y como configurar nuestro usuario para poder ejecutar el comando 'docker' sin tener que utilizar 'sudo'.

Espero que haya sido de utilidad y que disfrutes de las comodidades de Docker a partir de ahora.

A tope codear!!!

Enlaces relacionados:

Cómo instalar y usar Docker en Ubuntu 20.04 | DigitalOcean

Docker es una aplicación que simplifica el proceso de administración de procesos de aplicación en contenedores. Los contenedores le permiten ejecutar sus apl…

DigitalOceanBrian Hogan

Docker Engine post-installation steps

Optional post-installation steps for Linux

Docker Documentation

Llevo unos días con un pequeño proyecto al que he llamado PisthorIoc.
El nombre suena un poco a friki porque es la ombinación de las palabras Pistón + Thor + "Ioc".

Lo empecé como reto para hacer un Contenedor para Inyección de Dependencias y también porque empecé a trastear con el microframework Javalin y echaba de menos usar inyección de dependencias.

Existen varias librerías de contenedores para inyección de dependencias pero ninguna me convenció por lo engorroso que era utilizarlas. Me apetecía utilizar una librería que no hiciese uso de la reflexión, ya que va en contra de la filosofía de Javalin y otros microframeworks.

Por eso decidí intentar hacer uno por mi mismo.

Con PisthorIoc lo que he tratado de hacer es un contenedor sencillo de utilizar pero potente y que sea lo más completo y fiable posible.

El proyecto puedes encontrarlo en GitHub:
https://github.com/SilverioMG/PisthorIoc

Como lo implementé usando Java11 y haciendo uso de los módulos de java, decidí hacer otro proyecto a parte para los tests y así de paso comprobar también que la importación de módulos funciona correctamente:
https://github.com/SilverioMG/PisthorIoc_Test

Espero que sea de utilidad para alguien, sobre todo si estás usando algún microframework como Javalin o Spark.

Sino también puedes echarle un vistazo al código fuente y ver como se puede implementar un contendor de dependencias de manera sencilla :)

PisthorIoc - Contenedor de Dependencias sencillo y rápido

PisthorIoc es un Contenedor para Inyección de Dependencias para proyectos Java.

• Es simple de utilizar y ligero.
• No utiliza reflexión. No hay magia, solo código.
• ThreadSafe.
• Inyección de dependencias vía constructor.
• FluentApi.
• Permite registrar dependencias de tipo Singleton y Prototype.
• Es ideal para utilizar en microframeworks como Javalin o Spark.
• Cada dependencia se registra con un identificador único de tipo 'String' que será el mismo que se utilice a la hora de resolver/inyectar cada dependencia.
• Detecta errores comunes como intentar utilizar dependencias no registradas, registro de dependencias cíclicas, error en conversión de tipos al inyectar dependencias, aviso al sobreescribir el registro de alguna dependencia...
• Permite resolver las dependencias a medida que se van necesitando en la ejecución de nuestro código (lazy load) o realizar una carga completa cuando inicia nuestro proyecto de todas las dependencias registradas (recomendado).
• A la hora de hacer tests se puede sobreescribir directamente el registro de cualquier dependencia (servicio, repositorio...) para sustituirla por un mock o la correspondiente implementación de pruebas.

final String REPOSITORY = "repository";
final String SERVICE1 = "service1";
final String SERVICE2 = "service2";
final String CONTROLLER = "controller";

Logger logger = LoggerFactory.getLogger(IocContainer.class);
IocContainer iocContainer = IocContainerFactory.singleton()
	.setLogger(logger);
	
iocContainer
    .register(
        REPOSITORY,  
        (dr) -> new Repository())
    .register(
        SERVICE1,
        (dr) -> new Service1(dr.resolve(REPOSITORY , IRepository.class)))
    .register(
        SERVICE2,
        (dr) -> new Service2(dr.resolve(REPOSITORY , IRepository.class)))
    .register(
        CONTROLLER,
        (dr) -> new Controller(
            dr.resolve(SERVICE1, IService.class),
            dr.resolve(SERVICE2, IService.class)))
    .loadContent();
	
Controller controller = iocContainer.resolve(CONTROLLER, Controller.class);

Importar librería PisthorIoc en tu proyecto:

Compilar librería en local con Maven

Por el momento la librería PisthorIoc no está subida a ningún repositorio público como MavenCentral por lo que tendrás que compilar la librería e instalarla en su repositorio local.

Primero debes descargar la última versión del proyecto PisthorIoc.
A continuación, ejecuta el siguiente comando maven dentro del directorio raíz del proyecto:

mvn clean install

El proyecto se compilará y guardará el archivo .jar generado en tu directorio maven local .m2.

Añadir librería en tu proyecto

Si tu proyecto utiliza Maven:

<dependency>  
    <groupId>net.atopecode</groupId>  
    <artifactId>pisthorioc</artifactId>  
    <version>1.0.0</version>  
</dependency>

Si tu proyecto utiliza Gradle:

implementation "net.atopecode:pisthorioc:1.0.0"

Uso de Logger para mostrar mensajes

PisthorIoc permite utilizar logger (o no) según tus necesidades. En caso de no utilizar logger, la librería funciona igualmente pero no muestra advertencias ni mensajes de error (pero seguirá lanzando las correspondientes Exceptions en caso de error).

Es aconsejable utilizar siempre un logger para ver los mensajes y detectar posibles errores a medida que se registran y resuelven las dependencias.

PisthorIoc necesita un logger que implemente la interfaz slf4j.
En este ejemplo utilizaremos el logger logback para que nuestro contenedor de dependencias haga uso de él.
Añade las siguientes dependencias en tu proyecto:

Si tu proyecto utiliza Maven:

<dependency>  
    <groupId>ch.qos.logback</groupId>  
    <artifactId>logback-classic</artifactId>  
    <version>1.2.10</version>  
</dependency>  
<dependency>  
    <groupId>ch.qos.logback</groupId>  
    <artifactId>logback-core</artifactId>  
    <version>1.2.10</version>  
</dependency>

Si tu proyecto utiliza Gradle:

implementation "ch.qos.logback:logback-classic:1.2.10"
implementation "ch.qos.logback:logback-core:1.2.10"

Importar módulo Java de la librería PisthorIoc en tu proyecto

La librería PisthorIoc está implementada utilizando módulos de Java.
Si tu proyecto utiliza módulos de java debes añadir la siguiente línea en tu archivo module-info.java:

requires net.atopecode.pisthorioc.module;

Si tu proyecto no utiliza módulos de java no debes hacer nada especial para utilizar PisthorIoc, simplemente importa el paquete net.atopecode.pisthorioc.ioccontainer.* en tu código como harías normalmente.

Utilizando PisthorIoc en tu proyecto:

El uso del contendor de dependencias PisthorIoc se puede dividir en los siguientes pasos:

1. Crear contenedor de dependencias.
2. Registrar todas las dependencias necesarias.
3. Carga automática del contenedor con todas las dependencias registradas.
4. Uso del contenedor para resolver dependencias.

1. Crear contenedor de dependencias

Crear un contenedor como Singleton (el mismo objeto en memoria durante toda la ejecución del programa):

Logger logger = LoggerFactory.getLogger(IocContainer.class);
IocContainer container = IocContainerFactory.singleton()
    .setLogger(logger);

El método static 'IocContainerFactory.singleton()' siempre nos devolverá la misma instancia (mismo objeto) de nuestro contenedor de dependencias.
Por lo tanto, siempre podremos acceder a nuestro contenedor singleton desde cualquier parte de nuestro código utilizando el método static 'IocContainerFactory.singleton()' sin necesidad de guardar el objeto contenedor en un campo o ir pasándolo como parámetro de una parte del código a otra:

IocContainerFactory.singleton()
    .register(...);
	
IocContainerFactory.singleton()
    .resolve(...);

Crear un contenedor nuevo si es necesario (un nuevo objeto en memoria):

Logger logger = LoggerFactory.getLogger(IocContainer.class);
IocContainer container = IocContainerFactory.newInstance()
    .setLogger(logger);

El método static 'IocContainerFactory.newInstance()' siempre nos devolverá una nueva instancia (distinto objeto) de un contenedor de dependencias.

Usando un Logger:

En los ejemplos anteriores hemos creado siempre nuestro contenedor asignándole un logger.
Solo se permite asignar un logger a cada IocContainer una vez, es decir, si un IocContainer ya tiene un logger asignado y se intenta asignar de nuevo un logger, se produce una Exception.

Se puede comprobar si un contenedor tiene un logger ya asignado en cualquier momento:

IocContainer container = IocContainerFactory.singleton()
container.hasLogger(); //Devuelve 'false'.
container.setLogger(logger);
container.hasLogger(); //Devuelve 'true'.

//Se produce una 'Exception' porque ya se ha asignado previamente un logger al contenedor.
container.setLogger(logger); 

Sin usar Logger:

IocContainer container1 = IocContainerFactory.singleton();
IocContainer container2 = IocContainerFactory.newInstance();

Al no asignar logger al contenedor, su funcionamiento será el mismo, pero no se mostrarán mensajes de advertencia o de errores (pero se siguen lanzando las correspondientes Exceptions).

2. Registrar todas las dependencias necesarias

PisthorIoc utiliza inyección de dependencias vía constructor. Por lo que debe diseñar todos los objetos que vaya a utilizar como dependencias (controladores, servicios, repositorios...) para que sus constructores reciban las dependencias necesarias en cada momento.

Para nuestro ejemplo vamos a definir las siguientes clases (con sus correspondientes interfaces) que actuarán como dependencias dentro de nuestro contenedor y que se inyectarán unas en otras usando sus constructores:

public interface IRepository {
    public void methodRepository();
}

public interface IService {
    public void methodService();
}

public class Repository implements IRepository {
    public Repository(){
    }

    @Override
    public void methodRepository(){
    }
}

public class Service1 implements IService {
    private final IRepository repository;

    public Service1(IRepository repository){
        this.repository = repository;
    }
 
    @Override
    public void methodService(){
    }
}

public class Service2 implements IService {
    private final IRepository repository;

    public Service2(IRepository repository){
        this.repository = repository;
    }
 
    @Override
    public void methodService(){
    }
}

public class Controller {
    private final IService service1;
    private final IService service2;
	
    public Controller(IService service1, IService service2){
        this.service1 = service1;
        this.service2 = service2;
    }
    
    ...
}

Una vez definidas las clases para nuestras dependencias vamos a registrarlas dentro del contenedor de dependencias indicando como debe ser la construcción de cada una de ellas e inyectando las dependencias necesarias en cada caso.

Registrar una dependencia en PisthorIoc consiste en indicarle al contenedor como debe crearse un objeto y las dependencias que necesita para ello. Cuando se necesite resolver (recuperar) un objeto, el contenedor sabrá como debe crearlo inyectando las dependencias que necesita en su constructor.

final String REPOSITORY = "repository";
final String SERVICE1 = "service1";
final String SERVICE2 = "service2";
final String CONTROLLER = "controller";

IocContainerFactory.singleton()
    .register(  
        REPOSITORY ,  
        (dr) -> new Repository())
    .register(  
        SERVICE1,  
        (dr) -> new Service1(dr.resolve(REPOSITORY , IRepository.class)))
    .register(  
        SERVICE2,  
        (dr) -> new Service2(dr.resolve(REPOSITORY , IRepository.class)))
    .register(  
        CONTROLLER,  
        (dr) -> new Controller(
            dr.resolve(SERVICE1, IService.class),
            dr.resolve(SERVICE2, IService.class)));

3. Carga automática del contenedor con todas las dependencias registradas

Partiendo del apartado anterior, ahora mismo en nuestro contenedor están registradas todas las dependencias que necesitamos, pero aún no se ha creado ningún objeto. El contenedor simplemente tiene las instrucciones necesarias para crear los objetos y sus dependencias cuando sea necesario recuperarlas (resolverlas).

PisthorIoc utiliza un enfoque Lazy Load por defecto para resolver las dependencias.
Cada vez que se intente resolver (recuperar) una dependencia para utilizarla en nuestro código, en ese justo momento el contenedor intentará crear el objeto y todas sus dependencias necesarias.

Utilizando el enfoque Lazy Load, es posible que se produzcan errores a la hora de resolver alguna dependencia debido a que se ha registrado de forma incorrecta (no se ha registrado alguna dependencia necesaria para su construcción, registro de dependencias cíclicas...). Con lo cual puede que la inyección falle de forma no controlada sin saber justo el momento en el que se producirá el error debido a que nuestro programa ya lleva un tiempo ejecutándose.

Para evitar esto, es preferible realizar una carga automática de todas las dependencias justo al finalizar el registro.
Con la carga automática evitamos que se produzcan errores inesperados, ya que podemos controlar justo el momento en el que se pueden producir.
Lo normal es que el registro de las dependencias y la carga automática se hagan al inicio de nuestro programa o servicio.

Realizar carga automática después del registro de dependencias:

IocContainerFactory.singleton()
    .register(  
        "repository",  
        (dr) -> new Repository())
    .register(  
        "service1",  
        (dr) -> new Service1(dr.resolve("repository", IRepository.class)))
    .loadContent();

Añadimos el método loadContent() justo al finalizar el registro de las dependencias.

4. Uso del contenedor para resolver dependencias

Una vez que tenemos nuestras dependencias registradas en el punto 2, pasamos a resolver las dependencias para utilizarlas en nuestro proyecto (independientemente de si hemos decidido realizar la carga automática del punto 3 o no).

Obtenemos el objeto correspondiente a la dependencia registrada con el nombre "controller":

IocContainer container = IocContainerFactory.singleton();
Controller controller = container.resolve("controller", Controller.class);

La primera vez que se intenta resolver la dependencia, a su vez, se crean automáticamente el resto de dependencias necesarias para inyectarlas en su constructor y finalmente se devuelve el objeto de tipo 'Controller' con todas sus dependencias inyectadas.

Al estar registrado como Singleton, la próxima vez que se intente resolver la dependencia de tipo "controller", el contenedor devolverá siempre el mismo objeto en vez de crear uno nuevo.

A continuación resolvemos el objeto registrado como singleton con el nombre "service1":

IService service1 = container.resolve("service1", IService.class);

El contenedor nos devuelve el mismo objeto de tipo 'Service1' que se creó cuando resolvimos el objeto con nombre "controller", ya que hizo falta el 'Service1' para inyectarlo en el constructor de 'Controller' y nuestro contenedor tuvo que crear el objeto en ese momento.

Uso avanzado:

Las dependencias se pueden registrar como 'Singleton' (por defecto) o 'Prototype':

• Singleton: El objeto se crea una vez y siempre que se recupere su valor se devolverá la misma instancia (el mismo objeto).
• Prototype: Cada vez que se quiera recuperar un objeto, se crea una nueva instancia (nuevo objeto).

Sino se indica nada, por defecto todos los objetos se registran como dependencias de tipo Singleton.

Registrar un objeto como Singleton:

//Por defecto sino se indica nada, se registra el objeto como 'Singleton'.
container
    .register(  
        "repository",  
        (dr) -> new Repository());

//Indicando de forma explícita el registro como 'Singleton'.
container
    .register(  
        "repository",
        DependencyFactory.DependencyType.SINGLETON,
        (dr) -> new Repository());

Registrar un objeto como Prototype:

//Siempre hay que indicar forma explícita el registro como 'Prototype'.
container
    .register(  
        "repository",
        DependencyFactory.DependencyType.PROTOTYPE,
        (dr) -> new Repository());

No importa el orden de registro de nuestras dependencias:

A la hora de registrar las dependencias en nuestro contenedor no importa el orden en el que lo hagamos.
Lo único importante es que a la hora de resolver alguna dependencia, esta haya sido previamente registrada además de todas las demás dependencias que puedan ser necesarias para su construcción.

Por lo tanto podemos registrar las dependencias en cualquier orden:

final String REPOSITORY = "repository";
final String SERVICE1 = "service1";
final String SERVICE2 = "service2";
final String CONTROLLER = "controller";

IocContainerFactory.singleton()
    .register(  
        CONTROLLER,  
        (dr) -> new Controller(
            dr.resolve(SERVICE1, IService.class),
            dr.resolve(SERVICE2, IService.class)))
    .register(  
        SERVICE2,  
        (dr) -> new Service2(
            dr.resolve(REPOSITORY , IRepository.class)))
    .register(  
        SERVICE1,  
        (dr) -> new Service1(
            dr.resolve(REPOSITORY , IRepository.class)))
    .register(  
        REPOSITORY ,  
        (dr) -> new Repository())
    .loadContent();

Controller controller = IocContainerFactory.singleton()
    .resolve(CONTROLLER, Controller.class);

Mostrar las dependencias que guarda el contenedor:

La primera vez que se intenta resolver o inyectar una dependencia registrada como singleton, el contenedor crea su correspondiente objeto y lo almacena en su interior.
Para las dependencias registradas como prototype esto no sucede, ya que el contenedor crea un nuevo objeto cada vez que se intentan resolver o inyectar y por lo tanto no las almacena en su interior.

El método showContent() hace logging de todas las dependencias registradas como singleton que un contenedor tiene almacenadas. Es necesario que el contenedor tenga un logger asignado.

Logger logger = LoggerFactory.getLogger(IocContainer.class);
IocContainerFactory.singleton()
    .setLogger(logger)
    .showContent();

Sobreescribir el registro de una dependencia:

container
    .register(
        "repository",
        (dr) -> new Repository())
    .register(
        "repository",
        (dr) -> new RepositoryMock())
    .loadContent();
    
RepositoryMock repository = container.resolver("repository", IRepository.class);

Si registramos 2 o más veces el mismo objeto (utilizamos el mismo identificador de tipo string) como en el ejemplo anterior que hemos registrado 2 veces una dependencia con el mismo nombre "repository", no se produce ningún error, pero el contenedor muestra un mensaje de log como aviso (en caso de que hayamos utilizado un logger al crear el contenedor).
La dependencia con el nombre "repository" quedará registrada con el último registro realizado, sobreescribiendo los registros anteriores.

Para que el nuevo registro sobreescriba a sus antecesores y se aplique correctamente a la hora de resolver la dependencia, no se debe haber intentado resolver (recuperar) ninguna dependencia del contenedor ni haber realizado la carga automática antes del registro.
Ya que una vez que se crea el objeto de dicha dependencia, se guarda dentro del contenedor y este a su vez puede ser una dependencia de otro objeto. Y aún cuando la dependencia puede estar declarada como Prototype y no se guarde dentro del contenedor, siempre puede haber sido inyectada en otra dependencia de tipo Singleton que siempre guardará una versión del objeto prototype que no corresponderá con el nuevo registro.

Sobreescribir el registro de un objeto es realmente útil para realizar tests.
Podemos utilizar el mismo registro de dependencias de nuestro proyecto y en los tests sobreescribir solo aquellas dependencias que necesitamos mockear o sustituir su comportamiento.

Uso del contenedor para Testing (sobreescribiendo el registro de las dependencias):

Supongamos que en nuestro proyecto vamos a utilizar las siguientes clases y sus correspondientes interfaces:

public interface IEmailService {
    public void sendEmail();
}

public interface ICustomerService {
    public void sendEmailToCustomer();
}

public class EmailService implements IEmailService{
    @Override
    public void sendEmail(){
        //Código que envía un email de verdad.
        ...
    }
}

public class CustomerService implements ICustomerService{
    private final IEmailService emailService;
	
    public CustomerService(IEmailService emailService){
        this.emailService = emailService;
    }
	
    @Override
    public void sendEmailToCustomer(){
        emailService.sendEmail();
    }
}

public class EmailServiceMock implements IEmailService {
    @Override
    public void sendEmail(){
        //No hace nada.
        return;
    }
}

Utilizamos una clase 'IocContext' que inicialice nuestro contenedor y que se encargue de realizar el registro de todas las dependencias necesarias:

public class IocContext {
    public static void init(IocContainer iocContainer, boolean loadContent){
        Logger logger = LoggerFactory.getLogger(IocContainer.class);
        iocContainer
            .setLogger(logger)
            .register(
                "emailService",
                (dr) -> new EmailService())
            .register(
                "customerService",
                (dr) -> new CustomerService(dr.resolve("emailService", IEmailService.class)));
		
        if(loadContent) iocContainer.loadContent();
    }
}

Es importante remarcar que en la línea donde se registra 'customerService', a la hora de resolver 'emailService' para inyectarlo en su constructor, el objeto de tipo 'class' que se envía como parámetro es del tipo de la interfaz 'IEmailService',
no de la clase 'EmailService'. Se hace así porque a la hora de sobreescribir el registro de 'emailService' en nuestro test para utilizar 'EmailServiceMock', cuando el contenedor intente inyectarle a 'customerService' la dependencia de "emailService", esta será del tipo 'EmailServiceMock' y hará casting contra la interfaz 'IEmailService' por haber usado el parámetro correcto 'IEmailService.class' (si se usa como parámetro 'EmailService.class', se haría casting del objeto de tipo 'EmailServiceMock' contra el tipo 'EmailService' y fallaría).

Al inicio de nuestro proyecto (no en los tests) lo normal sería utilizar la clase 'IocContext' definida anteriormente para registrar todas las dependencias necesarias y también forzaremos la carga automática para comprobar que el registro es correcto.
En nuestro proyecto utilizaremos el contenedor de dependencias como Singleton, pero en los tests será mejor crear una nueva instancia del contenedor por cada ejecución.

//Al inicio de nuestro proyecto:
IocContext.init(IocContainerFactory.singleton(), true);

A la hora de hacer un test necesitamos cambiar el comportamiento de la dependencia "emailService".
En producción se utilizará 'EmailService' para enviar los emails necesarios, pero a la hora de ejecutar nuestros tests no queremos que envíe ningún email y utilizaremos 'EmailServiceMock' en su lugar.

Al inicio del test sustituiremos el registro de la dependencia para el servicio de email por nuestro mock, así a la hora de resolver el servicio de email, el contenedor devolverá siempre nuestro mock.

Es importante remarcar que para que la sobrescritura del registro funcione correctamente, en el test no se debe realizar la carga automática hasta que no se haya registrado nuestro servicio mock.
Además, por cada tests que hagamos, es conveniente utilizar una nueva instancia del contenedor y realizar de nuevo el registro.

@Test
public void emailServiceTest(){
    IocContainer iocContainer = IocContainerFactory.newInstance(); //Nueva instancia del contenedor (no singleton).
    IocContext.init(iocContainer, false); //No se realiza la carga automática.
	
    //Sobreescribimos el registro de "emailService" para utilizar 'EmailServiceMock'.
    iocContainer
        .register(
            "emailService",
            (dr) -> new EmailServiceMock());
		
    //Realizamos la carga automática después de sobreescribir el registro de dependencias.
    iocContainer.loadContent();

    ICustomerService customerService = iocContainer.resolve("customerService", ICustomerService.class);
    customerService.sendEmailToCustomer(); //No hace nada.
	
    IEmailService emailService = iocContainer.resolve("emailService", IEmailService.class);
    assertTrue(emailService instanceof EmailServiceMock);
}

Más ejemplos de uso de PisthorIoc

Para ver más ejemplos sobre el uso de PisthorIoc puede consultar los tests de la librería en el proyecto PisthorIoc_Test.

Para todas aquellas personas como en mi caso que tengan instalados en su pc Windows y Linux y ejecutando ambos mediante arranque dual, este artículo puede ser de gran interés.

Con WSL2 lo que se consigue es poder instalar una imagen Linux en Windows y ejecutarla mediante virtualización.

En mi caso prefiero Windows para programar y Linux para ejecutar y desplegar ya que al fin y al cabo cuando subo algún servicio a la nube suele ser en una máquina Linux (por precio, seguridad y rendimiento), pero antes siempre hago pruebas en local y me toca reiniciar el pc y arrancar en Linux.

Al utilizar WSL2 en realidad ya no hace falta tener instalado Linux en otra partición y utilizar el arranque dual.
Simplemente desde Windows se arranca la imagen de Linux y podremos utilizar la terminal para hacer todo lo que deseemos, ya que estaremos trabajando sobre un Linux de verdad.

Requisitos para instalar WSL2 en Windows:

1. Tu versión de Windows debe ser de 64 bits.

2. Debes de tener Windows actualizado. Hay que tener una versión igual o superior a la 1903.
   Para ver la versión de Windows actual presiona la tecla 'Windows + R' y teclea 'winver'.

3. Tu procesador debe soportar virtualización (en procesadores Intel VT-x y en Amd AMD-V). Además debe de estar habilitada dicha virtualización en la Bios.
   Lo normal es que si tu procesador tiene menos de 6 años ya tenga virtualización y esté activada en la Bios.

Para comprobar si el requisito nº 3 es correcto puedes pulsar las teclas CTRL + Mayúsculas + Esc y se abrirá el Administrador de Tareas de Windows.
En la pestaña Rendimiento seleccionando la CPU se puede ver si la opción Virtualization está activada:

Instalar WSL en Windows:

Para instalar WSL pulsa las teclar Windows + R y se abrirá la ventana de ejecutar. A continuación escribe OptionalFeatures.exe y se abrirá la ventana para instalar caracteríticas opcionales.

Selecciona las opciones Plataforma de máquina virtual (Virtual Machine Platform) y Subsistema de Windows para Linux (Windows Subsystem for Linux).

Después de la instalación habrá que reiniciar el sistema.

A continuación hay que actualizar el kernel de Linux en Windows.
Se puede descargar desde este enlace

Se instala como cualquier programa Windows, darle a siguiente y finalizar.

Después de haber instalado WSL, reiniciado y actualizado el Kernel de Linux es necesario seleccionar la versión de WSL que se ejecutará por defecto.
Esto es necesario porque cuando se instala WSL se instalan conjuntamente la versión 1 y la 2.

Para asegurarse que siempre se utilice la version WSL2 abre una terminal de PowerShell como administrador y teclea:

wsl --set-default-version 2

Instalar distribución de Linux:

Para instalar una imagen de Linux hay que ir a la WindowsStore y buscar por 'Linux'.
La más utilizada es Ubuntu, pero puedes instalar otras distros desde la WindowsStore. Ten en cuenta que algunas son de pago, aunque no es lo normal.
Te dejo los enlaces para acceder directamente a las distros de Ubuntu:

Ubuntu 18.04 LST

Ubuntu 20.04 LST

Utilizar la distribución de Linux con WSL2:

Una vez instalado WSL2 y la distribución de Linux solo falta arrancarla por medio del comando wsl.

Desde una terminal de Windows o PowerShell teclea lo siguiente:

• wsl -l
  Con este comando se listan todas las imágenes que tienes instaladas en su sistema para ejecutar con wsl.
  En mi caso aparecen varias imágenes porque tengo Docker instalado, pero la que nos intersa es la de Ubuntu-20.04.

• wsl -d <nombre de la distribución que se quiere arrancar>
  Con este comando se arranca la distribución deseada escribiendo su nombre completo.
  Lo que sucederá es que en la misma terminal de windows se nos abrirá una session en la distribución Linux arrancada.
  El usuario de Linux es el mismo que usamos en Windows y tiene privilegios de root utilizando el comando sudo.

Al igual que en Linux, podemos tener varias sesiones abiertas.
Si desde otra terminal de Windows volvemos a ejecutar el comando wsl -d, como la distro Linux ya está arrancada lo que sucede es que se abre otra sessión en una nueva consola.

• wsl -h
  Con este comando se muestran todos los demás parámetros que podemos utilizar con wsl.

Compartir archivos entre Windows y distro Linux WSL2:

Si te fijas en la imagen de arriba (después de ejecutar el comando 'wsl -d'), nada más arrancar la distribución de Ubuntu me indica que estoy en el path:
very@OPTIMUS:/mnt/c

Lo que quiere decir que en nuestro Linux se ha montado la partición C: de nuestro disco duro donde tenemos instalado Windows.

Si escribimos en nuestro terminal Linux el comando 'ls -laF' podremos comprobar que el contenido es el mismo que si escribimos desde la consola de Windows c:\>dir.

Por lo tanto, abriendo desde Windows el explorador de archivos y copiando cualquier archivo en la partición C: de nuestro disco duro podremos acceder desde Linux a su contenido y viceversa.

Como en cualquier Linux, el directorio /mnt es donde se montan dispositivos y particiones. Podemos navegar hasta la raíz del sistema con el comando 'cd /' y hasta nuestro home con 'cd ~'.

Comunicación por red entre Windows y distro Linux WSL2:

Por defecto la distro Linux instalada no tendrá el firewall activado.
He hecho pruebas activándolo y despúes de buscar más info en internet he llegado a la conclusión de que activar el firewall en nuestro nuevo Linux no es recomendable.
Al activar el firewall de Linux se pierde la conexión a internet desde nuestra distro.

Windows comparte la conexión de red con nuestra distro Linux.
Windows ya tiene un firewall configurado y al contenido de Linux solo accederemos desde nuestro Windows por lo tanto no es necesario activar ningún firewall y la conexión de red es la misma para ambos sistemas operativos.

Si en nuestro nuevo Linux instalamos un servidor Http como Apache (puerto 80) o un Servicio Web SpringBoot (puerto 8080) por ejemplo, desde Windows podremos acceder a ellos de la misma forma que si se estuviesen ejecutando en el propio Windows:

http://localhost:80/miWeb
http://127.0.0.1:8080/api

Conclusión:

En este artículo hemos visto como instalar una distribución Linux en Windows y ejecutarla por medio de WSL2 sin necesidad de tener que reiniciar el equipo para ejecutar Linux con arranque dual.

Es una manera mucho más cómoda de trabajar para todos los que programemos en Windows, ya que al fin y al cabo si te dedicas a programar Backend siempre vas a tener que trastear con Linux.

Enlaces de interés:

• ¿Qué es el Subsistema de Windows para Linux?
• 3 Fun Linux Tools to Run on Windows 10 With WSL
• Cómo instalar Java con apt en Ubuntu 18.04
• Interoperabilidad de Windows con Linux
• Campus MVP - Cómo instalar Linux en Windows y usar los dos sistemas a la vez: montando el subsistema de Linux (WSL2)

Esta es la 3ª parte de artículos sobre 'Optionals' en Java.
En las entradas anteriores Optionals en Java - Parte 1. Entendiendo su uso y Optionals en Java - Parte 2. Evitando validaciones 'null' de 'if' anidados se explica como se deben utilizar los Optionals (y como no) y una de sus mayores ventajas para evitarnos las comprobaciones de 'null' con 'if' anidados de toda la vida.

Este artículo es continuación del anterior y trata de explicar cuando hay que utilizar 'map()' y cuando 'flatMap()' con nuestros 'Optionals'.

Optional.map():

Con el método 'map()' debemos de envíar como parámetro una lambda de tipo 'Function' que a su vez devuelve un tipo de dato en concreto. Posteriormente y de forma automática, el método 'map()' envuelve nuestro tipo de dato devuelto dentro de un 'Optional' para poder seguir operando con él.

En el ejemplo anterior, para 'map()' estamos utilizando una lambda que devuelve el campo 'Person.email' que es de tipo 'String', por lo tanto, estamos devolviendo directamente un 'String'.
Pero después de ejecutar nuestra función lambda, 'map()' automáticamente crea un 'Optional<String>' envolviendo nuestro 'email'. Éste 'Optional' devuelto es el valor que se sigue utilizando el flujo.

Por lo tanto, la línea '.orElse(null);' lo que está recibiendo es un 'Optional<String>'.

Optional.flatMap():

El método 'flatMap()' también recibe como parámetro una función lambda de tipo 'Function', pero en este caso, desde nuestra lambda debemos devolver un 'Optional' directamente.
Es decir, a diferencia de como funciona 'map()', con 'flatMap()' el resultado devuelto no se envuelve automáticamente en un 'Optional'.
Debemos devolver nosotros un objeto de tipo 'Optional'.

Caso práctico utilizando 'map()' y 'flatMap()':

Para ver cuando hay que utilizar un método u otro en la práctica, vamos a utilizar los modelos de datos del artículo anterior pero añadiendo unos cuantos métodos getter.
Seguiremos utilizando el mismo repositorio.

En el artículo anterior sobre Optionals en Java hemos visto como y cuando se deben utilizar.

En este artículo veremos una de las mayores ventajas de los 'Optionals' a la hora de acceder a campos de objetos que pueden valer 'null' y evitarnos el tener que comprobar si cada referencia vale 'null' con 'if' anidados.

En otros lenguajes de programación como C# o TypeScript esto se puede hacer de forma sencilla ya que se hace uso del Null Conditional Operator.
Pero en Java, para obtener la misma funcionalidad, de momento tenemos que hacer uso de los 'Optionals'.

Entrando en contexto:

Normalmente en Java cuando queremos acceder al campo de un objeto hay que comprobar primero que dicho objeto no valga 'null'. La cosa se complica cuando queremos acceder a un campo que está dentro del campo de otro objeto y así sucesivamente:

Al final nuestro código se convierte en un montón de 'ifs' anidados cuando en C# por ejemplo, el mismo código sería de la siguiente manera:

Si alguno de los campos vale 'null' se asigna 'null' directamente a 'stateName' y no se siguen evaluando los demás.

Este resultado es el mismo que con el ejemplo de Java pero con mucho menos código y mucho más legible.

Vamos a ver ahora como se consigue esto en Java y de paso encontrándole un poco más de utilidad a los 'Optionals'.
Partiremos del mismo proyecto de tests que usamos en el artículo anterior con nuestros modelos de datos y el repositorio.
Puedes descargar el código fuente desde GitHub.

Empezamos a picar código:

Evitando 'Null Validations' anidadas:

Vamos a ver una serie de tests para recuperar el valor de un campo sin tener que utilizar 'if' anidados para comprobar valores 'null':

En este test primero se crea un objeto 'Person' cuyo campo 'Person.address' vale 'null'.
Para comprobar que se ha creado correctamente el objeto, se intenta acceder a dicho campo y como vale 'null' se lanza una 'NullPointerException'.

A continuación se crea un 'Optional' a partir de nuestro objeto 'Person'.
Se utiliza 'map()' para intentar acceder al campo 'Person.address.street' de forma segura sin tener que comprobar valores 'null'.
La función 'map()' acepta como parámetro una lambda de tipo 'Function' que devolverá un campo del objeto actual que a su vez se envuelve dentro de un 'Optional' para poder seguir evaluándolo.
Si el campo devuelto vale 'null', la función 'map()' devolverá un 'Optional.empty'.

La línea de código '.map(person -> person.getAddress())' lo que haría sería devolver un 'Optional<Address>' con el valor del campo 'person.getAddress()'. Pero como en nuestro caso 'person.getAddress()' vale 'null', la función 'map()' devuelve un 'Optional.empty'.

La siguiente línea '.map(address -> address.getStreet())' no se llega a ejecutar ya que se está ejecutando sobre un 'Optional.empty' y salta a la siguiente función sin lanzar NullPointerException.

En la última línea '.orElseGet(() -> null);' lo que hacemos es indicar el valor final que se devolverá en caso de recibir un 'Optional.empty'. En nuestro caso hemos indicado que se devuelva 'null' pero se prodría haber indicado otro valor o incluso llamar a un método que nos devuelva el valor necesario.

En este otro test se vuelve a intentar recuperar el campo 'Person.getAddress.getStreet()' pero ahora con éxito, ya que partimos de un objeto 'Person' con valor para su campo 'address'.

Primero se crea el objeto 'Person' y se comprueba que 'address' no vale 'null' recuperando el campo 'street'.

A continuación se crea un 'Optional' a partir de nuestro objeto 'Person'.
Volvemos a utilizar 'map()' para obtener el valor de cada campo de forma segura evitando 'NullPointerExceptions'.

En la línea '.map(Person::getAddress)' se devuelve un 'Optional<Address>' con el valor del campo 'Person.getAddress()'.
Fíjate como en este caso en vez de envíar como parámetro al método 'map()' una lambda, se está enviando directamente un 'method reference', pero el efecto es justamente el mismo que en el test anterior.

La línea '.map(Address::getStreet)' en este caso sí se ejecuta porque recibe un 'Optional<Address>' que no está vacío.
En la lambda se recibe el objeto de tipo 'Address' y se devuelve un 'Optional<String>' con el valor del campo 'Address.street' correspondiente.

La línea '.orElseGet(() -> null);' en este caso no llega a ejecutarse, porque no recibe un 'Optional.empty'.
Se devuelve directamente el valor del campo 'Person.getAddress.getStreet()'.

Vamos a ver otro par de tests añadiendo un campo más, ahora intentaremos obtener el valor de 'Person.getAdress().getState().getName()' cuando 'state' vale 'null' y cuando tiene valor.
La explicación de los tests es la misma, simplemente se añade un método adicional 'map()' al 'Optional':

Conclusión:

En este artículo se comprueba como se puede obtener el valor del campo 'Person.getAdress().getStreet()' y 'Person.getAdress().getState().getName()' sin utilizar comprobación de 'null' ni 'if' anidados.

Si lo comparamos con el Null Conditional Operator de C#, en Java con 'Optional' tenemos un mecanismo para que en caso de que algún campo intermedio valga 'null' poder devolver el valor que nosotros queramos.
En C# se devolvería directamente 'null' y para poder devolver otro valor habría que utilizar un operador a mayores.

Enlaces de interés:

• Código del artículo en GitHub
• Using the New Null Conditional Operator in C# 6
• Tired of Null Pointer Exceptions? Consider Using Java SE 8's "Optional"!

A partir de la versión de Java 8 podemos utilizar Optional<T> para evitar las indeseables NullPointerExceptions.

Los objetos de tipo Optional almacenan un campo que puede tener valor o no ('null'). Ofrecen una serie de métodos para comprobar si hay valor almacenado, poder recuperarlo o devolver un valor por defecto en caso de que el valor almacenado sea 'null'.

De primeras parece una gran utilidad, pero no todo es oro lo que reluce :)
¿Cuando hay que utilizar este tipo de objeto? ¿Ya no volveré a utilizar 'null' nunca más? ¿De verdad es útil utilizar Optional?
En este artículo intentaré explicar el uso para el que está pensado Optional y las buenas prácticas para utilizarlo.

Veremos que sí que compensa utilizar Optional en nuestro código pero siguiendo una serie de normas y teniendo en cuenta cual es su verdadero propósito.

Vamos al lío.

Cuando utilizar Optional:

Optional está pensado únicamente para utilizarlo como valor de retorno de nuestros métodos.
Sirve para indicar al programador que un método en cuestión puede devolver valor 'null' y al mismo tiempo se le ofrece un mecanismo para que pueda recuperar de forma segura dicho valor y utilizarlo sin que se produzca 'NullPointerException'*:

Entonces, teniendo en cuenta lo anterior, NO se deberá utilizar Optional en los siguientes casos:

1. Como tipo de dato para un campo de nuestras clases:

Desde la versión 8 de Java podemos utilizar cualquier clase que implemente la interfaz Collection como si fuese un Stream con las ventajas que nos ofrece la programación funcional y las Expresiones Lambda.

Una vez que te acostumbres a utilizar los streams ya no querrás volver a hacer bucles del tipo 'for(Class var1: listType){}'

A continuación voy a poner unos ejemplos de los usos más frecuentes con streams.
Puedes descargar el código fuente desde GitHub.

Preparándonos para picar código:

Vamos a crear una clase 'Book' que será nuestro model y un repositorio 'BookRepository' que devolverá una lista de Books para poder utilizar en nuestros tests. Así mostramos como funciona cada función por separado y con su correspondiente comprobación del resultado final.

Funciones del Stream:

Ahora veamos uno por uno cada test para explicar un poco como funciona cada función del stream utilizada.

'Collect()' se utiliza para indicar el tipo de collection en la que se devolverá el resultado final de todas las operaciones realizadas sobre el stream.
En este ejemplo no se realiza ninguna operación sobre el stream y simplemente se convierte el contenido a un List y a un Set.
En el caso del Set se comprueba como no se guardan los valores repetidos del 'stream' debido a la propia naturaleza del Set que impide guardar valores duplicados.

El método 'peek()' recibe como parámetro una lambda de tipo 'Consumer' para poder utilizar y/o modificar cada elemento del stream.
Normalmente se utiliza para mostrar por consola el contenido del stream en cada momento.

También se puede modificar el valor de algún campo del objeto 'Book' como en nuestro ejemplo pero no es muy aconsejable, ya que en la programación funcional se aconseja utilizar objetos inmutables.
No es una buena práctica cambiar el valor del objeto directamente.
En este caso en particular sería mejor utilizar el método 'map()' que veremos más adelante devolviendo una copia modificada de cada elemento de la lista.

El método 'map()' recibe como parámetro una lambda de tipo 'Function' por lo que debemos indicar una función que recibe como parámetro de entrada cada elemento del stream y devuelve un objeto que puede ser un tipo de dato distinto o del mismo.

Se utiliza para modificar el contenido del stream a partir de un punto determinado del flujo.

En nuestro ejemplo el 'stream' comienza con un flujo de objetos de tipo 'Book' y a partir del 'map()' se convierte en un flujo de tipo 'String' al devolver el título de cada libro.

Se utiliza 'peek()' para mostrar por consola los valores devueltos por 'map()' y finalmente se recolecta el resultado como una lista.

Con 'forEach()' recorremos cada elemento del stream para realizar alguna acción con él. Recibe como parámetro una lambda de tipo 'Consumer'.

Si nos fijamos bien 'forEach()' es un método que no devuelve ningún valor.
A diferencia del resto de funciones vistas, 'forEach()' es una operación de terminación, es decir, no se pueden seguir realizando operaciones encadenadas con el mismo stream.

En nuestro primer ejemplo recorremos el stream de libros para modificar su precio y mostramos por consola su nuevo valor.

En el segundo ejemplo primero obtenemos los títulos de los libros por medio de la función 'map()' y utilizamos 'forEach()' para comprobar el resultado del test.

Con 'filter()' como su nombre indica, lo que hacemos es filtrar de todos los elementos del stream solo aquellos que cumplan una determinada condición.
Recibe como parámetro una lambda de tipo 'Predicate' la cual debe devolver 'true' solo en aquellos elementos que seguirán en el stream y 'false' para aquellos que se deben eliminar.

En nuestro ejemplo usamos 'filter' para seleccionar de todos los libros solo aquellos cuyo precio cumpla la condición indicada.
También usamos 'peek()' a continuación para mostrar por consola los libros seleccionados.

La función 'findFirst()' se utiliza para devolver el primer elemento encontrado del 'stream'. Se suele utilizar en combinación con otras funciones cuando hay que seleccionar un único valor del Stream que cumpla determinadas condiciones.

'findFirst()' devuelve un objeto de tipo 'Optional' para poder indicar un valor por defecto en caso de que no se pueda devolver ningún elemento del 'stream'.

En el ejemplo se filtran los libros por su precio, a continuación se muestran por consola los libros filtrados y finalmente se selecciona el primero que cumpla la condición.
En caso de que ningún libro cumpliese la condición del 'filter()' indicamos que se devuelva como valor 'null'.

Este es un buen ejemplo para observar una característica propia del funcionamiento de los 'streams', que es la 'LazyEvaluation'.
Las funciones del 'stream' se van ejecutando una tras otra por cada elemento (libro) y luego se pasa al siguiente elemento sobre el cual se vuelven a ejecutar todas las fuciones y así sucesivamente por cada elemento del stream.

En nuestro ejemplo hay 2 libros que cumplen la condición del 'filter()', pero si lo ejecutamos observamos que en el 'peek()' solo se muestra por consola el primero de ellos.
Esto es debido a que en cuanto el primer libro que cumple la condición del 'filter()' llega al 'findFirst()' el stream se finaliza devolviendo dicho elemento, con lo cual sobre el siguiente libro ya no se llega a ejecutar el correspondiente 'filter()' ni el resto de funciones del 'stream'.

Con 'toArray()' podemos convertir cualquier tipo de 'Collection' en un 'array' de forma sencilla.

Las 2 primeras líneas del ejemplo sirven de recordatorio para ver como se puede convertir una lista en un 'array' sin utilizar 'streams'.

A continuación se muestra como convertir un 'stream' (obtenido a partir de cualquier 'Collection') en un 'array'.

Y por último se muestra como obtener un 'stream' partir de un 'array' y se utiliza para mostrar por consola sus valores.

'sorted()' se utiliza para ordenar los elementos del 'stream'.
Recibe como parámetro una lambda de tipo 'Comparator' para que podamos indicar la lógica de ordenación.

En nuestro ejemplo estamos ordenando los libros por su campo 'author' en orden ascendente sin tener en cuenta las mayúsculas y minúsculas.

Con 'min()' se obtiene el elemento del 'stream' con el valor mínimo calculado a partir de la lambda de tipo 'Comparator' que indiquemos como parámetro.

'min()' devuelve un objeto de tipo 'Optional' para poder indicar un valor por defecto en caso de que no se pueda devolver ningún elemento del 'stream'.

En el ejemplo se obtiene el libro con el menor precio.
Se indica en el objeto 'Optional' devuelto por 'min()' que en caso de no encontrar ningún elemento se devuelva 'null'.

Con 'max()' se obtiene el elemento del 'stream' con el valor máximo calculado a partir de la lambda de tipo 'Comparator' que indiquemos como parámetro.

'max()' devuelve un objeto de tipo 'Optional' para poder indicar un valor por defecto en caso de que no se pueda devolver ningún elemento del 'stream'.

En el ejemplo se obtiene el libro con el mayor precio.
Se indica en el objeto 'Optional' devuelto por 'max()' que en caso de no encontrar ningún elemento se devuelva 'null'.

Con 'distinct()' se seleccionan los elementos distintos dentro del 'stream' eliminando los duplicados.

En nuestro ejemplo primero añadimos un nuevo libro a la lista con un nombre repetido. A continuación convertimos la lista en un 'stream' y utilizamos 'map()' para obtener los títulos de los libros y a continuación con 'distinct()' se excluyen los valores duplicados.

Hay que tener en cuenta que si usase 'distinct' directamente sobre el objeto 'Book' del stream, habría que implementar su correspondiente método 'equals()' que es el que se utiliza para comparar la igualdad de los elementos entre sí.

Las funciones 'allMatch()', 'anyMatch()' y 'noneMatch()' devuelven un 'boolean' después de ejecutar la lambda de tipo 'Predicate' que reciben como parámetro sobre cada elemento del 'stream'.

• 'allMatch()': Devuelve true en caso de que la condición de la lambda se cumpla para todos los elementos del 'stream' y false en caso de que algún elemento no cumpla la condición.
  Se utiliza evaluación por cortocircuito, es decir, en cuanto la condición no se cumple para un elemento ya no se sigue comparando con el resto y 'allMatch()' devolverá false.

En nuestro ejemplo comprobamos que todos los elementos del 'stream' sean par (el resto de la división entre 2 debe dar O como resultado). Como existe un elemento que no es par, el resultado de 'allMatch()' es false.

• 'anyMatch()': Devuelve true en caso de que la condición de la lambda se cumpla para algún elemento del 'stream' y false si ningún elemento cumple la condición.
  También se utiliza evaluación por cortocircuito, es decir, en cuanto la condición se cumpla para un elemento ya no se sigue comparando con el resto y 'anyMatch' devolverá true.

En nuestro ejemplo comprobamos que algún elemento del 'stream' sea par. Como el primer elemento seleccionado ya es par, 'anyMatch()' devolverá true y no seguirá evaluando el resto de elementos.

• 'noneMatch()': Devuelve true en caso de que ningún elemento del 'stream' cumpla la condición de la lambda y false en caso de que algún elemento cumpla la condición.
  También se utiliza evaluación por cortocircuito, por lo que en cuanto se encuentre un elemento que cumpla la condición ya no se sigue comparando con el resto y 'noneMatch()' devolverá false.

En nuestro ejemplo comprobamos que ningún elemento del 'stream' sea múltiplo de 3, como sí que existe un elemento que cumple dicha condición, 'noneMatch()' devolverá false y no seguirá evuluando el resto de elementos.

Conclusión:
En este artículo hemos visto las funciones más comunes para utilizar con los streams de Java8 y versiones posteriores.

Existen más funciones y características que no se cubren en este artículo pero a continuación dejo un par de enlaces para seguir investigando sobre su uso.

Espero que este artículo te haya servido de utilidad y a partir de ahora empieces a utilizar los streams y las lambda para ser un ATopeCoder de verdad :)

Nos vemos.

Enlaces de interés:

• Código del artículo en GitHub
• A Guide to Java Streams in Java 8: In-Depth Tutorial With Examples
• Baeldung - Introduction to Java 8 Streams

El logging es una parte fundamental que necesitamos en nuestros Servicios Web.
Siempre vamos a tener que echar mano de ellos para consultar algún error inesperado o comprobar el comportamiento de nuestro servicio una vez desplegado.

SpringBoot por defecto utiliza una implementación de slf4j llamada LogBack
Si no configuramos nada, por defecto springboot solo muestra logs por consola y a partir del nivel 'INFO' y posteriores (no se mostrarán los niveles 'TRACE' ni 'DEBUG').

Siempre es bueno recordar los LogLevels ordenados de menor a mayor importacia:

• trace (the least serious)
• debug
• info
• warn
• error
• fatal (the most serious)

Configurando nuestro Logger:

Para configurar como se muestran los mensajes de Logging, con que formato y por donde deben imprimirse (consola y/o archivo) debemos de añadir un archivo con el nombre logback-spring.xml en la carpeta /resources de nuestro proyecto.
Un ejemplo de configuración puede ser esta:

Secciones del archivo logback-spring.xml:

property: Aquí se definen valores que se pueden repetir a lo largo del archivo .xml y en lugar de copiar/pegar dicho valor en todas las partes necesarias se utiliza una propiedad para hacer referencia a dicho valor. Así si el valor cambia solo tendremos que cambiarlo en dicha propiedad sin tener que ir buscando por todo el archivo la cadena correspondiente a modificar.

appender: Los appender sirven para declarar las 'salidas' de nuestros logs.
Se pueden configurar uno o más appenders para mostrar logs por consola o para que se escriban en un archivo. También se define el formato del mensaje y otra opciones como por ejemplo el truncado de nuestros archivos de logs cada cierto tiempo o al llegar a un tamaño en disco determinado.

root: En esta sección se configura el Logging por defecto de nuestra aplicación para cualquier paquete o clase.
Aquí es donde se utilizan los 'appenders' declarados previamente, para indicar cuales serán las salidas de nuestros logs por defecto.
En nuestro archivo .xml hemos definido que por defecto cualquier log que se haga debe salir solo por la consola.
Podríamos haber definido que se guardasen también en un archivo utilizando el appender 'RollingFile' o incluso declarar otro appender para guardarlos en otro archivo distinto y utilizar ambos para guardar los logs en 2 archivos distintos.
Se pueden utilizar tantos appenders como nos hagan falta según nuestras necesidades.
En la propiedad 'level' se indica el nivel de log a partir del cual se mostrarán los mensajes. En nuestro ejemplo solo se mostrarán los mensajes a partir del level 'info' y posteriores (no se mostrarán los logs con level 'trace' o 'debug').

logger: Esta sección sirve para configurar el Logging al igual que en la sección root pero solo para los Loggers que pertenezcan a un paquete y clase específicos.
En el parámetro 'name' se indica el paquete y/o clase correspondiente.
A continuación se indican los appenders que utilizarán los Loggers de dicho paquete y/o clase.
En nuestro arhivo .xml hemos definido que los mensajes de log de todas las clases que pertenezcan al paquete 'net.atopecode' (y descendientes) se escriban por consola y en archivo de disco.
En la propiedad 'level' se indica el nivel de log a partir del cual se mostrarán los mensajes. En nuestro ejemplo se muestran todos los niveles de logging ya que hemos indicado el level 'trace' y posteriores.

Utilizando el Logger desde nuestro código:

Para utilizar el Logger en nuestro código es necesario indicar a que clase pertenece. Dependiendo del paquete/clase a la que pertenece el Logger, a la hora de mostrar el mensaje se utilizará un appender u otro según lo que hayamos configurado en la sección 'logger' de nuestro archivo 'logback-spring.xml'

En este ejemplo se está creando el Logger para la clase 'PruebaLoggingComponent' que coincide que es la misma clase donde se va a utilizar el Logger. Normalmente la clase para la que se define el Logger es la misma en la que se va a utilizar pero no tiene porque ser así.
Lo que importa a la hora de declarar nuestro Logger con respecto a la configuración del archivo .xml es el parámetro '.class' que se para como parámetro en el método 'LoggerFactory.getLogger()'.

En este caso nuestro Logger utilizará la sección

    <logger name="net.atopecode" level="trace" additivity="false">
        <appender-ref ref="RollingFile" />
        <appender-ref ref="Console" />
    </logger>

de nuestro archivo 'logback-spring.xml' ya que la clase 'PruebaLoggingComponent' está dentro del paquete '.net.atopecode.*'.
Por lo tanto se escribirán los mensajes de log por consola y en archivo de disco al mismo tiempo.

Propiedad 'additivity':

Hay que tener en cuenta que la sección 'root' de nuestro archivo 'logback-spring.xml' también afecta a nuestro Logger, ya que hace referencia a cualquier Logger definido dentro del proyecto.

Para estos casos se utiliza la propiedad 'additivity' que por defecto vale 'true'. En nuestro caso al asignar additivity="false" estamos indicando que se utilice la sección 'logger' de nuestro archivo .xml que más se ajuste al 'paquete/clase' pero no todas las otras secciones que puedan hacer referencia a nuestro Logger.

Si no hubiésemos indicado additivity="false" en este caso, nuestros mensajes habrían salido por duplicado en la consola (una vez por la sección root y otra por la sección logger) y también se escribirían en un archivo (por la sección logger).

Para entender mejor esta parte pongamos como ejemplo otro archivo .xml igual al anterior, pero esta vez añadiremos otra sección 'logger' indicando el nombre de la clase (somos más restrictivos que solo indicando el paquete) para que se ajuste más a nuestro Logger declarado en el código Java.

Ahora nuestro Logger declarado en la clase Java "PruebaLoggingComponent" utilizará la nueva sección 'logger' de nuestro archivo .xml ya que es la que más se ajusta porque está indicando directamente el nombre de clase:

    <logger name="net.atopecode.authservice.component.PruebaLoggingComponent" level="debug" additivity="false">
        <appender-ref ref="Console" />
    </logger>

Nuestros mensajes saldrán ahora solo por consola y a partir del level debug.

Si no hubiésemeos puesto la propiedad additivity="false", además de nuestra nueva sección se estaría también utilizando la anterior a ella:

    <logger name="net.atopecode" level="trace" additivity="false">
        <appender-ref ref="RollingFile" />
        <appender-ref ref="Console" />
    </logger>

En cuyo caso se mostrarían los mensajes en archivo y por duplicado en la consola.
Es una buena práctica utilizar siempre additivity="false" para que solo una sección 'logger' de nuestro archivo xml afecte a los mensajes de nuestros Loggers.

Conclusión:

En este artículo hemos visto una forma básica de configurar los Logs en SpringBoot.
Existen muchas más opciones pero con esta configuración se puede empezar a trabajar en un proyecto guardando los logs en un archivo además de mostrarlos por consola y especificando a partir de que nivel queremos que se muestren.

Espero que este artículo haya sido de utilidad.
A Tope Codear!!!

Enlaces de interés:

• Logging in Spring Boot - Baeldung Blog
• A Guide To Logback - Baeldung Blog
• How can I configure Logback to log different levels for a logger to different destinations?
• Logging In Spring Boot - Reflectoring Blog
• Tracing in Distributed Systems with Spring Cloud Sleuth

Para proyectos SpringBoot se suele utilizar como IDE el Spring Tool Suite que es un Eclipse tuneado y que incorpora por defecto los plugins para desarrollar con SpringBoot. Aunque el STS está muy bien hay que reconocer que el IntelliJ es mucho mejor IDE.

El problema es que con la versión Community de IntelliJ (gratis) no se pueden instalar los plugins para SpringBoot y el desarrollo no es tan trivial.

Hay varias maneras para desarrollar un proyecto SpringBoot con el IntelliJIdea Community, en este artículo muestro varias opciones para hacerlo.

Creando el proyecto SpringBoot:

Desde la página de Spring Initializr creamos un proyecto SpringBoot seleccionado todas las librerías que vamos a utilizar. Lo descargamos y posteriormente lo abrimos en el IntelliJ.

Dependiendo de como hemos decidido crear el proyecto en la web de Spring Initializr se nos abrirá como un proyecto maven o gradle.

Ahora ya podemos empezar a picar código y desarrollar nuestro servicio web.

Arrancando el Servicio Web SpringBoot:

Para compilar y arrancar nuestro servicio hay varias opciones:

1.- La forma más rápida es desde la ventana 'Project' seleccionando el archivo que corresponde con la clase 'Application' de nuestro proyecto.
Haciendo click derecho y seleccionando 'Run' o pulsando Ctrl+Mayús+F10 se compilará nuestro código y se arrancará el servicio web.
Si lo que queremos es depurar, en vez de seleccionar la opción 'Run' deberemos seleccionar 'Debug'.

En la ventana 'Run' podemos ver los logs que indican que el servicio ha arrancado correctamente y desde esta misma ventana podemos finalizar su ejecución haciendo click en el botón con el símbolo de Stop

Si queremos volver a arrancar el servicio después de la primera vez, desde esta misma ventana de 'Run' se puede hacer click en el botón 'Rerun' sin tener que volver a seleccionar el archivo de nuestra clase 'Application'.

2.- La opción standard y que se debería de hacer en cada proyecto es añadiendo una Run/Debug Configuration como se muestra en el siguiente video:

3.- Otra opción es utilizando el plugin maven correspondiente desde la ventana de 'Maven'. Localizando el plugin 'spring-boot - spring-boot:run' y haciendo doble click se arranca nuestro servicio web.

Igual que el paso anterior se nos vuelve a abrir la ventana de 'Run' desde la cual se muestran los logs y podremos finalizar la ejecución del servicio (stop) o volver a ejecutarlo (rerun)

4.- La cuarta y última forma de arrancar nuestro servicio web es la más rudimentaria y menos ágil cuando estamos desarrollando.

Consiste en ejecutar desde la ventana de terminal y dentro del directorio raíz de nuestro proyecto el comando:

./mvnw spring-boot:run

Nuestro servicio web empezará a arrancarse y se mostraran los correspondientes logs en la ventana de 'Terminal'.
En este caso para finalizar el proceso hay que pulsar en dicha ventana las teclas 'Ctrl + C' y teclear 's' cuando se nos pregunte si queremos finalizar el proceso.
Para volver a ejecutar el servicio tendremos que volver a ejecutar el comando.

Conclusión:

Personalmente prefiero cualquiera de las 2 primeras opciones.
Es aconsejable utilizar siempre la misma opción para arrancar y detener el servicio web, ya que si cambiamos de una a otra podemos dejar el servicio en ejecución y al intentar volver a ejecutarlo nos dará error porque ya se está usando el mismo puerto.

Si ya se está acostumbrado a utilizar el Spring Tool Suite igual no es buena idea pasarse al IntelliJ Idea sin tener una licencia (cuestan sobre unos 500 euros al año).
Si ya se está utilizando el IntelliJ Idea Community y lo que quieres es hacer algo con SpringBoot entonces las opciones descritas en este artículo si que pueden serte útiles.

Nos vemos.
A tope codear!!!