Questo è più un problema di OOD e non ho codice specifico per postare qui. La stessa classe può violare l'SRP in un contesto ed essere compatibile con SRP in altri senza modificare una singola riga di codice?
In altre parole, può esserci una situazione che all'interno dei framework dei precedenti requisiti la classe è conforme a SRP e quindi, quando i requisiti cambiano, non è più conforme.
Buona domanda.
In primo luogo, il facile: diversi contesti, come nella singola responsabilità di una classe, o di un metodo, o di un componente, o microservizio, o cosa-hai-te. In questi termini, l'SRP è chiaramente dipendente dal contesto, anche se stai parlando di diverse unità in ogni contesto.
La tua domanda di riparare l'unità mentre cambi il contesto è più interessante, naturalmente.
Tuttavia, non riesco a vedere un modo in cui l'SRP viene violato da quello. La stessa responsabilità cambierà sicuramente. Ad esempio, una classe potrebbe essere un DTO-POJO per un framework e quindi cambiare quadro e deve essere un'entità JPA o qualcosa del genere. Ha comunque una sola responsabilità e avresti cambiato il codice.
Avere una differenza di conformità SRP senza modificare il codice, tuttavia, richiederebbe che la responsabilità fosse direttamente dipendente dal requisito. Tuttavia, questo ancora non dovrebbe portare ad un problema di conformità al cambiamento. Quando ci pensi, il vecchio requisito è strettamente associato alla responsabilità della tua unità, quindi cambiare il requisito significa che anche il tuo codice deve essere cambiato o non soddisferà più il nuovo requisito. Dato che il tuo codice è semplice e semplicemente sbagliato in quel momento, discutere del merito della sua conformità SRP diventa una specie di vuoto.
In breve: apportare modifiche a quadri / requisiti è altamente probabile che svuoti la necessità della tua responsabilità, ma l'unità invariata ha ancora la sua unica responsabilità. Tuttavia, tale responsabilità non può più essere ritenuta corretta o necessaria.
Pensiamoci ... è un esercizio mentale che si piega al cervello. Se il cambiamento di contesto implica un cambiamento nel livello di astrazione ...
Se nel contesto A abbiamo un livello superiore di astrazione, il che significa che la classe modella la realtà in un modo più grossolano e poi cambiamo al contesto B (perché i requisiti sono cambiati) in cui il livello di astrazione è più a grana fine, allora potrebbe esserci una situazione in cui abbiamo bisogno di più classi, perché devono essere affrontate nuove responsabilità. Sarebbe violare SRP se codifichiamo le nuove responsabilità nella classe, altrimenti è impossibile tale violazione perché non è stato aggiunto alcun codice.
Quindi, in pratica, se una tale situazione sembra accadere, significa solo che la classe non soddisfa i nuovi requisiti, o la classe stava già facendo troppo per cominciare . Perché la classe abbia più responsabilità di prima, deve esserci aggiunta di codice. Quindi penso che non sia possibile .
Uno degli scopi principali di OOP è semplificare il riutilizzo del codice. Ciò significa che una classe può essere parte di una libreria utilizzata in più di un progetto o contesto, e non sto nemmeno parlando di librerie di terze parti (sarebbe la scusa perfetta), potrebbe essere una libreria il cui codice sorgente controlli ma questo è usato in diversi progetti. Quindi, per rendere l'intera cosa più simile al paradosso del gatto di Schrödinger, se SRP fosse dipendente dal contesto, la classe violerebbe simultaneamente e non violando SRP.
Se una classe viola l'SRP nel contesto A, la solita soluzione è dividerlo in unità più piccole. E se puoi farlo (senza buttare via alcuna funzionalità esistente), puoi riutilizzare le unità anche in un contesto diverso B. Ma se la classe originale non formattata non avrebbe violato l'SRP già nel contesto B, l'uso della divisione le unità nel contesto B non sarebbero né possibili, o almeno non avrebbero molto senso. Tuttavia, se quelle unità avevano senso nel contesto A, non vedo come esse non possano avere senso nel contesto B. Quindi la mia opinione è semplicemente no .
Naturalmente, potrebbero esserci casi limite in cui il posizionamento di una determinata funzione in una classe è una violazione dell'SRP, ma questo può essere tollerato nel contesto A come una soluzione pragmatica, perché non c'è altro buon posto per quella funzione all'interno di A. Tuttavia, nel contesto B potrebbe esserci un posto migliore per la funzione in una classe diversa, quindi si potrebbe dire che in B la violazione dell'SRP è più grave. Ma non penso che questo influenzi la nozione generale di SRP che sta in una proprietà che è in gran parte indipendente dal contesto.
Sì, oh sì.
La responsabilità non è ciò che puoi fare. È ciò che ti viene affidato.
Posso rispondere alle domande e posso fare un fantastico brindisi francese. Questi potrebbero tutti cadere sotto la responsabilità di essere un ospite divertente. Ma dal momento che nessuno qui conta su di me facendo toast francesi non è una delle mie responsabilità qui.
Un altro esempio basato su codice potrebbe essere una classe nome completo. Questo oggetto valore contiene ed espone un nome, un secondo e un cognome. Tutti sono necessari per assemblare il nome completo. Questa è una sola responsabilità finché esiste un codice che si basa su questi campi. Rilascia questo codice in codice che funziona solo con i cognomi e all'improvviso sta facendo molto.
Allo stesso modo se quella classe nome completo è stata rilasciata in una base di codice in cui un pacchetto ha usato il cognome e un altro ha usato il nome, quindi ancora una volta questa classe nome completo ha troppe responsabilità.
Una singola responsabilità significa avere una sola ragione per cambiare. Ciò non significa che un oggetto non possa soddisfare i bisogni di molti sistemi. Può. Significa che se quei sistemi non sono d'accordo sui loro bisogni hanno bisogno di usare oggetti diversi. L'oggetto dovrebbe essere in grado di ignorare i cui bisogni è soddisfacente. Non dovrebbe avere più facce che si rivolgono a chi ne ha bisogno.
Leggi altre domande sui tag object-oriented single-responsibility