En el desarrollo de software, Diseño orientado a objetos juega un papel crucial cuando se trata de escribir código flexible, escalable, mantenible y reutilizable. Hay muchos beneficios al usar OOD, pero todo desarrollador también debe conocer el principio SOLID para un buen diseño orientado a objetos en programación. El principio SOLID fue introducido por Robert C. Martin, también conocido como tío Bob, y es un estándar de codificación en programación. Este principio es un acrónimo de los cinco principios que se detallan a continuación:

• Principio de Responsabilidad Única (SRP)
• Principio abierto/cerrado
• Principio de sustitución de Liskov (LSP)
• Principio de segregación de interfaz (ISP)
• Principio de inversión de dependencia (DIP)

El principio SÓLIDO ayuda a reducir el acoplamiento apretado. El acoplamiento estrecho significa que un grupo de clases dependen en gran medida unas de otras, lo que debes evitar en tu código.

• Lo opuesto al acoplamiento estrecho es el acoplamiento flexible y su código se considera un buen código cuando tiene clases débilmente acopladas.
• Las clases poco acopladas minimizan los cambios en su código y ayudan a que el código sea más reutilizable, mantenible, flexible y estable. Ahora analicemos uno por uno estos principios...

1. Principio de responsabilidad única

Este principio establece que Una clase debe tener solo una razón para cambiar lo que significa que cada clase debe tener una única responsabilidad, un único trabajo o un único propósito. En otras palabras, una clase debe tener sólo un trabajo o propósito dentro del sistema de software.

cómo cambiar el nombre de un directorio Linux

Entendamos el principio de responsabilidad única con un ejemplo:

Imagínese un panadero que se encarga de hornear pan. La función del panadero es centrarse en la tarea de hornear pan, asegurando que el pan sea de alta calidad, esté bien horneado y cumpla con los estándares de la panadería.

• Sin embargo, si el panadero también es responsable de administrar el inventario, ordenar suministros, atender a los clientes y limpiar la panadería, esto violaría el SRP.
• Cada una de estas tareas representa una responsabilidad separada y, al combinarlas, el enfoque y la eficacia del panadero al hornear pan podrían verse comprometidos.
• Para cumplir con el SRP, la panadería podría asignar diferentes roles a diferentes personas o equipos. Por ejemplo, podría haber una persona o equipo independiente responsable de gestionar el inventario, otro de pedir suministros, otro de atender a los clientes y otro de limpiar la panadería.

2. Principio abierto/cerrado

Este principio establece que Las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas a la extensión, pero cerradas a la modificación. lo que significa que debería poder extender el comportamiento de una clase sin modificarlo.

Entendamos el principio abierto/cerrado usando un ejemplo:

Imagina que tienes una clase llamadaPaymentProcessor>que procesa pagos para una tienda en línea. Inicialmente, elPaymentProcessor>La clase solo admite el procesamiento de pagos con tarjetas de crédito. Sin embargo, desea ampliar su funcionalidad para admitir también el procesamiento de pagos mediante PayPal.

En lugar de modificar lo existentePaymentProcessor>clase para agregar soporte de PayPal, puede crear una nueva clase llamadaPayPalPaymentProcessor>que extiende elPaymentProcessor>clase. De esta manera, elPaymentProcessor>La clase permanece cerrada para modificación pero abierta para extensión, adhiriéndose al principio abierto-cerrado.

escaneo java.siguientecadena

3. Principio de sustitución de Liskov

El principio fue introducido por Barbara Liskov en 1987 y de acuerdo con este principio Las clases derivadas o secundarias deben ser sustituibles por sus clases base o principales. . Este principio garantiza que cualquier clase que sea hija de una clase principal pueda utilizarse en lugar de su clase principal sin ningún comportamiento inesperado.

dormir en javascript

Entendamos el principio de sustitución de Liskov usando un ejemplo:

Uno de los ejemplos clásicos de este principio es un rectángulo que tiene cuatro lados. La altura de un rectángulo puede tener cualquier valor y el ancho puede tener cualquier valor. Un cuadrado es un rectángulo con igual ancho y alto. Entonces podemos decir que podemos extender las propiedades de la clase rectángulo a la clase cuadrado.

Para hacer eso, necesita intercambiar la clase secundaria (cuadrado) con la clase principal (rectángulo) para que se ajuste a la definición de un cuadrado que tiene cuatro lados iguales, pero una clase derivada no afecta el comportamiento de la clase principal, por lo que si lo hace que violará el Principio de Sustitución de Liskov.

4. Principio de segregación de interfaz

Este principio es el primer principio que se aplica a las interfaces en lugar de a las clases en SOLID y es similar al principio de responsabilidad única. Se afirma que No obligue a ningún cliente a implementar una interfaz que sea irrelevante para él. . Aquí su objetivo principal es centrarse en evitar interfaces pesadas y dar preferencia a muchas interfaces pequeñas específicas del cliente. Debería preferir muchas interfaces de cliente en lugar de una interfaz general y cada interfaz debería tener una responsabilidad específica.

Entendamos el principio de segregación de interfaces usando un ejemplo:

ordenar tuplas python

Supongamos que entras a un restaurante y eres vegetariano puro. El camarero de ese restaurante le entregó la tarjeta del menú que incluye platos vegetarianos, platos no vegetarianos, bebidas y dulces.

• En este caso, como cliente, debes tener una tarjeta de menú que incluya solo elementos vegetarianos, no todo lo que no comes en tu comida. Aquí el menú debe ser diferente para diferentes tipos de clientes.
• La carta de menú común o general para todos se puede dividir en varias cartas en lugar de una sola. El uso de este principio ayuda a reducir los efectos secundarios y la frecuencia de los cambios necesarios.

5. Principio de inversión de dependencia

El principio de inversión de dependencia (DIP) es un principio del diseño orientado a objetos que establece que Los módulos de alto nivel no deberían depender de módulos de bajo nivel. Ambos deberían depender de abstracciones. . Además, las abstracciones no deberían depender de los detalles. Los detalles deberían depender de abstracciones.

• En términos más simples, el DIP sugiere que las clases deberían basarse en abstracciones (por ejemplo, interfaces o clases abstractas) en lugar de implementaciones concretas.
• Esto permite un código más flexible y desacoplado, lo que facilita el cambio de implementaciones sin afectar otras partes del código base.

Entendamos el principio de inversión de dependencia con un ejemplo:

En un equipo de desarrollo de software, los desarrolladores dependen de un sistema de control de versiones abstracto (por ejemplo, Git) para gestionar y realizar un seguimiento de los cambios en el código base. No dependen de detalles específicos de cómo funciona internamente Git.

Esto permite a los desarrolladores centrarse en escribir código sin necesidad de comprender las complejidades de la implementación del control de versiones.