Este artículo está dirigido a personas que ya han tenido su primer acercamiento a React, y que, como principiantes, tienen dudas sobre cómo funciona setState y cómo usarlo correctamente. También debería ayudar a los desarrolladores de nivel medio a superior a usar formas más limpias y abstractas de establecer el estado, y hacer que las funciones de orden superior manejen y abstraigan el estado.

¡Solo lee y diviértete!

¡Así que toma una taza de café y sigue leyendo!

Conceptos básicos de setState( )

Los componentes de React le permiten dividir la interfaz de usuario (IU) en piezas independientes y reutilizables, para que pueda pensar en cada pieza de forma aislada.

Conceptualmente, los componentes son como funciones de JavaScript. Aceptan entradas arbitrarias (llamadas "propiedades" o "props") y devuelven elementos React que describen lo que debería aparecer en la pantalla.

Si necesita darle al usuario la oportunidad de ingresar algo o de alguna manera cambiar las variables que el componente recibe como propiedades, necesitará setState.

Ya sea que declare un Componente como una función o una clase, nunca debe modificar sus propios accesorios.

Todos los componentes de React deben actuar como funciones puras con respecto a sus propiedades. Esto significa funciones que nunca intentan cambiar sus entradas y siempre devuelven el mismo resultado para las mismas entradas.

Por supuesto, las interfaces de usuario de las aplicaciones son dinámicas y cambian con el tiempo. Por eso se creó state.

State permite que los componentes de React cambien su salida con el tiempo en respuesta a las acciones del usuario, las respuestas de la red y cualquier otra cosa, sin violar esta regla.

Los Componentes definidos como clases tienen algunas características adicionales. El estado local es una función disponible solo para los Componentes de clase.

setState es el método API proporcionado con la librería para que el usuario pueda definir y manipular el estado a lo largo del tiempo.

Tres reglas generales al usar setState( )

No modifiques el estado directamente

Las actualizaciones de estado pueden ser asincrónicas

React puede agrupar varias llamadas setState() en una sola actualización para mejorar el rendimiento.

Debido a que this.props y this.state pueden actualizarse de forma asíncrona, no debe confiar en sus valores para calcular el siguiente estado.    

Siempre debe hacer este tipo de manipulación con un enfoque funcional, proporcionando el state y los props y devolviendo el nuevo state basado en el anterior.

Las actualizaciones de estado se fusionan

Cuando llamas a setState(), React fusiona el objeto que proporcionas en el resto del state actual.

En el siguiente ejemplo, estamos actualizando la variable dogNeedsVaccination independientemente de las otras variables de state.

La fusión es superficial, por lo que this.setState({ dogNeedsVaccination: true }) deja intactas las otras variables, reemplazando solo el valor de dogNeedsVaccination.

Respeta el flujo de datos y evita el estado al máximo

¡Los datos fluyen hacia abajo! Ni los componentes principales ni los secundarios pueden saber si un determinado componente tiene estado o no, y no debería importarles si se define como una función o una clase.

Es por eso que el state a menudo se llama local o encapsulado. No es accesible a ningún componente que no sea el que lo posee y lo configura.

Cuando estableces una propiedad de estado y lo usas en tu componente, estás interrumpiendo el flujo de las propiedades de renderizado. Si por alguna razón la propiead pasad a tu componente cambia en el componente padre, ¿el hijo no se volverá a renderizar automáticamente por arte de magia?

Veamos un ejemplo:

Aquí tienes un Componente Home que está generando un número mágico cada 1000ms y poniéndolo en su propio state.

Después de eso, representa el número e invoca a tres Componentes Child (Hermanos) que recibirán el número mágico con el objetivo de mostrarlo usando tres enfoques diferentes:

Primer enfoque

El Componente ChildOfHome está respetando el flujo de cascada de props de React y, considerando que el objetivo es solo mostrar el número mágico, está renderizando los props recibidos directamente.

Segundo enfoque

El Componente ChildOfHomeBrother recibe las props de su padre y, invocando componentDidMount, establece el número mágico en el state. Luego representa el state.magicNumber.

