Principios de diseño SOLID simplificados | Por Srinath Singh | Febrero de 2022
En el desarrollo de software, es muy importante escribir un código limpio, fácil de entender, mantenible y extensible. Los principios de diseño de SOLID proporcionan algunas pautas sobre cómo estructurar el código.
Después de leer este artículo, comprenderá bien estos principios, así que comencemos sin más preámbulos.
1. Principio de responsabilidad única
«Debería haber una sola razón para cambiar de clase».
Este es el principio más básico e intuitivo que se puede ver en muchas aplicaciones bien desarrolladas. Simplemente significa que cada clase o método debe tener una sola responsabilidad o una sola tarea relacionada con la realización. Tener múltiples responsabilidades puede generar múltiples errores, y los cambios en una sola clase pueden tener algunas consecuencias no deseadas.
Lo anterior es un ejemplo de una clase Logger simple que solo es responsable de imprimir datos en la consola. Obviamente, sería muy inusual usar la misma clase, por ejemplo, para fines de inicio de sesión de usuario.
2. El principio de apertura y cierre.
«Los cursos deben estar abiertos para extensión pero cerrados para modificación».
Debería poder extender el comportamiento de la clase sin modificarlo. Para evitar nuevos errores, el código existente y probado debe actualizarse lo menos posible.
Aquí hay un ejemplo de una operación básica, no se puede ver operación de suma ni sustracción Si se agregan nuevas operaciones en el futuro, la clase debe modificarse, simplemente puede implementar Operación y proporcione su propia implementación.
3. Principio de sustitución de Leskov
«Sea φ(x) una propiedad demostrable sobre un objeto x de tipo T. Entonces φ(y) debería ser cierto para un objeto y de tipo S, donde S es un subtipo de T».
¡Todo bien! ¡No se deje intimidar por la definición, permítame simplificarlo para usted!
Si tenemos una clase principal, deberíamos poder reemplazarla con su subclase sin romper ninguna lógica, es así de simple. Veamos un ejemplo.
Como se muestra arriba, si ciclo para reemplazar vehículo arrojará NoEngineFoundException(), Esto viola el principio de sustitución de Liskov para corregirlo, puede crear más bifurcaciones vehículo Ingresar vehiculo con motor y vehículo sin motor Y definir su implementación concreta de la siguiente manera.
igual que ahora ciclo ampliar VehículoSinMotor No hay problema al llamar empieza a moverte() método. Este principio asegura que una clase principal y sus subclases se puedan usar de la misma manera sin causar ningún problema.
4. Principio de aislamiento de interfaz
«Los clientes no deberían verse obligados a confiar en interfaces que no usan».
Si su interfaz tiene muchos métodos, es poco probable que todas sus implementaciones los usen, por lo que tiene más sentido dividirla en otras interfaces más pequeñas.
Está claro de lo anterior que no es necesario implementar un cuadrado como una figura 2D para calcular su volumen, para evitar esto, debe dividir su interfaz en casos de uso más elaborados de la siguiente manera.
Un cliente puede implementar cualquier interfaz que necesite sin tener que proporcionar implementaciones obligatorias para métodos no utilizados.
5. Principio de inversión de dependencia
«Los módulos de alto nivel no deberían depender de los módulos de bajo nivel. Ambos deberían depender de abstracciones».
«Los resúmenes no deben depender de los detalles. Los detalles deben depender de las abstracciones».
Este principio básicamente significa que sus clases principales no deben estar estrechamente acopladas con sus clases dependientes, el siguiente ejemplo muestra el estrecho acoplamiento entre clases.
Veamos cómo usar constructores para eliminar este acoplamiento estrecho. inyección de dependencia.
Entonces, el comportamiento de la clase se puede cambiar en tiempo de ejecución sin ningún esfuerzo adicional, ahora computadora clase aceptada monitor y teclado Tipos de objetos que eliminan el acoplamiento directo de clases y abstracciones. Esto también facilita la prueba unitaria del código, ya que las clases ahora están disponibles de forma independiente.
Esto nos lleva al final del artículo, si le gustó este artículo, haga clic en Clapp! para apoyarlo. Sígueme para más artículos relacionados con la tecnología que publicaré pronto. ¡descansa en paz!
Referirse a: socio de código
¡Puedes conectarte conmigo en LinkedIn!
![Tecnología 2 [pt] -¿O plagio? | Douglas Magno | Mayo de 2021](https://sistemaandroid.info/wp-content/uploads/2021/05/Tecnologia-2-pt-¿O-plagio-Douglas-Magno-Mayo.jpeg "Tecnología 2 [pt] -¿O plagio? | Douglas Magno | Mayo de 2021 12")
