{"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\/news\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","title":{"rendered":"10 principi della programmazione orientata agli oggetti che ogni sviluppatore dovrebbe conoscere","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"10
\n
\nIncontro spesso sviluppatori che non hanno sentito parlare dei principi SOLID (noi ne abbiamo parlato in dettaglio qui<\/a><\/noindex>. \u2014 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\u00e0 utile sia ai principianti che ai programmatori gi\u00e0 esperti.
\n<\/a><\/noindex><\/p>\n

Ricordiamo:<\/b> per tutti i lettori di \u00ab\u0425\u0430\u0431\u0440\u0430\u00bb \u2014 sconto di 10.000 rubli per l'iscrizione a qualsiasi corso Skillbox utilizzando il codice promozionale \u00ab\u0425\u0430\u0431\u0440\u00bb.<\/i><\/p>\n

Skillbox consiglia:<\/b> Corso online educativo \u00abSviluppatore Java\u00bb<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

DRY (Don\u2019t Repeat Yourself)<\/h3>\n

\nUn principio abbastanza semplice, la cui essenza \u00e8 chiara dal titolo: \u00abNon ripeterti\u00bb. Per un programmatore, ci\u00f2 significa evitare codice duplicato e avere la possibilit\u00e0 di utilizzare l'astrazione nel lavoro.<\/p>\n

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

Questo serve a semplificare il codice e a rendere pi\u00f9 facile il suo supporto, che \u00e8 l'obiettivo principale dell'OOP. Non si dovrebbe abusare dell'unione, poich\u00e9 lo stesso codice non passer\u00e0 la validazione sia per OrderId che per 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, mantenerlo. Puoi semplificarti la vita attraverso l'incapsulamento. Questo permetter\u00e0 di testare e mantenere la base di codice esistente in modo pi\u00f9 efficiente. Ecco uno degli esempi<\/a><\/noindex>.<\/p>\n

Se stai scrivendo in Java, assegna per default ai metodi e alle variabili la visibilit\u00e0 private<\/a><\/noindex>.<\/p>\n

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

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

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

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

\"10
\n
\nSe \u00e8 necessario apportare modifiche, richieder\u00e0 molto tempo, poich\u00e9 dovranno essere modificati tutte le parti di codice che hanno una connessione con il frammento necessario.<\/p>\n

Tra l'altro, apertura-chiusura \u00e8 uno dei principi SOLID.<\/p>\n

Principio della responsabilit\u00e0 unica (SRP)<\/h3>\n

\nUn 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\u00f2 avere diversi metodi, ma ognuno di essi \u00e8 utilizzato solo per risolvere un compito comune. Tutti i metodi e le propriet\u00e0 devono servire solo a questo. <\/p>\n

\"10
\n
\nIl valore di questo principio sta nel fatto che riduce il legame tra un singolo componente software e il codice. Se si aggiunge pi\u00f9 di una funzionalit\u00e0 a una classe, questo introduce una connessione tra due funzioni. Pertanto, se si modifica una di esse, c'\u00e8 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.<\/p>\n

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

\n\"10
\n
\nQui sopra \u00e8 un esempio di codice in cui AppManager dipende da EventLogWriter, che, a sua volta, \u00e8 strettamente legato ad AppManager. Se \u00e8 necessario un modo diverso per visualizzare una notifica, che sia una push, un SMS o un'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 moduli singoli con altri, modificando il modulo di dipendenza. Ci\u00f2 consente di modificare un modulo senza influenzare gli altri.<\/p>\n

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

\n\"10Esistono due modalit\u00e0 principali di riutilizzo del codice: ereditariet\u00e0 e composizione, ognuna delle quali ha i propri vantaggi e svantaggi. Di solito si preferisce la seconda, poich\u00e9 \u00e8 pi\u00f9 flessibile.<\/p>\n

La composizione consente di modificare il comportamento di una classe durante l'esecuzione impostando le sue propriet\u00e0. Quando si implementano interfacce si utilizza il polimorfismo, che offre un'implementazione pi\u00f9 flessibile.<\/p>\n

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

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

\nUn altro principio della cassetta degli attrezzi SOLID. Esso afferma che i sottotipi devono essere sostituibili per il supert\u00edpo. In altre parole, i metodi e le funzioni che lavorano con la superclasse devono poter lavorare 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 della sottoclasse, quest'ultima non supporter\u00e0 alcune funzioni, violando questo principio.<\/p>\n

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

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

Questo principio, che \u00e8 una definizione specifica di sottotipo, \u00e8 stato proposto da Barbara Liskov nel 1987 durante una conferenza, in un intervento principale intitolato \"Astrattismo 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 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.<\/p>\n

Questa situazione si verifica pi\u00f9 spesso quando l'interfaccia contiene pi\u00f9 funzionalit\u00e0, e il cliente ha bisogno solo di una di esse.<\/p>\n

Poich\u00e9 scrivere un'interfaccia \u00e8 un compito complesso, modificarla dopo il completamento del lavoro senza violare nulla sar\u00e0 problematico.<\/p>\n

Il vantaggio del principio ISP in Java \u00e8 che prima \u00e8 necessario implementare tutti i metodi, e solo dopo possono essere utilizzati dalle classi. Pertanto, il principio consente di ridurre il numero di metodi.<\/p>\n

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

Programmazione per interfaccia, non per implementazione<\/h3>\n

\nQui \u00e8 tutto chiaro dal nome. Applicare questo principio porta alla creazione di codice flessibile, in grado di lavorare con qualsiasi nuova implementazione dell'interfaccia.<\/p>\n

\u00c8 consigliabile utilizzare il tipo interfaccia per variabili, tipi di ritorno o tipo di argomento del metodo. Esempio: utilizzare SuperClass invece di SubClass.<\/p>\n

Cio\u00e8:<\/p>\n

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

Non:<\/p>\n

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

Ecco un'implementazione pratica di quanto detto sopra.<\/p>\n

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

Il principio di delega<\/h3>\n

\nUn esempio comune \u00e8 rappresentato dai metodi equals() e hashCode() in Java. Quando \u00e8 necessario confrontare due oggetti, tale operazione viene delegata alla classe corrispondente anzich\u00e9 al cliente.<\/p>\n

Il vantaggio di questo principio \u00e8 l'assenza di duplicazione del codice e la relativa facilit\u00e0 di modifica del comportamento. Si applica anche alla delega di eventi.<\/p>\n

\"10
\n
\nTutti questi principi consentono di scrivere codice pi\u00f9 flessibile, bello e affidabile, con alta coesione e basso accoppiamento. Certamente, la teoria \u00e8 utile, ma affinch\u00e9 uno sviluppatore utilizzi realmente le conoscenze acquisite, \u00e8 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.<\/p>\n

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