Este ejemplo no funcion porque render()no sabe que una prop ha cambiado, por lo que no activa la nueva representación del componente. Como el componente y no se vuelve a representar, no se invoca el componentDidMount y la pantalla no se actualiza.

Tercer enfoque

Por lo general, cuando intentamos que funcione con el segundo enfoque, pensamos que falta algo. ¡En lugar de dar un paso atrás, seguimos agregando cosas al código para que funcione!

Entonces, en este tercer enfoque, agregamos componentDidUpdate para verificar si hay un cambio en props para activar la nueva representación del componente. Esto es innecesario y nos lleva a un código sucio. También trae consigo costos de rendimiento que se multiplicarán por la cantidad de veces que hagamos esto en una aplicación grande donde tenemos muchos componentes encadenados y efectos secundarios.

Esto es incorrecto a menos que necesite permitir que el usuario cambie el valor de prop recibido.

Si no necesita cambiar el valor de prop, siempre trate de mantener las cosas funcionando de acuerdo con el Flujo de React (Primer Enfoque).

Puede consultar una página web en funcionamiento con este ejamplo que he preparado para ti en  Glitch. ¿Echa un vistazo y diviértete?

Consulta también el código en  Home.js y  HomeCodeCleaned.js  (sin las cosas de HTML) en mi repositorio sobre este artículo.

Cómo establecer el estado con setState

Entonces, llegados a este punto, ¡creo que es hora de ensuciarse las manos!

¡Juguemos un poco con setState y mejoremos eso! Solo sigue y toma otra taza de café!

Vamos a crear un pequeño formulario para actualizar los datos del usuario:

Aquí está el código para el ejemplo anterior:

Estamos configurando el state como un objeto y no hay problema porque nuestro estado actual no depende de nuestro último estado.

¿Qué pasa si creamos un campo de formulario más para introducir y mostrar el Apellido (Last Name)?

¡Bien! Hemos abstraído el método handleFormChange para poder manejar todos los campos de entrada y setState.

¿Qué pasa si agregamos un botón para marcar los datos como válidos o no válidos y un contador para saber cuántos cambios hemos hecho en el state?

¡Sí! ¡Lo estamos petando! ¡Hemos abstraído muchas cosas!

Hmmm... Digamos que no quiero una casilla de verificación para controlar la variable, isValid sino un simple botón de alternancia.

También separemos el controlador de contador de este método. Funciona bien, pero en situaciones más complejas en las que React necesita cambios por lotes/grupos, no es una buena política confiar en la variable this.state.counter para agregar uno más. Este valor puede cambiar sin que te des cuenta.

Estamos usando una copia superficial del mismo en el instante en que se invoca la operación, y en ese momento determinado no sabes si su valor es el que esperabas o no.

¡Vamos a ponernos un poco funcionales!

Vale – Hemos perdido la abstracción porque hemos separado los controladores, ¡pero es por una buena razón!

Así que en este momento mantenemos handleFormChange pasando un objeto al método API setState. Pero los métodos handleCounter y handleIsValid ahora son funcionales y comienzan tomando el estado actual y luego, dependiendo de ese estado, cambiándolo al siguiente.

Esta es la forma correcta de cambiar el estado de las variables que dependen del estado anterior.

¿Qué pasa si queremos cambiar el estado de console.log() de los formularios de entrada firstName y lastName cada vez que ocurre un cambio? ¡Hagamos un intento!

¡Muy bien! Cada vez que se produce handleFormChange (lo que significa que se ha pulsado una nueva tecla), se invoca el método logFields() y se registra el estado actual en la consola.

Comprobemos la consola del navegador:

¡Espera! ¿Qué ha pasado aquí, amigo? ¡El registro de la consola muestra un cambio antes del cambio en el formulario actual! ¿Por qué está pasando esto?

¡¡setState es asíncrono!!

Ya lo sabíamos, ¡pero ahora lo estamos viendo con nuestros propios ojos! ¿Lo que está pasando allí? Echemos un vistazo a los métodos handleFormChange y logFields anteriores.

Entonces, el método handleFormChange recibe el nombre y el valor del evento, luego hace un setState de estos datos. Luego llama a handleCounter para actualizar la información del contador y, al final, invoca el método logFields. El método logFields toma el estado actual currentState y devuelve 'Eduard' en lugar de 'Eduardo'.

La cosa es: setState es asíncrono y no actúa en el momento. React está haciendo su trabajo y ejecuta primero el método logFields, dejando setState para el siguiente ciclo de eventos.

Pero, ¿cómo podemos evitar este tipo de situaciones?

Bien, la API setState tiene una callback (devolución de llamada) para evitar esta situación:

Si queremos que logFields() tenga en cuenta los cambios recientes que hemos realizado en el estado, debemos invocarlo dentro de la devolución de llamada, así:

Bien, ¡ahora está funcionando!

Le decimos a React: “¡Oye, React! Ten cuidado de que cuando invoques el método logFields, quiero que tenga el estado ya actualizado, ¿de acuerdo? ¡Confío en ti!"

React dice: “¡Está bien, Edo! ¡Voy a encargarme de todo este montón de cosas que suelo hacer en el patio trasero con setState y solo cuando termine con eso invocaré logField()! Tranquilo colega! Relájate!”

Y, de hecho, ¡funcionó!

¡Bien todos! En este momento hemos manejado los principales escollos de setState.

¿Tienes el coraje de ir más allá? Toma una taza de café y pongámonos realmente chulos.

Poniéndose elegantes con setState( )

Ahora que tenemos los métodos handleCounter y handleIsValid, y setState() expresado con funciones, ¡podemos componer la actualización de estado con otras funciones! ¡Me gusta la composición! ¡Vamos a divertirnos un poco!

Podemos llevar la lógica dentro de setState a una función fuera del componente de clase. Llamémoslo toggleIsValid. ☝️

Ahora esta función puede vivir fuera del componente de clase, en cualquier lugar de su aplicación.

¿Qué pasa si usamos una función de orden superior?

Guau! Ahora ya no estamos invocando la función toggleIsValid. Invocamos una función abstracta de orden superior llamada toggleKey y le pasamos una clave (una cadena en este caso).

¿Cómo necesitamos cambiar la función toggleIsValid ahora?

¡¿Qué?! Ahora tenemos una función llamada toggleKey que recibe una clave y devuelve una nueva función que cambia de estado según la clave suministrada.

Esta toggleKey puede estar en una biblioteca o en un archivo auxiliar. Se puede invocar en muchos contextos diferentes para cambiar el estado de lo que quieras a su opuesto.

¡Genial!

Hagamos lo mismo con el controlador del contador de incrementos:

‌

‌¡Sí! ¡Funciona! Que guay! Vamos a volvernos locos ahora...

Disparando a la luna y regresando

¿Qué sucede si creamos una función makeUpdater genérica que recibe la función de transformación que desea aplicar, toma la clave y devuelve la función de estado que administra el estado con la función de transformación y la clave? ¿Un poco confundido? ¡Vamos!

Ok, eso es suficiente... Nos paramos aquí

Puedes consultar todo el código que hemos hecho en este repositorio de GitHub.

Por último, pero no menos importante

No olvides evitar al máximo el uso del estado y respetar la cascada de propiedades de renderizado de React.

No olvides que setState es asíncrono.

No olvides que setState puede tomar un objeto o una función

No olvides que debes pasar una función cuando tu próximo estado dependa de su estado anterior.

¡Muchas gracias!

Hay mucho que considerar cuando se trabaja en una aplicación React, especialmente cuando se trata de formularios. Incluso si puede crear un botón de envío y actualizar el estado de su aplicación de la manera que desee, borrar los formularios puede ser difícil.

Digamos que su aplicación tiene formularios dinámicos como este:

import React from "react";
import Form from "./Form";

const Cart = props => {
  return (
    <div>
      <Form Items={props.Items} onChangeText={props.onChangeText} />

      <button onClick={props.handleSubmit}>Submit</button>
      <button onClick={props.handleReset}>Reset</button>
    </div>
  );
};

export default Cart;

import React from "react";

const Form = props => {
  return (
    <div>
      {props.Items.map((item, index) => (
        <input
          name={item.name}
          placeholder={item.description}
          data-type={item.dtype}
          data-group={item.group}
          onChange={e => props.onChangeText(e)}
          key={index}
        />
      ))}
    </div>
  );
};
export default Form;

