Separation of concerns

El principio de Separación de preocupaciones (SoC, por sus siglas en inglés) es una guía de diseño de software que se enfoca en separar los aspectos diferentes de un sistema en diferentes componentes para que cada uno se ocupe de una tarea específica y no haya mezcla de responsabilidades.

La idea detrás de este principio es que un sistema puede ser más fácilmente mantenido, extendido y modificado si cada componente se enfoca en una única preocupación. Por ejemplo, en una aplicación web, podemos separar la presentación de la lógica de negocio y la persistencia de datos. Cada una de estas preocupaciones se puede tratar de manera independiente.

La separación de preocupaciones puede mejorar la modularidad del sistema, reducir la complejidad y hacer que el código sea más fácil de leer y entender. Además, también puede ayudar a evitar errores al hacer que el código sea más manejable y menos propenso a bugs.

Es importante tener en cuenta que aunque la separación de preocupaciones es una práctica recomendada, en algunos casos no siempre es posible o práctico aplicarla completamente. En cualquier caso, se debe buscar siempre que sea posible separar las diferentes preocupaciones del sistema para lograr un diseño más limpio y mantenible.

Ejemplo

El principio de Separation of Concerns (Separación de Preocupaciones) consiste en separar un programa en partes o módulos distintos, cada uno enfocado en una tarea o preocupación específica, para reducir la complejidad y mejorar la mantenibilidad.

Un ejemplo en Java podría ser la separación de las preocupaciones relacionadas con la capa de presentación y la capa de lógica de negocio. En lugar de mezclar ambas en una sola clase, se pueden crear dos clases diferentes, cada una enfocada en su tarea específica.

Por ejemplo, supongamos que estamos desarrollando una aplicación que maneja los productos de una tienda en línea. Podríamos tener una clase Product que representa un producto y contiene información como su nombre, precio, descripción, etc. Esta clase estaría enfocada en las preocupaciones relacionadas con el producto en sí.

Además, podríamos tener otra clase llamada ProductService que se encarga de la lógica de negocio relacionada con los productos. Esta clase podría tener métodos como addProduct, updateProduct y deleteProduct que interactúan con la capa de persistencia para agregar, actualizar o eliminar productos de la base de datos. Esta clase estaría enfocada en las preocupaciones relacionadas con la lógica de negocio.

Al separar estas preocupaciones en diferentes clases, podemos mantener un código más organizado, fácil de entender y mantener en el futuro. Además, si en algún momento necesitamos cambiar la forma en que se manejan los productos o la lógica de negocio detrás de ellos, podremos hacerlo de manera más fácil y sin afectar otras partes de la aplicación.

¿Cómo se aplicaría este principio?

graph TD
    A[User Interface] -->|Sends requests to| B{Controller}
    B -->|Uses| C[Service Layer]
    C -->|Uses| D[Data Access Layer]

En este ejemplo, el componente de interfaz de usuario (UI) envía solicitudes al controlador (Controller) que es responsable de procesar la lógica del negocio y hacer uso del servicio de capa (Service Layer) para realizar cualquier tarea necesaria. La capa de servicio, a su vez, utiliza la capa de acceso a datos (Data Access Layer) para interactuar con la base de datos o cualquier otro sistema de almacenamiento.

Este diagrama muestra cómo se separan las diferentes responsabilidades de la aplicación en capas diferentes, cada una con su propio conjunto de preocupaciones. Al mantener estas preocupaciones separadas, el código se vuelve más modular y mantenible, lo que facilita las pruebas y la evolución de la aplicación con el tiempo.