La maggior parte dei "principi" in SOLID (che sono più simili alle linee guida nella maggior parte dei casi) sono molto dipendenti dal contesto, e non possiamo davvero vedere se sono violati dal sistema che descrivi perché non abbiamo molto contesto .
Ad esempio:
-
Non possiamo dire se hai violato il principio di responsabilità singola, perché determinare cosa è e cosa non è una responsabilità di un pezzo di codice richiede la comprensione di come viene specificato quel codice e di come tali specifiche possano cambiare in futuro. Se gestire i livelli delle scorte può cambiare indipendentemente dal modo in cui sono descritti i singoli articoli, allora raggrupparli nello stesso modulo potrebbe essere una violazione di SRP. Ma se entrambe sono conseguenze della stessa specifica (ad esempio perché si ha un unico fornitore e la descrizione è nello stesso formato fornito dal fornitore, quindi qualsiasi modifica a una è probabile che implichi anche una modifica dell'altro), allora SRP non viene violato qui.
-
La validità del Principio Aperto / Chiuso dipende strongmente da cosa sono i client di un pezzo di codice e se sono considerati parte dello stesso modulo (e quindi è probabile che evolvano insieme, vengano testati insieme, e così via) o diversi (a questo punto la stabilità fornita da OCP può diventare molto importante), quindi senza sapere come vengono effettivamente utilizzati gli oggetti del libro non possiamo stabilire se questo è violato.
-
Interfaccia La segregazione dipende ancora da cosa sono i client di un oggetto, non da ciò che fa l'oggetto stesso. Mentre la risposta di Christophe identifica una probabile violazione di questo, è solo in realtà una violazione se ci sono moduli separati nel tuo sistema che userebbero le interfacce separate che propone. Se c'è solo un singolo modulo che accede a libri o ebook, e usa sempre tutte le strutture che descrivi, non c'è violazione.
-
L'inversione di dipendenza richiede che gli oggetti dettagliati dipendano dalle astrazioni piuttosto che viceversa, ma tutti gli oggetti che descrivi hanno un livello di astrazione simile. Dovremmo vedere una descrizione molto più ampia di come il tuo sistema usa questi oggetti per sapere se il DIP è soddisfatto o meno.
Ho saltato la sostituzione di Liskov dalla lista sopra, perché la considero davvero una categoria diversa. I quattro principi sopra riportati sono linee guida progettuali utili. LSP causa quasi sempre seri problemi quando viene violato. È una regola molto meno soggettiva. Ma dipende anche dal comportamento dettagliato dei tuoi oggetti. Se il tuo oggetto ebook ha un comportamento valido per tutti i metodi inclusi negli oggetti del tuo libro, allora LSP non viene violato. Ma se un client di oggetti libro potrebbe fallire a causa degli oggetti ebook che gestiscono le scorte in modo incompatibile (ad esempio), LSP viene violato. Molto dipende da quali sono gli effetti collaterali osservabili dei vostri metodi e anche da come sono documentati come funzionanti.
Di tutti loro, penso che LSP sia il più probabile a essere violato nel sistema che descrivi, perché non riesco a vedere un modo ragionevole in cui un ebook possa implementare il metodo replenishStocks() che non potrebbe causare alcun client non è stato scritto pensando agli ebook di fallire. E come sottolinea Christophe, anche l'ISP è probabilmente violato. Gli altri, in realtà non abbiamo abbastanza informazioni per sapere.
Per inciso, i principi SOLID non contengono linee guida che hanno lo scopo di promuovere la semplicità del codice. Per le applicazioni del mondo reale, dovrebbero essere sempre utilizzati insieme a tali linee guida (e con la consapevolezza che in molti casi saranno in conflitto con loro, e che spetta a te come progettista di sistemi di elaborare quale dovrebbe avere la priorità). Le regole per il design semplice di Kent Beck sono un buon punto di partenza.