Y los cuadros de entrada simples se representan en la página:

Cuando un usuario ingresa texto en uno de los cuadros de entrada, se guarda en el estado de la aplicación en grupos como este:

Itemvalues:
  0:
    groupA: 
            item1: itemvalue1
            item2: itemvalue2
    groupB: 
            item3: itemvalue3
            item4: itemvalue4

Es bastante complicado, pero conseguiste que funcionara.

En handleReset, puedes restablecer los valores de itemvalues a un estado null cuando se presiona el botón "Reset":

handleReset = () => {
  this.setState({
    itemvalues: [{}]
  });
};

Pero el problema es que el texto no se borra de todos los cuadros de entrada:

Ya has manejado el almacenamiento del texto real en el estado, así que aquí hay una forma sencilla de borrar el texto de todos los cuadros de entrada.

Cómo borrar los valores de todos los campos de entrada

En la parte superior de handleReset, use document.querySelectorAll('input') para seleccionar todos los campos de entrada de la página:

handleReset = () => {
  document.querySelectorAll('input');
  this.setState({
    itemvalues: [{}]
  });
};

document.querySelectorAll('input') devuelve un NodeList, lo cual es un poco diferente a un arreglo, así que no puedes usar ninguno de los útiles métodos de arreglos con él.

Para convertirlo en un arreglo, pasa document.querySelectorAll('input') a Array.from():

handleReset = () => {
  Array.from(document.querySelectorAll('input'));
  this.setState({
    itemvalues: [{}]
  });
};

Ahora todo lo que tienes que hacer es iterar a través de cada una de las entradas y establecer su atributo de value a una cadena vacía. El método forEach es un buen candidato para esto:

handleReset = () => {
  Array.from(document.querySelectorAll("input")).forEach(
    input => (input.value = "")
  );
  this.setState({
    itemvalues: [{}]
  });
};

Ahora, cuando un usuario presiona el botón "Reset", el valor de cada entrada también se borra:

Los Principios SOLID tienen cinco principios de diseño de clases Orientado a Objetos. Son un conjunto de reglas y mejores prácticas a seguir al diseñar una estructura de clase.

Estos cinco principios nos ayudan a comprender la necesidad de ciertos patrones de diseño y arquitectura de software en general. Así que creo que es un tema que todo desarrollador debería aprender.

Este artículo te enseñará todo lo que necesitas saber para aplicar los principios SOLID a tus proyectos.

Empezaremos echando un vistazo a la historia de este término. Luego vamos a entrar en los detalles esenciales, los por qué y cómo de cada principio, creando un diseño de clase y mejorándolo paso a paso.

¡Así que toma una taza de café, mate o té y empecemos!

Antecedentes

Los principios SOLID fueron introducidos por primera vez por el famoso científico informático Robert J. Martin (también conocido como el tío Bob) en uno de sus artículos en 2000. Pero el acrónimo SOLID fue introducido más tarde por Michael Feathers.

El tío Bob también es el autor de los libros best-sellers Clean Code y Clean Architecture, y es uno de los participantes de la "Alianza Agile".

Por lo tanto, no sorprende que todos estos conceptos de codificación limpia, arquitectura orientada a objetos y patrones de diseño estén de alguna manera conectados y se complementen entre sí.

Todos tienen el mismo propósito:

"Para crear código comprensible, legible y comprobable en el que muchos desarrolladores puedan trabajar en colaboración."

Veamos cada principio uno por uno. Siguiendo el acrónimo inglés SOLID, son:

• El Principio de responsabilidad única (Single Responsibility Principle)
• El Principio Abierto-Cerrado (Open-Closed Principle)
• El Principio de sustitución de Liskov (Liskov Substitution Principle)
• El Principio de segregación de interfaz (Interface Segregation Principle)
• El Principio de inversión de dependencia (Dependency Inversion Principle)

Principio de responsabilidad única

El Principio de Responsabilidad Única dice que una clase debe hacer una cosa y, por lo tanto, debe tener una sola razón para cambiar.

Para enunciar este principio más técnicamente: Solo un cambio potencial (lógica de base de datos, lógica de registro, etc.) en la especificación del software debería poder afectar la especificación de la clase.

