Principio SÓLIDO en programación: comprensión con ejemplos de la vida real

En el desarrollo de software, el Diseño Orientado a Objetos juega un papel crucial cuando se trata de escribir código flexible, escalable, mantenible y reutilizable. Hay tantos beneficios de usar OOD, pero cada desarrollador también debe tener el conocimiento del principio SOLID para un buen diseño orientado a objetos en la programación. El principio SOLID fue introducido por Robert C. Martin , también conocido como Uncle Bob , y es un estándar de codificación en la programación. Este principio es un acrónimo de los cinco principios que se dan a continuación…

1. Principio de responsabilidad única (PRS)
2. Principio abierto/cerrado
3. Principio de sustitución de Liskov (LSP)
4. Principio de segregación de interfaz (ISP)
5. Principio de inversión de dependencia (DIP)

El principio SOLID ayuda a reducir el acoplamiento estrecho. El acoplamiento estrecho significa que un grupo de clases depende en gran medida unas de otras, lo que debe evitar en su código. Lo opuesto al acoplamiento fuerte es el acoplamiento débil y su código se considera un buen código cuando tiene clases débilmente acopladas. Las clases débilmente acopladas minimizan los cambios en su código, ayudan a hacer 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 una sola razón para cambiar «, lo que significa que cada clase debe tener una responsabilidad única, un trabajo único o un propósito único. Tomemos el ejemplo del desarrollo de software. La tarea se divide en diferentes miembros que hacen cosas diferentes, ya que los diseñadores front-end diseñan, el probador hace las pruebas y el desarrollador backend se encarga de la parte de desarrollo backend, entonces podemos decir que todos tienen un solo trabajo o responsabilidad.
La mayoría de las veces sucede que cuando los programadores tienen que agregar funciones o un nuevo comportamiento, implementan todo en la clase existente, lo cual es completamente incorrecto. Hace que su código sea largo, complejo y consume tiempo cuando más tarde es necesario modificar algo. Usar capasen su aplicación y divida las clases de Dios en clases o módulos más pequeños.

2. Principio abierto/cerrado: este principio establece que » las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas para la extensión, pero cerradas para la modificación «, lo que significa que debe poder extender el comportamiento de una clase, sin modificarlo. .
Supongamos que el desarrollador A necesita publicar una actualización para una biblioteca o marco y el desarrollador B quiere alguna modificación o agregar alguna función, entonces el desarrollador B puede ampliar la clase existente creada por el desarrollador A, pero se supone que el desarrollador B no debe modificar la clase directamente. . El uso de este principio separa el código existente del código modificado para que proporcione una mejor estabilidad, mantenibilidad y minimiza los cambios como en su código.

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 primarias «. Este principio garantiza que cualquier clase que sea hija de una clase padre se pueda usar en lugar de su padre sin ningún comportamiento inesperado.
Puede entenderlo de una manera que el hijo de un agricultor debe heredar las habilidades agrícolas de su padre y debe poder reemplazar a su padre si es necesario. Si el hijo quiere convertirse en agricultor, puede reemplazar a su padre, pero si quiere convertirse en jugador de críquet, definitivamente el hijo no puede reemplazar a su padre, aunque ambos pertenecen a la misma jerarquía familiar.
Uno de los ejemplos clásicos de este principio es un rectángulo que tiene cuatro lados. La altura de un rectángulo puede ser cualquier valor y el ancho puede ser 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 cuadrada. Para hacer eso, debe 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, así que si lo hace que violará el principio de sustitución de Liskov. Consulte el enlace Principio de sustitución de Liskov para una mejor comprensión.

4. Principio de segregación de interfaces: este principio es el primero que se aplica a las interfaces en lugar de a las clases en SOLID y es similar al principio de responsabilidad única. Establece que “ no obligues a ningún cliente a implementar una interfaz que es irrelevante para ellos ”. Aquí, su objetivo principal es centrarse en evitar una interfaz voluminosa y dar preferencia a muchas interfaces pequeñas específicas del cliente. Debe preferir muchas interfaces de cliente en lugar de una interfaz general y cada interfaz debe tener una responsabilidad específica.
Supongamos que entras en un restaurante y eres vegetariano puro. El mesero en ese restaurante le dio la tarjeta de menú que incluye artículos vegetarianos, artículos no vegetarianos, bebidas y dulces. En este caso, como cliente, debe tener una tarjeta de menú que incluya solo elementos vegetarianos, no todo lo que no come en su comida. Aquí el menú debe ser diferente para diferentes tipos de clientes. La tarjeta de menú común o general para todos se puede dividir en varias tarjetas en lugar de solo una. 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: antes de discutir este tema, tenga en cuenta que la inversión de dependencia y la inyección de dependencia son conceptos diferentes. La mayoría de las personas se confunden al respecto y consideran que ambos son iguales. Ahora hay dos puntos clave a tener en cuenta sobre este principio.

• Los módulos/clases de alto nivel no deben depender de módulos/clases de bajo nivel. Ambos deben depender de abstracciones.
• Las abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones.

Las líneas anteriores simplemente indican que si un módulo o clase alto dependerá más de módulos o clases de bajo nivel, entonces su código tendrá un acoplamiento estrecho y si intentará hacer un cambio en una clase, puede romper otra clase, lo cual es arriesgado. a nivel de producción. Así que siempre trate de hacer que las clases se acoplen libremente tanto como pueda y puede lograrlo a través de la abstracción . El motivo principal de este principio es desacoplar las dependencias, de modo que si la clase A cambia, la clase B no necesita preocuparse ni saber acerca de los cambios.
Puede considerar el ejemplo de la vida real de una batería remota de TV. Su control remoto necesita una batería, pero no depende de la marca de la batería. Puede usar cualquier marca XYZ que desee y funcionará. Entonces podemos decir que el control remoto del televisor está vagamente asociado con el nombre de la marca. La inversión de dependencia hace que su código sea más reutilizable.