¿Hay alguna herramienta de análisis estático que informe qué tan cerca se siguen los principios SÓLIDOS?

Question

Sé que seguir ciegamente cualquier "buena práctica" puede conducir a una apestosa pila de basura que se adhiere estrictamente a la mejor práctica. Los principios SÓLIDOS son simplemente eso, principios. No se aplican a todas las situaciones, pero siguen siendo muy buenas heurísticas para encontrar posibles mejoras en su código.

La desventaja de ellos es que en algún momento requieren un análisis profundo de su código fuente para aplicarlos. Yo, como la mayoría de los programadores, estoy constantemente buscando formas más eficientes de hacer las cosas, así que tengo curiosidad si alguien ha oído hablar de una herramienta de análisis que intenta probar la aplicación de los principios SÓLIDOS (o la falta de ellos).

SRPLa Responsabilidad Individual Principio

Una clase debe tener una sola razón para cambio.

OCPEl abierto-cerrado Principio

entidades de software (clases, módulos, funciones, etc.) deben estar abiertas para extensión, pero cerrado para modificación.

LSPla sustitución Liskov Principio

subtipos debe ser sustituibles por sus tipos base.

ISPLa interfaz Segregación Principio

Los clientes no deben ser forzados a depender en métodos que no utilizan. Las interfaces pertenecen a los clientes, no a las jerarquías .

DIPEl Dependencia Inversión Principio

abstracciones no deben depender de detalles. Los detalles deben depender de abstracciones .

-Desde principios ágiles, patrones y prácticas

Answer 1

No creo que el análisis estático automático puede determinar si se respetan los principios. Para escribir una herramienta de este tipo, necesitaría definir formalmente lo que significa cada concepto y tener una forma de verificarlo contra cualquier código. ¿Cómo formalizarías la noción de una responsabilidad? Personalmente no tengo idea.

Dicho esto, puede tener herramientas para ayudarlo a detectar la verosimilitud de la infracción. Por ejemplo, podría usar métricas de código como el número de métodos por clase, número de miembros por clase para determinar si una clase es demasiado grande y, por lo tanto, es probable que viole SRP.

Una excepción podría ser el Principio de sustitución Liskov. SI define los contratos en todos los métodos (precondiciones, condiciones posteriores, invariantes) luego puede verificar que un método que redefine un método de una superclase no refuerce la condición previa, no debilite la condición posterior y respete las invariantes de el método de la superclase. Creo que la herramienta ESC/Java realiza esos controles. Al leer el wikipedia page about LSP, se deberían realizar más comprobaciones.

Answer 2

Mi respuesta implica un producto específico de .NET, disculpas de antemano, y tal vez alguien pueda sugerir sus análogos que no sean .NET.

Daría NDepend una oportunidad y ver si me puede dar lugar a las violaciónes de SRP y el ISP mediante el uso de indicadores como:

• número de métodos por tipo tipos con
• números anormalmente altos de métodos
• aferentes/eferentes de acoplamiento en el plano de montaje y tipo
• otras métricas, full list of metrics here

Las violaciones de DIP y LSP pueden ser más difíciles de rastrear porque involucran la intención del programador. Una herramienta de análisis puede identificar la relación entre los tipos, pero ¿cómo puede decirse una situación en la que una clase se extiende genuinamente a otra distinta de la derivada inapropiada de Rectángulo de Square? ¿O que en un programa diseñado adecuadamente, A debería haber dependido de B y no al revés?

OCP presenta un desafío diferente porque la extensión/modificación a la que la clase debería abrirse/cerrarse no necesariamente ya se ha llevado a cabo.

Sin embargo, si creemos que siguiendo pistas sólidas para un producto más fácil de mantener (que demuestra esta afirmación científicamente no es lo que esta pregunta se refiere), entonces la carta Abstracción-Inestabilidad de NDepend debe darle una buena agregada medida de lo bien que la se siguieron los principios para cada módulo de software. Si lo fueran, el módulo debería haber evitado la esquina inferior izquierda de la tabla, llamada "Zona de dolor". En esa zona, el módulo es estable (no en el buen sentido, muchos otros dependen de él, por lo que es difícil cambiarlo), pero no lo suficientemente abstracto.