Stavo cercando di capire la differenza tra Open Closed Principle (OCP) e Dependency Inversion Princible (DIP).
Sulla base di ricerche che ho fatto finora su Internet, sono giunto alla conclusione che "il DIP è un'opzione attraverso la quale possiamo ottenere OCP".
Ho ragione su questo?
Puoi darmi un esempio che non segue il DIP ma segue l'OCP?
Ho scritto una risposta in precedenza su Principio Open-Closed (OCP) vs Principio di sostituzione di Liskov (LSP) e entrambi questi principi si relazionano l'un l'altro molto, ma sono ancora concettualmente diversi con alcuni esempi inventati di avere uno ma non l'altro. A causa di questa risposta, toccherò brevemente l'OCP e approfondirò in DIP e ciò che rende quel segno di spunta.
Proviamo a discutere su come OCP si collega e si differenzia con il principio di inversione delle dipendenze (DIP) spiegando prima i diversi principi.
Leggendo Principi di OOD dello zio Bob scoprirai che DIP afferma quanto segue:
Depend on abstractions, not on concretions.
Un'astrazione in Java viene semplicemente raggiunta con interface e abstract parole chiave, il che significa che hai un "contratto" per alcune entità software che il codice deve seguire. Alcuni linguaggi di programmazione non hanno la possibilità di impostare in modo esplicito comportamenti da seguire per il codice, quindi le astrazioni devono essere seguite in modo più manuale piuttosto che avere il compilatore che aiuti a far rispettare il contratto. Per esempio. in C ++ hai classi con metodi virtuali, e linguaggi di programmazione dinamici come Javascript devi assicurarti di usare gli oggetti allo stesso modo (anche se nel caso di Javascript questo è stato esteso in TypeScript che aggiunge un sistema di tipi per aiutarti con scrivere contratti che sono verificati dal compilatore).
Il nome include il termine "inversione" perché tradizionalmente (sai nelle vecchie età buie della programmazione) hai scritto strutture software che avevano moduli di livello superiore a seconda dei moduli di basso livello. Per esempio. aveva senso avere un ButtonAtKitchen di gestione degli input per un KitchenLamp1 e KitchenLamp2 . Sfortunatamente questo ha reso il software molto più specifico di quello che doveva essere e il grafico dell'oggetto sarebbe stato il seguente:
Quindiquandorendiilsoftwarepiùgenerale,aggiungendo"contratti". Notare come le frecce nel grafico dell'oggetto "inverte" la direzione. Le lampade da cucina ora dipendono da un Button . In altre parole, i dettagli dipendono ora dalle astrazioni invece che dall'altra parte.
QuindiabbiamounadefinizionepiùgeneralediDIP,anchedescrittain
A. High level modules should not depend on low level modules. Both should depend on abstraction. B. Abstractions should not depend upon details. Details should depend on abstractions.
Seguito dai principi dello zio Bob, scoprirai che l'OCP afferma quanto segue:
You should be able to extend a classes behavior, without modifying it.
Un esempio di come raggiungere questo obiettivo è utilizzare il modello di strategia dove una classe Context è chiusa per modifiche (cioè non è possibile modificare il suo codice interno) ma è anche aperto per l'estensione attraverso le sue dipendenze collaborative (cioè le classi di strategia).
In un senso più generale qualsiasi modulo è costruito per essere estensibile attraverso i suoi punti di estensione.
No,nonproprio.
Sebbeneentrambistianodiscutendodiastrazioni,sonoconcettualmentediversi.Entrambiiprincipiesaminanodiversicontesti,OCPsuunparticolaremoduloeDIPsudiversimoduli.PuoiottenereentrambiallostessotempodellamaggiorpartedeimodellididesignGangofFour,mapuoicomunqueallontanartidalpercorso.
Nell'esempioDIPdicuisopra,conilpulsanteelelampadedacucina,nessunadellelampadedacucinaèestensibile(néalmomentohaalcunrequisitochespieghichedevonoessere).Ildesignèinterromperel'OCPmasegueDIP.
Unesempioinverso(eforzato)sarebbeunalampadadacucinaessereestensibile(conilpuntodiestensionecheèqualcosacomeLampShade)mailpulsantedipendeancoradallelampade.ÈrompereDIPmasegueOCP.
Questoèinrealtàqualcosachevedraiaccaderespessonelcodicediproduzione,chepartediessopotrebbeinfrangereunprincipio.Neisistemisoftwarepiùgrandi(valeadirequalsiasicosapiùgrandedegliesempiprecedenti),sipotrebberompereunprincipiomamantenerel'altrodisolitoperchéènecessariomantenereilcodicesemplice.Questo,amioavviso,vabeneperimodulipiccolieautonomi,poichésononelcontestorelativoalPrincipiodiResponsabilitàUnica(SRP).
Unavoltachealcunimodulidiventanocomplicatianchesemoltoprobabilmentehaibisognodiguardarlicontuttiiprincipiinmenteeriprogettazioneo
Leggi altre domande sui tag object-oriented design-patterns object-oriented-design solid