Qualunque modello di progettazione OOP che sia in qualche modo rappresentativo di tutti i principi di progettazione SOLID OOP in gioco?

Uno dei pattern di progettazione più popolari tra la community qui è il schema di strategia . E sì, se costruisci un codice di esempio attorno a questo modello, puoi dimostrare tutti i principi SOLID :

• S = è soddisfatto quando ogni sottoclasse di strategia è responsabile solo di un compito, e la classe "contesto" non assume responsabilità che appartengono alle classi di strategia
• O = puoi aggiungere nuove strategie in seguito ("apri per estensioni") senza la necessità di modificare le parti interne del contesto ("chiuso per le modifiche")
• L = questo significa implementare correttamente le sottoclassi della strategia con la semantica definita dall'interfaccia della strategia, non cambiando la semantica in nessuna delle sottoclassi. LSP non verrebbe soddisfatto quando una sottoclasse implementa l'interfaccia della strategia in un modo che interrompe le parti del contesto utilizzando la strategia.
• I = è soddisfatto quando la classe base della strategia offre solo una piccola interfaccia single-purpose (come il metodo "execute")
• D = il contesto si basa completamente sull'interfaccia di strategia astratta, ottiene la strategia concreta "iniettata" dall'esterno (ad esempio, in fase di costruzione) e non fa ipotesi su, ad esempio, un insieme fisso di sottoclassi, o la disponibilità di sottoclassi specifiche.

Si noti che il pattern stesso non garantisce che il proprio codice sia SOLIDO, è più che i principi SOLID vi aiutano a implementare correttamente il pattern. Puoi considerare di mostrare ai tuoi studenti non solo esempi corretti per applicare i principi SOLID, ma anche contro-esempi nel contesto di un modello di strategia, mostrando codice che rompe ciascuno dei cinque principi. O ancora meglio: rendi questo un esercizio per loro.

Principi SOLID: è un acronimo di cinque principi.

+---------+------------+---------------------------------+
| Initial | Stands for |            Full form            |
+---------+------------+---------------------------------+
| S       | SRP        | Single responsibility principle |
| O       | OCP        | Open/closed principle           |
| L       | LSP        | Liskov substitution principle   |
| I       | ISP        | Interface segregation principle |
| D       | DIP        | Dependency inversion principle  |
+---------+------------+---------------------------------+

Principio di responsabilità singola: una classe dovrebbe avere un'unica responsabilità.

• Analogia: lavoro come team leader per una delle aziende di software in India. Nel mio tempo libero faccio alcuni scritti, editing di giornali e altri vari progetti. Fondamentalmente, ho più responsabilità nella mia vita.

  Quando succede qualcosa di brutto sul mio posto di lavoro, come quando il mio capo mi rimprovera per qualche errore, mi distrao dal mio altro lavoro. Fondamentalmente, se una cosa va male, tutto si rovinerà.

Apri principio di chiusura: le entità software (classi, moduli, funzioni, ecc.) dovrebbero essere aperte per l'estensione, ma chiuse per la modifica.

• Analogia: Supponiamo che tu voglia aggiungere un altro piano tra il primo e il secondo piano della tua casa a due piani. Pensi che sia possibile? Sì lo è, ma è fattibile? Ecco alcune opzioni:

  • Una cosa che avresti potuto fare al momento della costruzione della casa la prima volta è stata la realizzazione di tre piani, mantenendo il secondo piano vuoto. Quindi utilizza il secondo piano ogni volta che vuoi. Non so quanto sia fattibile, ma è una soluzione.
  • Interrompe l'attuale secondo piano e costruisci due nuovi piani, il che non è ragionevole.

Principio di sostituzione di Liskov: i sottotipi devono essere sostituibili ai loro tipi di base. Nota : S è già occupato in SOLID, quindi pre-fissato dal nome dell'autore Liskov.

• Analogy: Ostrich è un uccello (sicuramente lo è!) e quindi eredita la classe Bird. Ora, può volare? No! Qui, il design viola l'LSP.

  Quindi, anche se nel mondo reale questo sembra naturale, nel disegno di classe, Ostrich non dovrebbe ereditare la classe Bird, e ci dovrebbe essere una classe separata per gli uccelli che non possono realmente volare e Ostrich dovrebbe ereditarlo.

Principio di segregazione dell'interfaccia: i client non dovrebbero essere forzati ad implementare interfacce che non usano.

• Analogia: immagina una situazione in cui il negoziante inizia a mostrarti anche la palla e i ceppi. Potrebbe essere possibile che ci sentiremo confusi e finiremo per comprare qualcosa che non abbiamo richiesto. Potremmo persino dimenticare perché eravamo lì in primo luogo.

Principio di inversione delle dipendenze: i moduli di alto livello non dovrebbero dipendere da moduli di basso livello. Piuttosto, entrambi dovrebbero dipendere dalle astrazioni.

• Analogia: Parliamo dei nostri computer desktop. Parti diverse come RAM, un disco rigido e un CD-ROM (ecc.) Sono collegate in modo lasco alla scheda madre. Ciò significa che, se in futuro in qualsiasi parte smette di funzionare, può essere facilmente sostituito con uno nuovo. Immagina solo una situazione in cui tutte le parti fossero strettamente accoppiate tra loro, il che significa che non sarebbe possibile rimuovere alcuna parte dalla scheda madre. In quel caso, se la RAM smette di funzionare, dobbiamo acquistare una nuova scheda madre che sarà molto costosa.

source1 source2