Sembra non capire i principi SOLID e i modelli di progettazione

Question

Sto provando ad entrare in OOP ultimamente e ho problemi con i principi SOLID e gli schemi di progettazione. Capisco perché le persone li usano, e voglio davvero usarli anche io, ma non riesco a capire come sviluppare le mie lezioni secondo le specifiche. Gradirei davvero qualcosa che possa aiutare la mia comprensione di questo.

Answer 1

Ho frequentato un corso al college che ha trascorso due settimane in giro a disegnare disegni e ho letto il libro Gang of Four senza successo. Capire che cosa serviva ogni modello e come usarlo per adattarsi ai problemi era molto difficile per me, uno sviluppatore che non aveva molta esperienza nella programmazione OO.

Il libro che ha fatto veramente clic per me era Head First Design Patterns. Inizia mostrando un problema, approcci diversi che gli sviluppatori hanno preso in considerazione, e poi come hanno finito con l'utilizzare un modello di progettazione per risolverlo. Usa un linguaggio molto semplice e mantiene il libro molto coinvolgente.

design pattern finiscono per essere un modo per descrivere una soluzione, ma non ha adattare le classi alla soluzione. Pensa a loro più come una guida che suggerisce una buona soluzione per una vasta gamma di problemi. parlare

Let su SOLID:

1. responsabilità singola. Una classe dovrebbe avere una sola responsabilità. Ciò significa che, ad esempio, una classe Persona dovrebbe solo preoccuparsi del problema del dominio riguardante la persona stessa, e non, ad esempio, la sua persistenza nel database. Per questo, potresti voler usare un PersonDAO per esempio. Una classe Persona potrebbe voler mantenere le sue responsabilità il più breve possibile. Se una classe usa troppe dipendenze esterne (cioè altre classi), questo è un sintomo che la classe sta avendo troppe responsabilità. Questo problema si presenta spesso quando gli sviluppatori cercano di modellare il mondo reale usando oggetti e portandolo troppo lontano. Le applicazioni liberamente accoppiate spesso non sono molto facili da navigare e non modellano esattamente come funziona il mondo reale.
2. Aperto Chiuso. Le classi dovrebbero essere estensibili, ma non modificabili. Ciò significa che aggiungere un nuovo campo a una classe va bene, ma la modifica delle cose esistenti non lo è. Altri componenti del programma possono dipendere da detto campo.
3. sostituzione Liskov. Una classe che si aspetta un oggetto di tipo animale dovrebbe funzionare se un cane sottoclasse e un gatto sottoclasse vengono passati. Ciò significa che l'animale NON dovrebbe avere un metodo chiamato corteccia per esempio, poiché le sottoclassi di tipo cat non saranno in grado di abbaiare. Le classi che usano la classe Animale, inoltre, non dovrebbero dipendere dai metodi che appartengono a un cane di classe. Non fare cose come "Se questo animale è un cane, allora (calcola l'animale al cane) abbaia: se l'animale è un gatto allora (lancia animale a gatto) miagola".
4. Principio di separazione interfaccia. Mantieni le tue interfacce il più piccolo possibile. Un insegnante che è anche uno studente dovrebbe implementare entrambe le interfacce IStudent e ITeacher, invece di un'unica grande interfaccia chiamata IStudentAndTeacher.
5. Principio di inversione delle dipendenze. Gli oggetti non dovrebbero istanziare le loro dipendenze, ma dovrebbero essere passati a loro. Ad esempio, un'Auto che ha un oggetto Motore all'interno non dovrebbe fare engine = new DieselEngine(), ma piuttosto dovrebbe essere passato ad esso dal costruttore. In questo modo la classe dell'auto non sarà accoppiata alla classe DieselEngine.