Esto significa que si una clase es un contenedor de datos, como una clase Libro o una clase Estudiante, y tiene algunos campos relacionados con esa entidad, debería cambiar solo cuando cambiamos el modelo de datos.

Es importante seguir el principio de responsabilidad única. En primer lugar, debido a que muchos equipos diferentes pueden trabajar en el mismo proyecto y editar la misma clase por diferentes motivos, esto podría dar lugar a módulos incompatibles.

En segundo lugar, facilita el control de versiones. Por ejemplo, digamos que tenemos una clase de persistencia que maneja las operaciones de la base de datos y vemos un cambio en ese archivo en las confirmaciones de GitHub. Al seguir el PRU, sabremos que está relacionado con el almacenamiento o con cosas relacionadas con la base de datos.

Los conflictos de fusión son otro ejemplo. Aparecen cuando diferentes equipos modifican el mismo archivo. Pero si se sigue el PRU, aparecerán menos conflictos: los archivos tendrán una sola razón para cambiar y los conflictos que existen serán más fáciles de resolver.

Trampas comunes y Anti-patrones

En esta sección, veremos algunos errores comunes que violan el Principio de Responsabilidad Única. Luego hablaremos sobre algunas formas de solucionarlos.

Veremos el código de un programa simple de facturación de librería como ejemplo. Comencemos definiendo una clase de libro para usar en nuestra factura.

class Libro {
	String nombre;
	String nombreAutor;
	int anyo;
	int precio;
	String isbn;

	public Libro(String nombre, String nombreAutor, int anyo, int precio, String isbn) {
		this.nombre = nombre;
		this.nombreAutor = nombreAutor;
		this.anyo = anyo;
        this.precio = precio;
		this.isbn = isbn;
	}
}

Esta es una clase de libro simple con algunos campos. Nada sofisticado. No estoy haciendo que los campos sean privados para que no tengamos que lidiar con getters y setters y podamos centrarnos en la lógica.

Ahora vamos a crear la clase de factura que contendrá la lógica para crear la factura y calcular el precio total. Por ahora, suponga que nuestra librería solo vende libros y nada más.

public class Factura {

	private Libro libro;
	private int cantidad;
	private double tasaDescuento;
	private double tasaImpuesto;
	private double total;

	public Factura(Libro libro, int cantidad, double tasaDescuento, double tasaImpuesto) {
		this.libro = libro;
		this.cantidad = cantidad;
		this.tasaDescuento = tasaDescuento;
		this.tasaImpuesto = tasaImpuesto;
		this.total = this.calculaTotal();
	}

	public double calculaTotal() {
	        double precio = ((libro.precio - libro.precio * tasaDescuento) * this.cantidad);

		double precioConImpuestos = precio * (1 + tasaImpuesto);

		return precioConImpuestos;
	}

	public void imprimeFactura() {
            System.out.println(cantidad + "x " + libro.nombre + " " +          libro.precio + "$");
            System.out.println("Tasa de Descuento: " + tasaDescuento);
            System.out.println("Tasa de Impuesto: " + tasaImpuesto);
            System.out.println("Total: " + total);
	}

        public void guardarArchivo(String nombreArchivo) {
	// Crea un archivo con el nombre dado y escribe la factura.
	}

}

Aquí está nuestra clase de Factura. También contiene algunos campos sobre facturación y 3 métodos:

• calculaTotal método que calcula el precio total,
• imprimeFactura método que debería imprimir la factura por consola, y
• guardaArchivo método responsable de escribir la factura en un archivo.

Debe darse un segundo para pensar en lo que está mal con este diseño de clase antes de leer el siguiente párrafo.

Bien, entonces, ¿qué está pasando aquí? Nuestra clase viola el Principio de Responsabilidad Única de múltiples maneras.

La primera violación es el método imprimeFactura, el cual contiene nuestra lógica de impressión. El PRU establece que nuestra clase solo debería tener una única razón para cambiar, y esa razón debería ser un cambio en el cálculo de la factura para nuestra clase.

Pero en esta arquitectura, si queremos cambiar el formato de impresión, necesitaríamos cambiar la clase. Esta es la razón por la que no deberíamos tener lógica de impresión mezclada con lógica de negocios en la misma clase.

