Incontro spesso sviluppatori che non hanno sentito parlare dei principi SOLID (noi . — Nota dell'autore) o di programmazione orientata agli oggetti (OOP), oppure ne hanno sentito parlare ma non li utilizzano nella pratica. In questo articolo vengono descritti i vantaggi dei principi OOP che aiutano gli sviluppatori nel loro lavoro quotidiano. Alcuni di essi sono ben noti, altri non molto, quindi l'articolo sarà utile sia ai principianti che ai programmatori già esperti.
Ricordiamo: per tutti i lettori di «Хабра» — sconto di 10.000 rubli per l'iscrizione a qualsiasi corso Skillbox utilizzando il codice promozionale «Хабр».
Skillbox consiglia: Corso online educativo .
DRY (Don’t Repeat Yourself)
Un principio abbastanza semplice, la cui essenza è chiara dal titolo: «Non ripeterti». Per un programmatore, ciò significa evitare codice duplicato e avere la possibilità di utilizzare l'astrazione nel lavoro.
Se nel codice ci sono due sezioni ripetitive, è meglio unirle in un unico metodo. Se un valore fissato viene utilizzato più di una volta, è consigliabile trasformarlo in una costante pubblica.
Questo serve a semplificare il codice e a rendere più facile il suo supporto, che è l'obiettivo principale dell'OOP. Non si dovrebbe abusare dell'unione, poiché lo stesso codice non passerà la validazione sia per OrderId che per SSN.
Incapsulamento delle modifiche
I prodotti software della maggior parte delle aziende sono in continua evoluzione. Ciò significa che è necessario apportare modifiche al codice, mantenerlo. Puoi semplificarti la vita attraverso l'incapsulamento. Questo permetterà di testare e mantenere la base di codice esistente in modo più efficiente. .
Se stai scrivendo in Java, .
Principio di apertura/chiusura
Questo principio può essere facilmente ricordato leggendo la seguente affermazione: «Le entità software (classi, moduli, funzioni ecc.) devono essere aperte per l'estensione, ma chiuse per la modifica». Nella pratica ciò significa che possono consentire di modificare il loro comportamento senza alterare il codice sorgente.
Il principio è importante quando le modifiche al codice sorgente richiedono una revisione, test modulare e altre procedure. Il codice che segue il principio di apertura/chiusura non cambia durante l'estensione, quindi ci sono molti meno problemi con esso.
Ecco un esempio di codice che viola questo principio.
Se è necessario apportare modifiche, richiederà molto tempo, poiché dovranno essere modificati tutte le parti di codice che hanno una connessione con il frammento necessario.
Tra l'altro, apertura-chiusura è uno dei principi SOLID.
Principio della responsabilità unica (SRP)
Un altro principio del set SOLID. Esso afferma che "esiste solo una ragione per modificare una classe". Una classe si occupa solo di un compito. Può avere diversi metodi, ma ognuno di essi è utilizzato solo per risolvere un compito comune. Tutti i metodi e le proprietà devono servire solo a questo.
Il valore di questo principio sta nel fatto che riduce il legame tra un singolo componente software e il codice. Se si aggiunge più di una funzionalità a una classe, questo introduce una connessione tra due funzioni. Pertanto, se si modifica una di esse, c'è un grande rischio di rovinare la seconda, collegata alla prima. E questo significa un aumento dei cicli di test per identificare in anticipo tutti i problemi.
Principio dell'inversione delle dipendenze (DIP)
Qui sopra è un esempio di codice in cui AppManager dipende da EventLogWriter, che, a sua volta, è strettamente legato ad AppManager. Se è necessario un modo diverso per visualizzare una notifica, che sia una push, un SMS o un'email, è necessario modificare la classe AppManager.
Il problema può essere risolto utilizzando il DIP. Così, invece di AppManager, richiediamo EventLogWriter, che sarà introdotto tramite il framework.
Il DIP consente di sostituire facilmente moduli singoli con altri, modificando il modulo di dipendenza. Ciò consente di modificare un modulo senza influenzare gli altri.
Composizione invece di ereditarietà
Esistono due modalità principali di riutilizzo del codice: ereditarietà e composizione, ognuna delle quali ha i propri vantaggi e svantaggi. Di solito si preferisce la seconda, poiché è più flessibile.
La composizione consente di modificare il comportamento di una classe durante l'esecuzione impostando le sue proprietà. Quando si implementano interfacce si utilizza il polimorfismo, che offre un'implementazione più flessibile.
Anche "Effective Java" di Joshua Bloch consiglia di privilegiare la composizione rispetto all'ereditarietà.
Principio di sostituzione di Barbara Liskov (LSP)
Un altro principio della cassetta degli attrezzi SOLID. Esso afferma che i sottotipi devono essere sostituibili per il supertípo. In altre parole, i metodi e le funzioni che lavorano con la superclasse devono poter lavorare senza problemi anche con le sue sottoclassi.
LSP è correlato sia al principio di responsabilità unica che al principio di separazione delle responsabilità. Se una classe fornisce più funzionalità della sottoclasse, quest'ultima non supporterà alcune funzioni, violando questo principio.
Ecco un pezzo di codice che contraddice LSP.
Il metodo area(Rectangle r) calcola l'area di un Rectangle. Il programma andrà in errore dopo l'esecuzione di Square, poiché Square non è un Rectangle in questo contesto. Secondo il principio LSP, le funzioni che utilizzano riferimenti a classi base devono poter utilizzare anche oggetti delle classi derivate senza istruzioni aggiuntive.
Questo principio, che è una definizione specifica di sottotipo, è stato proposto da Barbara Liskov nel 1987 durante una conferenza, in un intervento principale intitolato "Astrattismo dei dati e gerarchia" — da qui il suo nome.
Principio di separazione delle interfacce (ISP)
Un altro principio SOLID. Secondo questo, un'interfaccia che non viene utilizzata non dovrebbe essere implementata. Seguire questo principio aiuta il sistema a rimanere flessibile e adatto al refactoring quando si apportano modifiche alla logica operativa.
Questa situazione si verifica più spesso quando l'interfaccia contiene più funzionalità, e il cliente ha bisogno solo di una di esse.
Poiché scrivere un'interfaccia è un compito complesso, modificarla dopo il completamento del lavoro senza violare nulla sarà problematico.
Il vantaggio del principio ISP in Java è che prima è necessario implementare tutti i metodi, e solo dopo possono essere utilizzati dalle classi. Pertanto, il principio consente di ridurre il numero di metodi.
Programmazione per interfaccia, non per implementazione
Qui è tutto chiaro dal nome. Applicare questo principio porta alla creazione di codice flessibile, in grado di lavorare con qualsiasi nuova implementazione dell'interfaccia.
È consigliabile utilizzare il tipo interfaccia per variabili, tipi di ritorno o tipo di argomento del metodo. Esempio: utilizzare SuperClass invece di SubClass.
Cioè:
List numbers = getNumbers();
Non:
ArrayList numbers = getNumbers();
Ecco un'implementazione pratica di quanto detto sopra.
Il principio di delega
Un esempio comune è rappresentato dai metodi equals() e hashCode() in Java. Quando è necessario confrontare due oggetti, tale operazione viene delegata alla classe corrispondente anziché al cliente.
Il vantaggio di questo principio è l'assenza di duplicazione del codice e la relativa facilità di modifica del comportamento. Si applica anche alla delega di eventi.
Tutti questi principi consentono di scrivere codice più flessibile, bello e affidabile, con alta coesione e basso accoppiamento. Certamente, la teoria è utile, ma affinché uno sviluppatore utilizzi realmente le conoscenze acquisite, è necessaria la pratica. Il passo successivo dopo aver appreso i principi della POO potrebbe essere lo studio dei modelli di design per risolvere problemi comuni nello sviluppo software.
Skillbox consiglia:
- Corso pratico .
- Corso online pratico .
- Corso pratico di due anni .
Fonte: habr.com
