Foto - nesa - Unsplash
Acrónimo
SÓLIDO : denota los primeros cinco principios de la programación orientada a objetos:
- (SRP). / — . , - , « Unix» KISS.
- / (OCP). — . (Bertrand Meyer) — Eiffel.
- (LSP). , . , . (Barbara Liskov) — Clu.
- (ISP). (Robert Martin), , : « , ». .
- (DIP). , — . ( ).
Si sigue esto y estructura sus clases y funciones para que los principios SOLID sean verdaderos, es probable que obtenga un código confiable, comprensible y fácil de mantener. Por cierto, aquí hay ejemplos para ilustrar cómo funciona cada principio.
Quién trajo SOLID
Como habrás adivinado, fue el tío Bob el responsable de la mayor parte de los principios . Los describió exhaustivamente en sus Principios de diseño y patrones de diseño de 2000, y el ingeniero Michael Feathers sugirió el acrónimo SOLID. Si estás interesado, Michael tiene un libro donde da consejos sobre cómo "revivir" el sistema heredado y no volverse loco por el camino.
Foto - Oskar Yildiz -
La misión de Unsplash SOLID es ayudar a desarrollar aplicaciones que sean fáciles de mantener y expandir con el tiempo. Pero este conjunto de pautas suele ser criticado.
Por que se critica
A veces, estos principios se denominan "demasiado vagos", lo que dificulta su aplicación en la práctica. El programador y escritor Joel Spolsky también señaló en uno de The StackOverflow Podcast que la metodología SOLID es demasiado utópica y obliga a los desarrolladores a dedicar tiempo a código redundante, de hecho, por el simple hecho de hacerlo.
Él cree que no es necesario intentar de antemano tener en cuenta todos los escenarios posibles y simplemente programar, corrigiendo gradualmente las deficiencias, y no depender de un "sistema de seguridad" imaginario. Spolsky no niega la importancia de los principios, pero los llama excesivos.
Hay una opinionque el código SOLID es débilmente coherente y fácil de probar pero muy difícil de entender (la crítica usa la palabra "ininteligible"). El programador tiene que escribir muchas interfaces detalladas y clases pequeñas que distraen más y confunden más que ayudar a configurar un sistema. Esta afirmación es compartida por muchos que creen que centrarse en la simplicidad del código es suficiente para que otros desarrolladores lo admitan.
Foto - Kevin Canlas - Temas de Unsplash
Hacker News hablany que la elección de la arquitectura, la pila tecnológica y la gestión de la dependencia del proyecto es mucho más importante, y no los principios fundamentales sobre los que se basa su redacción. Aquí nuevamente señalan la complejidad innecesaria de comenzar con un diseño de sistema integrado, señalando ya el principio YAGNI o " No lo vas a necesitar ". Hasta cierto punto, este es otro remix del enfoque clásico de KISS .
Tenemos que admitir que hay muchas declaraciones en defensa de SOLID. Entonces, uno de los residentes de HN dice que seguir estos principios ayudará a reemplazar rápidamente la biblioteca condicional si algo sale mal en el nivel de abstracción. Bastará con asegurarte de que se están ejecutando las pruebas para la nueva implementación, y eso es todo, lo máximo es verificar adicionalmente las dependencias de la versión anterior de la clase y, si es necesario, utilizar la modificada para que las pruebas pasen con éxito. Entonces no habrá "complejidad innecesaria" en el código, y quienes lo abordarán más adelante no enfrentarán el llamado síndrome de rechazo del desarrollo ajeno .
Es importante recordar que los principios SOLID son solo pautas, no reglas estrictas. Y siempre habrá casos en los que es mejor ceñirse a ellos y cuándo retirarse.
1cloud.ru:
— HTTP-
,
UTF-8
: