Ho sentito parlare principalmente di persone che applicano il principio a classi e metodi, ma le persone lo applicano anche a soluzioni / DLL? Ad esempio, se stavo scrivendo una libreria per analizzare i dati da UsefulProgram, e poi avevo un po 'più di codice relativo a UsefulProgram, dovrei averli in due librerie separate o solo una libreria di UsefulProgramUtilities?
Modifica: Credo che quello che sto chiedendo sia come dovrei dividere il mio codice tra le librerie.
Una DLL è un dettaglio di implementazione di un programma. SRP si concentra su unità di codice logiche:
Una classe dovrebbe modellare solo un'unità coesiva di stato o comportamento.
Un metodo dovrebbe eseguire solo un'unità di lavoro, e in genere non dovrebbe restituire entrambi e lo stato di mutamento.
Ma nessuno di questi si estende bene al livello library . Quando progetto una gerarchia di classi, non mi interessa se le classi si trovano in DLL, SO, JAR, ecc. Separati che solo l'ambiente di runtime può caricare e utilizzare la classe.
Per dirla in altro modo, l'obiettivo di SRP è garantire che un'unità di codice non sia troppo complessa. Posso creare un'istanza di un oggetto, chiamare metodi su di esso, passarlo, ecc. Ma non esiste un equivalente per una DLL. Certo, potrei chiamare LoadLibrary() per caricarlo manualmente, ma questa è l'entità di manipolare una DLL nel mio programma.
Wikipedia dice che SRP influisce su "classi o moduli", ma sarei prudente nell'applicare questo principio alle DLL. Le DLL sono in genere organizzate come parte di uno schema architettonico; SRP è uno dei SOLID Principles , applicato in modo specifico a Object-Oriented Design, non all'architettura software in generale.
La strada per programmare il nirvana è disseminata di cadaveri di programmatori che hanno tentato di applicare un principio di programmazione a situazioni dove non si applica .
Leggi altre domande sui tag design single-responsibility