{"id":34855,"date":"2019-10-31T22:00:51","date_gmt":"2019-10-31T19:00:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik\/"},"modified":"2019-10-31T22:00:51","modified_gmt":"2019-10-31T19:00:51","slug":"10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","title":{"rendered":"10 principi di programmazione orientata agli oggetti che ogni sviluppatore deve conoscere","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"10
\n
\nSpesso 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\u00e0 utile sia ai principianti che ai programmatori pi\u00f9 esperti. per tutti i lettori di \u00abHabr\u00bb \u2014 sconto di 10.000 rubli per l'iscrizione a qualsiasi corso Skillbox con il codice promozionale \u00abHabr\u00bb.<\/a><\/noindex>\u00abSviluppatore Java\u00bb
\n<\/a><\/noindex><\/p>\n

Ricordiamo:<\/b> DRY (Non Ripeterti)<\/i><\/p>\n

Skillbox consiglia:<\/b> Corso online educativo Un principio abbastanza semplice, la cui essenza \u00e8 chiara dal nome: \u00abNon ripeterti\u00bb. Per un programmatore questo significa evitare codice duplicato e avere la possibilit\u00e0 di utilizzare l'astrazione nel lavoro.<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

Se nel codice ci sono due segmenti ripetitivi, vale la pena unirli in un unico metodo. Se un valore fisso viene utilizzato pi\u00f9 di una volta, \u00e8 consigliabile trasformarlo in una costante pubblica.<\/h3>\n

\nUn principio piuttosto semplice, il cui significato \u00e8 chiaro dal nome: \"Non ripeterti\". Per un programmatore, ci\u00f2 implica la necessit\u00e0 di evitare il codice duplicato e la possibilit\u00e0 di utilizzare l'astrazione nel lavoro.<\/p>\n

Se ci sono due sezioni ripetute nel codice, \u00e8 consigliabile unirle in un unico metodo. Se un valore hardcoded viene usato pi\u00f9 di una volta, \u00e8 opportuno trasformarlo in una costante pubblica.<\/p>\n

Questo serve a semplificare il codice e rendere pi\u00f9 semplice il suo supporto, che \u00e8 l'obiettivo principale della OOP. Tuttavia, non \u00e8 opportuno abusare delle unioni, poich\u00e9 lo stesso codice non superer\u00e0 la verifica sia con OrderId che con SSN.<\/p>\n

Incapsulamento delle modifiche<\/h3>\n

\nI prodotti software della maggior parte delle aziende sono in continua evoluzione. Ci\u00f2 significa che \u00e8 necessario apportare modifiche al codice e mantenerlo. \u00c8 possibile semplificarsi la vita grazie all'incapsulamento. Questo permetter\u00e0 di testare e mantenere pi\u00f9 efficacemente l'attuale base di codice. Ecco un esempio<\/a><\/noindex>.<\/p>\n

Se stai scrivendo in Java, assegna per impostazione predefinita private ai metodi e alle variabili<\/a><\/noindex>.<\/p>\n

Principio di apertura\/chiusura<\/h3>\n

\nQuesto principio pu\u00f2 essere facilmente memorizzato leggendo la seguente affermazione: \u00abLe entit\u00e0 software (classi, moduli, funzioni, ecc.) devono essere aperte all'estensione, ma chiuse alla modifica\u00bb. In pratica, ci\u00f2 significa che possono consentire di cambiare il loro comportamento senza modificare il codice sorgente.<\/p>\n

Il principio \u00e8 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.<\/p>\n

Ecco un esempio di codice che viola questo principio.<\/p>\n

\"10
\n
\nSe dovesse essere necessario apportare delle modifiche, ci vorr\u00e0 molto tempo, poich\u00e9 sar\u00e0 necessario modificare tutte le parti del codice collegate al frammento in questione.<\/p>\n

A proposito, l'apertura e la chiusura sono uno dei principi SOLID.<\/p>\n

Principio di responsabilit\u00e0 singola (SRP)<\/h3>\n

\nUn altro principio del set SOLID. Esso afferma che \u00abesiste una sola causa che porta alla modifica di una classe\u00bb. Una classe risolve un solo compito. Pu\u00f2 avere pi\u00f9 metodi, ma ciascuno di essi \u00e8 utilizzato solo per risolvere il compito generale. Tutti i metodi e le propriet\u00e0 devono servire soltanto a questo. <\/p>\n

\"10
\n
\nIl valore di questo principio \u00e8 che riduce il legame tra i singoli componenti del software e il codice. Aggiungere pi\u00f9 di una funzionalit\u00e0 a una classe crea una dipendenza tra due funzioni. Pertanto, se si modifica una di esse, c'\u00e8 un'alta probabilit\u00e0 di danneggiare la seconda, che \u00e8 legata alla prima. Ci\u00f2 comporta un aumento dei cicli di test per identificare in anticipo tutti i problemi.<\/p>\n

Principio di inversione delle dipendenze (DIP)<\/h3>\n

\n\"10
\n
\nQui sopra \u00e8 fornito un esempio di codice in cui AppManager dipende da EventLogWriter, il quale a sua volta \u00e8 strettamente connesso a AppManager. Se \u00e8 necessario un modo diverso per mostrare una notifica, sia essa push, SMS o email, \u00e8 necessario modificare la classe AppManager.<\/p>\n

Il problema pu\u00f2 essere risolto utilizzando il DIP. Cos\u00ec, invece di AppManager, richiediamo EventLogWriter, che sar\u00e0 introdotto tramite il framework.<\/p>\n

Il DIP consente di sostituire facilmente singoli moduli con altri, modificando il modulo di dipendenza. Ci\u00f2 consente di cambiare un modulo senza influenzare gli altri.<\/p>\n

Composizione invece di ereditariet\u00e0<\/h3>\n

\n\"10Ci sono due principali modi per riutilizzare il codice: eredit\u00e0 e composizione, ciascuno con i propri vantaggi e svantaggi. Di solito, si predilige quest'ultima, poich\u00e9 \u00e8 pi\u00f9 flessibile.<\/p>\n

La composizione consente di modificare il comportamento di una classe a runtime impostando le sue propriet\u00e0. Si utilizza il polimorfismo nell'implementazione delle interfacce, che fornisce un'implementazione pi\u00f9 flessibile.<\/p>\n

Anche \"Effective Java\" di Joshua Bloch consiglia di preferire la composizione all'eredit\u00e0.<\/p>\n

Principio di sostituzione di Barbara Liskov (LSP)<\/h3>\n

\nUn altro principio dell'insieme SOLID. Stabilisce che i sottotipi devono essere sostituibili per il supertipo. Ci\u00f2 significa che i metodi e le funzioni che operano con la superclasse dovrebbero funzionare senza problemi anche con le sue sottoclassi.<\/p>\n

LSP \u00e8 correlato sia al principio di responsabilit\u00e0 unica che al principio di separazione delle responsabilit\u00e0. Se una classe fornisce pi\u00f9 funzionalit\u00e0 rispetto alla sottoclasse, quest'ultima non supporter\u00e0 alcune funzioni, violando cos\u00ec questo principio.<\/p>\n

Ecco un pezzo di codice che contraddice l'LSP.<\/p>\n

\"10
\n
\nIl metodo area(Rectangle r) calcola l'area del rettangolo. Il programma generer\u00e0 un errore dopo l'esecuzione di Square, poich\u00e9 Square non \u00e8 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.<\/p>\n

Questo principio, che \u00e8 una definizione specifica di sottotipo, \u00e8 stato proposto da Barbara Liskov nel 1987 in un intervento principale intitolato \"Astrazione dei dati e gerarchia\" \u2014 da qui il suo nome.<\/p>\n

Principio di separazione delle interfacce (ISP)<\/h3>\n

\nUn 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.<\/p>\n

Questa situazione si verifica pi\u00f9 comunemente quando l'interfaccia contiene pi\u00f9 funzionalit\u00e0, ma il cliente necessita solo di una di esse.<\/p>\n

Poich\u00e9 scrivere un'interfaccia \u00e8 un compito complesso, modificarla in seguito con successo dopo il completamento sar\u00e0 problematico.<\/p>\n

Il vantaggio del principio ISP in Java \u00e8 che \u00e8 necessario implementare prima tutti i metodi, per poi poterli usare nelle classi. Questo principio consente quindi di ridurre il numero di metodi.<\/p>\n

\"10
\n <\/p>\n

Programmare per l'interfaccia, non per l'implementazione<\/h3>\n

\nQui tutto \u00e8 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.<\/p>\n

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.<\/p>\n

Cio\u00e8:<\/p>\n

List numbers = getNumbers();<\/i><\/p>\n

E non:<\/p>\n

ArrayList numbers = getNumbers();<\/i><\/p>\n

Ecco una realizzazione pratica di quanto sopra.<\/p>\n

\"10
\n <\/p>\n

Il principio di delega<\/h3>\n

\nUn esempio comune sono i metodi equals() e hashCode() in Java. Quando \u00e8 necessario confrontare due oggetti, questa azione viene delegata alla classe appropriata anzich\u00e9 al cliente.<\/p>\n

Il vantaggio del principio \u00e8 l'assenza di duplicazione del codice e la relativa facilit\u00e0 di modifica del comportamento. Inoltre, \u00e8 applicabile alla delega degli eventi.<\/p>\n

\"10
\n
\nTutti questi principi consentono di scrivere codice pi\u00f9 flessibile, elegante e affidabile, con alta coesione e bassa accoppiatura. Certo, la teoria \u00e8 importante, ma per un programmatore \u00e8 fondamentale mettere in pratica le conoscenze acquisite. Il passo successivo dopo aver appreso i principi della OOP pu\u00f2 essere lo studio dei design pattern per affrontare problemi comuni nello sviluppo software.<\/p>\n

Skillbox consiglia:<\/b><\/p>\n