Hay otro método que viola el PRU en nuestra clase: el método guardarArchivo. También es un error extremadamente común mezclar la lógica de persistencia con la lógica de negocios.

No piense solo en términos de escribir en un archivo, podría ser guardarlo en una base de datos, hacer una llamada a la API u otras cosas relacionadas con la persistencia.

Entonces, ¿cómo podemos arreglar esta función de impresión?, puede preguntar.

Podemos crear nuevas clases para nuestra lógica de impresión y persistencia, por lo que ya no necesitaremos modificar la clase de factura para esos fines.

Creamos 2 clases, FacturaImpresion y FacturaPersistencia, y movemos los métodos.

public class FacturaImpresion {
    private Factura factura;

    public FacturaImpresion(Factura factura) {
        this.factura = factura;
    }

    public void imprimir() {
        System.out.println(factura.cantidad + "x " + factura.libro.nombre + " " + factura.libro.precio + " $");
        System.out.println("Tasa de Descuento: " + factura.tasaDescuento);
        System.out.println("Tasa de Impuesto: " + factura.tasaImpuesto);
        System.out.println("Total: " + factura.total + " $");
    }
}

public class FacturaPersistencia {
    Factura factura;

    public FacturaPersistencia(Factura factura) {
        this.factura = factura;
    }

    public void guardarArchivo(String nombreArchivo) {
        // Crea un archivo con el nombre dado y escribe la factura.
    }
}

Ahora nuestra estructura de clases obedece al principio de responsabilidad única y cada clase es responsable de un aspecto de nuestra aplicación. ¡Excelente!

Principio de apertura y cierre

El principio de apertura y cierre exige que las clases deban estar abiertas a la extensión y cerradas a la modificación.

Modificación significa cambiar el código de una clase existente y extensión significa agregar una nueva funcionalidad.

Entonces, lo que este principio quiere decir es: Deberíamos poder agregar nuevas funciones sin tocar el código existente para la clase. Esto se debe a que cada vez que modificamos el código existente, corremos el riesgo de crear errores potenciales. Por lo tanto, debemos evitar tocar el código de producción probado y confiable (en su mayoría) si es posible.

Pero, ¿cómo vamos a agregar una nueva funcionalidad sin tocar la clase?, puede preguntarse. Por lo general, se hace con la ayuda de interfaces y clases abstractas.

Ahora que hemos cubierto los conceptos básicos del principio, apliquémoslo a nuestra aplicación Factura.

Digamos que nuestro jefe vino a nosotros y dijo que quiere que las facturas se guarden en una base de datos para que podamos buscarlas fácilmente. Creemos que está bien, esto es fácil jefe, ¡solo dame un segundo!

Creamos la base de datos, nos conectamos a ella y agregamos un método de guardado a nuestra clase FacturaPersistencia:

public class FacturaPersistencia {
    Factura factura;

    public FacturaPersistencia(Factura factura) {
        this.factura = factura;
    }

    public void guardarArchivo(String nombreArchivo) {
        // Crea un archivo con el nombre dado y escribe la factura.
    }

    public void guardarEnBaseDatos() {
        // Guarda la factura en la base de datos
    }
}

Lamentablemente, nosotros, como desarrolladores perezosos de la librería, no diseñamos las clases para que fueran fácilmente ampliables en el futuro. Entonces, para agregar esta función, hemos modificado la clase FacturaPersistencia.

Si nuestro diseño de clase obedeciera al principio Abierto-Cerrado, no necesitaríamos cambiar esta clase.

Entonces, como el desarrollador perezoso pero inteligente de la librería, vemos el problema de diseño y decidimos refactorizar el código para obedecer el principio.

interface FacturaPersistencia {

    public void guardar(Factura factura);
}

Cambiamos el tipo de FacturaPersistencia a Interface y agregamos un método de guardado. Cada clase de persistencia implementará este método de guardado.

public class BaseDeDatosPersistencia implements FacturaPersistencia {

    @Override
    public void guardar(Factura factura) {
        // Guardar en la base de datos
    }
}

public class ArchivoPersistencia implements FacturaPersistencia {

