Esistono strumenti di analisi statica che segnaleranno quanto strettamente seguano i principi SOLID?

Question

So che seguire ciecamente una "buona pratica" può ancora portare a una puzzolente pila di cagate che si attiene strettamente alle migliori pratiche. I principi SOLID sono proprio questo, principi. Non si applicano ad ogni situazione, ma sono ancora ottime euristiche per trovare possibili miglioramenti nel codice.

Il lato negativo per loro è che a volte richiedono un'analisi approfondita del codice sorgente per applicarli. Io, come la maggior parte dei programmatori, sono costantemente alla ricerca di modi più efficienti di fare le cose, quindi sono curioso di sapere se qualcuno ha sentito parlare di uno strumento di analisi che tenta di verificare l'applicazione dei principi SOLID (o la loro mancanza).

SRPLa responsabilità singolo Principio

Una classe dovrebbe avere solo una ragione per cambiamento.

OCPL'aperto-chiuso Principio

entità software (classi, moduli, funzioni, etc.) devono essere aperte per estensione, ma chiuso per modifica.

LSPIl Liskov principio di sostituzione

sottotipi deve essere sostituibili i loro tipi di base.

ISPL'interfaccia segregazione Principio

I client non dovrebbero essere costretti a dipendere su metodi che non utilizzano. Le interfacce appartengono ai client, non alle gerarchie .

DIPIl principio di inversione delle dipendenze

Abstractions non dovrebbe dipendere dettagli. I dettagli dovrebbero dipendere dalle astrazioni .

-Da Agile Principi, Patterns and Practices

Answer 1

Non credo che l'analisi statica automatica in grado di determinare se i principi siano rispettati. Per scrivere uno strumento del genere, è necessario definire formalmente cosa significhi ciascun concetto e avere un modo per controllarlo rispetto a qualsiasi codice. Come formalizzeresti la nozione di responsablità? Personalmente non ne ho idea.

Detto questo, è possibile disporre di strumenti che consentono di rilevare la probabilità di violazione. Ad esempio, è possibile utilizzare le metriche del codice come numero di metodi per classe, numero di membri per classe per determinare se una classe è troppo grande e quindi suscettibile di violare SRP.

Un'eccezione potrebbe essere il Principio di sostituzione di Liskov. IF si definiscono i contratti su tutti i metodi (precondizioni, postcondizioni, invarianti), quindi è possibile verificare che un metodo che ridefinisce un metodo di una superclasse non rafforzi la precondizione, non indebolisca la postcondizione e rispetti gli invarianti di il metodo della superclasse. Penso che lo strumento ESC/Java esegua quei controlli. Leggere gli wikipedia page about LSP devono essere eseguiti ulteriori controlli.

Answer 2

La mia risposta riguarda un prodotto specifico di .NET, ci scusiamo in anticipo e forse qualcuno può suggerire i suoi analoghi non- .NET.

Darei NDepend una prova e vedere se mi può portare a violazioni del SRP e ISP utilizzando metriche come:

• certo numero di metodi per tipi tipo con
• numero anormalmente elevato di metodi
• afferente accoppiamento/efferente a livello di assieme ed il tipo
• altre metriche, full list of metrics here

Le violazioni DIP e LSP potrebbero essere più difficili da rintracciare perché coinvolgono l'intento del programmatore. Uno strumento di analisi può identificare la relazione tra i tipi, ma come può indicare una situazione in cui una classe ne estende effettivamente un'altra derivando inappropriatamente da Rectangle? Oppure, che in un programma progettato correttamente, A avrebbe dovuto dipendere da B e non viceversa?

OCP presenta una diversa sfida poiché l'estensione/modifica che la classe deve essere aperta/chiusa potrebbe non aver già già avuto luogo.

Tuttavia, se crediamo che in seguito porta solido per un prodotto più gestibile (dimostrando questa affermazione scientificamente non è ciò che questa domanda è di circa), poi grafico astrattezza-instabilità del NDepend dovrebbe dare una buona complessivo misura di quanto bene il i principi sono stati seguiti per ciascun modulo software. Se lo fossero, il modulo avrebbe dovuto evitare l'angolo in basso a sinistra del grafico, soprannominato "The Zone of Pain". In quella zona, il modulo è stabile (non in senso buono - troppi altri dipendono da esso, quindi è difficile da modificare), ma non abbastanza astratto.