Spesso incontro sviluppatori che non hanno mai sentito parlare dei principi SOLID (ne abbiamo parlato dettagliatamente qui) o della programmazione orientata agli oggetti (OOP), oppure ne hanno sentito parlare ma non li applicano 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 meno, quindi l'articolo sarà utile sia ai principianti che ai programmatori più esperti. «Sviluppatore Java»
Ricordiamo: DRY (Non Ripeterti)
Skillbox consiglia: Corso online educativo .
Se nel codice ci sono due segmenti ripetitivi, vale la pena unirli in un unico metodo. Se un valore fisso viene utilizzato più di una volta, è consigliabile trasformarlo in una costante pubblica.
Un principio piuttosto semplice, il cui significato è chiaro dal nome: "Non ripeterti". Per un programmatore, ciò implica la necessità di evitare il codice duplicato e la possibilità di utilizzare l'astrazione nel lavoro.
Se ci sono due sezioni ripetute nel codice, è consigliabile unirle in un unico metodo. Se un valore hardcoded viene usato più di una volta, è opportuno trasformarlo in una costante pubblica.
Questo serve a semplificare il codice e rendere più semplice il suo supporto, che è l'obiettivo principale della OOP. Tuttavia, non è opportuno abusare delle unioni, poiché lo stesso codice non supererà la verifica sia con OrderId che con SSN.
Incapsulamento delle modifiche
I prodotti software della maggior parte delle aziende sono in continua evoluzione. Ciò significa che è necessario apportare modifiche al codice e mantenerlo. È possibile semplificarsi la vita grazie all'incapsulamento. Questo permetterà di testare e mantenere più efficacemente l'attuale base di codice. .
Se stai scrivendo in Java, .
Principio di apertura/chiusura
Questo principio può essere facilmente memorizzato leggendo la seguente affermazione: «Le entità software (classi, moduli, funzioni, ecc.) devono essere aperte all'estensione, ma chiuse alla modifica». In pratica, ciò significa che possono consentire di cambiare il loro comportamento senza modificare il codice sorgente.
Il principio è importante quando le modifiche al codice sorgente richiedono una revisione, test modulari e altre procedure. Il codice che rispetta il principio di apertura/chiusura non viene modificato durante l'estensione, quindi presenta molte meno problematiche.
Ecco un esempio di codice che viola questo principio.
Se dovesse essere necessario apportare delle modifiche, ci vorrà molto tempo, poiché sarà necessario modificare tutte le parti del codice collegate al frammento in questione.
A proposito, l'apertura e la chiusura sono uno dei principi SOLID.
Principio di responsabilità singola (SRP)
Un altro principio del set SOLID. Esso afferma che «esiste una sola causa che porta alla modifica di una classe». Una classe risolve un solo compito. Può avere più metodi, ma ciascuno di essi è utilizzato solo per risolvere il compito generale. Tutti i metodi e le proprietà devono servire soltanto a questo.
Il valore di questo principio è che riduce il legame tra i singoli componenti del software e il codice. Aggiungere più di una funzionalità a una classe crea una dipendenza tra due funzioni. Pertanto, se si modifica una di esse, c'è un'alta probabilità di danneggiare la seconda, che è legata alla prima. Ciò comporta un aumento dei cicli di test per identificare in anticipo tutti i problemi.
Principio di inversione delle dipendenze (DIP)
Qui sopra è fornito un esempio di codice in cui AppManager dipende da EventLogWriter, il quale a sua volta è strettamente connesso a AppManager. Se è necessario un modo diverso per mostrare una notifica, sia essa push, SMS o 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 singoli moduli con altri, modificando il modulo di dipendenza. Ciò consente di cambiare un modulo senza influenzare gli altri.
Composizione invece di ereditarietà
Ci sono due principali modi per riutilizzare il codice: eredità e composizione, ciascuno con i propri vantaggi e svantaggi. Di solito, si predilige quest'ultima, poiché è più flessibile.
La composizione consente di modificare il comportamento di una classe a runtime impostando le sue proprietà. Si utilizza il polimorfismo nell'implementazione delle interfacce, che fornisce un'implementazione più flessibile.
Anche "Effective Java" di Joshua Bloch consiglia di preferire la composizione all'eredità.
Principio di sostituzione di Barbara Liskov (LSP)
Un altro principio dell'insieme SOLID. Stabilisce che i sottotipi devono essere sostituibili per il supertipo. Ciò significa che i metodi e le funzioni che operano con la superclasse dovrebbero funzionare 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à rispetto alla sottoclasse, quest'ultima non supporterà alcune funzioni, violando così questo principio.
Ecco un pezzo di codice che contraddice l'LSP.
Il metodo area(Rectangle r) calcola l'area del rettangolo. Il programma genererà un errore dopo l'esecuzione di Square, poiché Square non è un Rectangle. Secondo il principio LSP, le funzioni che utilizzano riferimenti a classi base devono poter utilizzare anche oggetti di classi derivate senza ulteriori istruzioni.
Questo principio, che è una definizione specifica di sottotipo, è stato proposto da Barbara Liskov nel 1987 in un intervento principale intitolato "Astrazione dei dati e gerarchia" — da qui il suo nome.
Principio di separazione delle interfacce (ISP)
Un altro principio SOLID. Secondo questo, un'interfaccia non utilizzata non dovrebbe essere implementata. Seguire questo principio aiuta il sistema a rimanere flessibile e idoneo a essere rifattorizzato quando vengono apportate modifiche alla logica operativa.
Questa situazione si verifica più comunemente quando l'interfaccia contiene più funzionalità, ma il cliente necessita solo di una di esse.
Poiché scrivere un'interfaccia è un compito complesso, modificarla in seguito con successo dopo il completamento sarà problematico.
Il vantaggio del principio ISP in Java è che è necessario implementare prima tutti i metodi, per poi poterli usare nelle classi. Questo principio consente quindi di ridurre il numero di metodi.
Programmare per l'interfaccia, non per l'implementazione
Qui tutto è chiaro dal nome. L'applicazione di questo principio porta alla creazione di un codice flessibile, in grado di lavorare con qualsiasi nuova implementazione dell'interfaccia.
Si dovrebbe utilizzare il tipo interfaccia per le variabili, i tipi di ritorno o il tipo dell'argomento del metodo. Esempio: usare SuperClass piuttosto che SubClass.
Cioè:
List numbers = getNumbers();
E non:
ArrayList numbers = getNumbers();
Ecco una realizzazione pratica di quanto sopra.
Il 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 appropriata anziché al cliente.
Il vantaggio del principio è l'assenza di duplicazione del codice e la relativa facilità di modifica del comportamento. Inoltre, è applicabile alla delega degli eventi.
Tutti questi principi consentono di scrivere codice più flessibile, elegante e affidabile, con alta coesione e bassa accoppiatura. Certo, la teoria è importante, ma per un programmatore è fondamentale mettere in pratica le conoscenze acquisite. Il passo successivo dopo aver appreso i principi della OOP può essere lo studio dei design pattern per affrontare problemi comuni nello sviluppo software.
Skillbox consiglia:
- Corso pratico .
- Corso online applicativo .
- Corso pratico di due anni .
Fonte: habr.com