    @Override
    public void guardar(Factura factura) {
        // Guardar en archivo
    }
}

Así que nuestra estructura de clases ahora se ve así:

Ahora nuestra lógica de persistencia es fácilmente extensible. Si nuestro jefe nos pide que agreguemos otra base de datos y tengamos 2 tipos diferentes de bases de datos como MySQL y MongoDB, podemos hacerlo fácilmente.

Puede pensar que podríamos simplemente crear múltiples clases sin una interfaz y agregar un método de guardado para todas ellas.

Pero supongamos que ampliamos nuestra aplicación y tenemos varias clases de persistencia como FacturaPersistencia, LibroPersistencia y creamos una clase AdministradorPersistencia que administra todas las clases de persistencia:

public class AdministradorPersistencia {
    FacturaPersistencia facturaPersistencia;
    LibroPersistencia libroPersistencia;
    
    public AdministradorPersistencia(FacturaPersistencia facturaPersistencia, LibroPersistencia libroPersistencia) {
        this.facturaPersistencia = facturaPersistencia;
        this.libroPersistencia = libroPersistencia;
    }
}

Ahora podemos pasar cualquier clase que implemente la interfaz FacturaPersistencia a esta clase con la ayuda del polimorfismo. Esta es la flexibilidad que proporcionan las interfaces.

Principio de sustitución de Liskov

El Principio de Sustitución de Liskov establece que las subclases deben ser sustituibles por sus clases base.

Esto significa que, dado que la clase B es una subclase de la clase A, deberíamos poder pasar un objeto de la clase B a cualquier método que espere un objeto de la clase A y el método no debería dar ningún resultado extraño en ese caso.

Este es el comportamiento esperado, porque cuando usamos la herencia asumimos que la clase secundaria hereda todo lo que tiene la superclase. La clase secundaria extiende el comportamiento pero nunca lo reduce.

Por lo tanto, cuando una clase no obedece este principio, genera algunos errores desagradables que son difíciles de detectar.

El principio de Liskov es fácil de entender, pero difícil de detectar en el código. Así que veamos un ejemplo.

class Rectangulo {
	protected int ancho, alto;

	public Rectangulo() {
	}

	public Rectangulo(int ancho, int alto) {
		this.ancho = ancho;
		this.alto = alto;
	}

	public int getAncho() {
		return ancho;
	}

	public void setAncho(int ancho) {
		this.ancho = ancho;
	}

	public int getAlto() {
		return alto;
	}

	public void setAlto(int alto) {
		this.alto = alto;
	}

	public int getArea() {
		return ancho * alto;
	}
}

Tenemos una clase Rectángulo simple y una función getArea que devuelve el área del rectángulo.

Ahora decidimos crear otra clase para Cuadrados. Como sabrás, un cuadrado es solo un tipo especial de rectángulo donde el ancho es igual a la altura.

class Cuadrado extends Rectangulo {
	public Cuadrado() {}

	public Cuadrado(int talla) {
		ancho = alto = talla;
	}

	@Override
	public void setAncho(int ancho) {
		super.setAncho(ancho);
		super.setAlto(ancho);
	}

	@Override
	public void setAlto(int alto) {
		super.setAlto(alto);
		super.setAncho(alto);
	}
}

Nuestra clase Cuadrado amplía la clase Rectángulo. Establecemos alto y ancho en el mismo valor en el constructor, pero no queremos que ningún cliente (alguien que use nuestra clase en su código) cambie el alto o el peso de una manera que pueda violar la propiedad cuadrada.

Por lo tanto, anulamos los setters para establecer ambas propiedades cada vez que se cambia una de ellas. Pero al hacerlo acabamos de violar el principio de sustitución de Liskov.

Vamos a crear una clase principal para realizar pruebas en la función getArea.

class Test {

   static void getAreaTest(Rectangulo r) {
      int ancho = r.getAncho();
      r.setAlto(10);
      System.out.println("Area esperada de " + (ancho * 10) + ", tiene " + r.getArea());
   }

   public static void main(String[] args) {
      Rectangulo rc = new Rectangulo(2, 3);
      getAreaTest(rc);

      Rectangulo sq = new Cuadrado();
      sq.setAncho(5);
      getAreaTest(sq);
   }
}

