Molto spesso incontro sviluppatori che non hanno sentito parlare dei principi SOLID (noi . — Transl.) o programmazione orientata agli oggetti (OOP), o ne hai sentito parlare, ma non li usi nella pratica. Questo articolo descrive i vantaggi dei principi OOP che aiutano lo sviluppatore nel suo lavoro quotidiano. Alcuni di essi sono ben noti, altri non così tanto, quindi l'articolo sarà utile sia ai principianti che ai programmatori esperti.
Ti ricordiamo: per tutti i lettori Habr: uno sconto di 10 rubli quando si iscrive a qualsiasi corso Skillbox utilizzando il codice promozionale Habr.
Skillbox consiglia: Corso didattico online .
ASCIUTTO (non ripetere te stesso)
Un principio abbastanza semplice, la cui essenza è chiara già dal nome: “Non ripeterti”. Per un programmatore, ciò significa la necessità di evitare codici duplicati, nonché l'opportunità di utilizzare l'astrazione nel proprio lavoro.
Se nel codice sono presenti due sezioni ripetute, è necessario combinarle in un unico metodo. Se un valore hardcoded viene utilizzato più di una volta, vale la pena convertirlo in una costante pubblica.
Ciò è necessario per semplificare il codice e facilitarne la manutenzione, che è l'obiettivo principale dell'OOP. Non dovresti nemmeno abusare dell'unione, poiché lo stesso codice non supererà la verifica sia con OrderId che con SSN.
Incapsulare i cambiamenti
I prodotti software della maggior parte delle aziende sono in continua evoluzione. Ciò significa che è necessario apportare modifiche al codice, deve essere supportato. Puoi semplificarti la vita usando l'incapsulamento. Ciò ti consentirà di testare e mantenere in modo più efficiente la tua codebase esistente. .
Se scrivi in Java, allora .
Principio aperto/chiuso
Questo principio può essere facilmente ricordato leggendo la seguente dichiarazione: “Le entità software (classi, moduli, funzioni, ecc.) dovrebbero essere aperte per l’estensione, ma chiuse per la modifica”. In pratica, ciò significa che possono consentire che il loro comportamento venga modificato senza modificare il codice sorgente.
Il principio è importante quando le modifiche al codice sorgente richiedono revisione del codice, test unitari e altre procedure. Il codice che segue il principio aperto/chiuso non cambia quando viene esteso, quindi ci sono molti meno problemi.
Ecco un esempio di codice che viola questo principio.
Se è necessario modificare qualcosa al suo interno, ci vorrà molto tempo, poiché tutte le sezioni del codice che hanno una connessione con il frammento desiderato dovranno essere modificate.
A proposito, l'apertura-chiusura è uno dei principi di SOLID.
Principio di responsabilità unica (SRP)
Un altro principio del set SOLID. Si afferma che “c’è una sola causa che provoca un cambiamento di classe”. La classe risolve un solo problema. Può avere diversi metodi, ma ognuno di essi viene utilizzato solo per risolvere un problema comune. Tutti i metodi e le proprietà dovrebbero servire solo a questo.
Il valore di questo principio è che allenta l'accoppiamento tra il singolo componente software e il codice. Se aggiungi più di una funzionalità a una classe, viene introdotta una relazione tra le due funzioni. Quindi, se ne cambi uno, c'è un'alta probabilità di rovinare il secondo, che è collegato al primo. E questo significa aumentare i cicli di test per identificare in anticipo tutti i problemi.
Principio di inversione delle dipendenze (DIP)
Sopra è riportato un esempio di codice in cui AppManager dipende da EventLogWriter, che a sua volta è strettamente associato ad AppManager. Se hai bisogno di un modo diverso per mostrare una notifica, sia essa push, SMS o email, devi cambiare la classe AppManager.
Il problema può essere risolto utilizzando DIP. Quindi, invece di AppManager, richiediamo un EventLogWriter, che verrà inserito utilizzando il framework.
DIP consente di sostituire facilmente singoli moduli con altri modificando il modulo di dipendenza. Ciò rende possibile modificare un modulo senza influenzare gli altri.
Composizione invece di eredità
Esistono due modi principali per riutilizzare il codice: ereditarietà e composizione, entrambi con vantaggi e svantaggi. Solitamente si preferisce la seconda perché più flessibile.
La composizione ti dà la possibilità di modificare il comportamento di una classe in fase di esecuzione impostandone le proprietà. Quando si implementano le interfacce, viene utilizzato il polimorfismo, che fornisce un'implementazione più flessibile.
Anche Effective Java di Joshua Bloch consiglia di scegliere la composizione anziché l'ereditarietà.
Principio di sostituzione di Barbara Liskov (LSP)
Un altro principio del toolkit SOLID. Afferma che i sottotipi devono essere sostituibili al supertipo. Cioè, i metodi e le funzioni che funzionano con una superclasse dovrebbero essere in grado di funzionare senza problemi con le sue sottoclassi.
LSP è associato sia al principio di responsabilità unica che al principio di responsabilità condivisa. Se una classe fornisce più funzionalità di una sottoclasse, quest'ultima non supporterà alcune funzionalità, violando questo principio.
Ecco un pezzo di codice che contraddice LSP.
Il metodo area(Rettangolo r) calcola l'area di un Rettangolo. Il programma si bloccherà dopo l'esecuzione di Square perché Square non è un Rectangle qui. Secondo il principio LSP, le funzioni che utilizzano riferimenti alle classi base dovrebbero essere in grado di utilizzare oggetti di classi derivate senza istruzioni aggiuntive.
Questo principio, che è una definizione specifica di un sottotipo, è stato proposto da Barbara Liskov in una conferenza del 1987 intitolata “Data Abstraction and Hierarchy”, da cui il nome.
Principio di separazione dell'interfaccia (ISP)
Un altro principio SOLIDO. Secondo esso un'interfaccia non utilizzata non dovrebbe essere implementata. Seguire questo principio aiuta il sistema a rimanere flessibile e adatto al refactoring quando vengono apportate modifiche alla logica operativa.
Molto spesso, questa situazione si verifica quando l'interfaccia contiene più funzioni contemporaneamente e il client ne ha bisogno solo una.
Poiché scrivere un'interfaccia è un compito difficile, modificarla una volta completato il lavoro senza rompere nulla sarà una sfida.
Il vantaggio del principio ISP in Java è che tutti i metodi devono essere prima implementati e solo dopo possono essere utilizzati dalle classi. Pertanto, il principio consente di ridurre il numero di metodi.
Programmazione per l'interfaccia, non l'implementazione
Tutto qui è chiaro dal nome. L'applicazione di questo principio porta alla creazione di un codice flessibile che può funzionare con qualsiasi nuova implementazione dell'interfaccia.
Dovresti utilizzare il tipo di interfaccia per variabili, tipi restituiti o il tipo di argomento del metodo. Un esempio utilizza SuperClass anziché SubClass.
I.e:
Numeri della lista= getNumbers();
Ma no:
Numeri ArrayList = getNumbers();
Ecco un'implementazione pratica di quanto discusso sopra.
Principio di delega
Un esempio comune sono i metodi equals() e hashCode() in Java. Quando è necessario confrontare due oggetti, questa azione viene delegata alla classe corrispondente anziché a quella client.
Il vantaggio di questo principio è che non vi è alcuna duplicazione del codice ed è relativamente semplice modificare il comportamento. Si applica anche alla delega degli eventi.
Tutti questi principi consentono di scrivere codice più flessibile, bello e affidabile con elevata coesione e basso accoppiamento. Naturalmente, la teoria è buona, ma affinché uno sviluppatore possa utilizzare effettivamente le conoscenze acquisite, è necessaria la pratica. Una volta acquisiti i principi dell'OOP, il passo successivo potrebbe essere quello di apprendere modelli di progettazione per risolvere problemi comuni di sviluppo software.
Skillbox consiglia:
- Corso pratico .
- Corso online applicato .
- Corso pratico di due anni .
Fonte: habr.com