Al probador de su equipo se le ocurrió la función de prueba getAreaTest y le dice que su función getArea no pasa la prueba de objetos cuadrados.

En la primera prueba, creamos un rectángulo donde el ancho es 2 y la altura es 3 y llamamos a getAreaTest. La salida es 20 como se esperaba, pero las cosas salen mal cuando pasamos en la plaza. Esto se debe a que la llamada a la función setAlto en la prueba también establece el ancho y da como resultado un resultado inesperado.

Principio de segregación de interfaces

La segregación significa mantener las cosas separadas, y el Principio de Segregación de Interfaces se trata de separar las interfaces.

El principio establece que muchas interfaces específicas del cliente son mejores que una interfaz de propósito general. No se debe obligar a los clientes a implementar una función que no necesitan.

Este es un principio simple de entender y aplicar, así que veamos un ejemplo.

public interface Estacionamiento {

	void aparcarCoche(); // Reducir el recuento de puntos vacíos en 1
	void sacarCoche(); // Aumenta los espacios vacíos en 1
	void getCapacidad(); // Devuelve la capacidad del coche
	double calcularTarifa(Coche coche); // Devuelve el precio en función del número de horas.
	void hacerPago(Coche coche);
}

class Coche {

}

Modelamos un estacionamiento muy simplificado. Es el tipo de estacionamiento donde pagas una tarifa por hora. Ahora considere que queremos implementar un estacionamiento que sea gratuito.

public class EstacionamientoGratis implements Estacionamiento {

	@Override
	public void aparcarCoche() {
		
	}

	@Override
	public void sacarCoche() {

	}

	@Override
	public void getCapacidad() {

	}

	@Override
	public double calcularTarifa(Coche coche) {
		return 0;
	}

	@Override
	public void hacerPago(Coche coche) {
		throw new Exception("Estacionamiento es gratis");
	}
}

Nuestra interfaz de estacionamiento se componía de 2 cosas: lógica relacionada con el estacionamiento (aparcar coche, sacar automóvil, obtener capacidad) y lógica relacionada con el pago.

Pero es demasiado específico. Debido a eso, nuestra clase EstacionamientoGratis se vio obligada a implementar métodos relacionados con el pago que son irrelevantes. Separemos o segreguemos las interfaces.

Ahora hemos separado el estacionamiento. Con este nuevo modelo, incluso podemos ir más allá y dividir EstacionamientoPagado para admitir diferentes tipos de pago.

Ahora nuestro modelo es mucho más flexible, extensible y los clientes no necesitan implementar ninguna lógica irrelevante porque solo proporcionamos funcionalidad relacionada con el estacionamiento en la interfaz del estacionamiento.

Principio de inversión de dependencia

El principio de inversión de dependencia establece que nuestras clases deben depender de interfaces o clases abstractas en lugar de clases y funciones concretas.

En su artículo (2000), el tío Bob resume este principio de la siguiente manera:

"Si el PAC establece el objetivo de la arquitectura OO, el PID establece el mecanismo principal".

Estos dos principios están realmente relacionados y hemos aplicado este patrón antes mientras discutíamos el Principio Abierto-Cerrado.

Queremos que nuestras clases estén abiertas a la extensión, por lo que hemos reorganizado nuestras dependencias para que dependan de interfaces en lugar de clases concretas. Nuestra clase AdministradorPersistencia depende de FacturaPersistencia en lugar de las clases que implementan esa interfaz.

Conclusión

En este artículo, comenzamos con la historia de los principios SOLID y luego tratamos de adquirir una comprensión clara de los por qué y los cómo de cada principio. Incluso refactorizamos una aplicación de Factura simple para obedecer los principios de SOLID.

Quiero agradecerte por tomarte el tiempo de leer el artículo completo y espero que los conceptos anteriores sean claros.

Sugiero tener en cuenta estos principios al diseñar, escribir y refactorizar su código para que su código sea mucho más limpio, extensible y comprobable.

Si estás interesado en leer más artículos como este, puedes suscribirte a la lista de correo de mi blog para recibir una notificación cuando publique un nuevo artículo.