La Programmazione ad Oggetti – Seconda Parte

Come spiegato nella Prima Parte, la Programmazione ad oggetti è stato un vero salto in avanti nell’ambito dello sviluppo del software.

L’ereditarietà, il polimorfismo e l’incapsulamento permettono una grande flessibilità nello sviluppo. Adesso, anche se non si conosce nel dettaglio la struttura degli oggetti di una libreria, è facile interfacciarsi e trovare le funzioni che servono.
Grazie alle nuove interfacce (IDE – Integrated Development Environment) di programmazione come Eclipse, NetBeans e Visual Studio, e grazie alla tecnologia Intellisense, è possibile rintracciare le classi attraverso la navigazione tra i namespaces.

Molti di questi tools permettono la creazione di strutture documentative incorporate nel codice, in questa maniera è possibile capire direttamente dal codice il significato di alcune funzioni.

Ma qual’è il più grande vantaggio nello sviluppo ad oggetti ? La possibilità di concentrarsi in piccole porzioni di codice, di testare piccole parti e poter creare codice molto complesso a piccoli passi e con grande facilità.

Per questa ragione che i tool che creano oggetti dalla struttura del database (ORM – Object Relational Mapping) creano una struttura di classi utilizzabili dal programmatore. Queste librerie permettono di nascondere la complessità del codice che si interfaccia con il Database semplificando al massimo le operazioni più comuni.
Semplificare, nascondere la complessità sono le caratteristiche principali di una libreria di oggetti.
Un programmatore deve poter utilizzare funzioni molto potenti con semplicità, e la creazione di framework stratificati serve a questo, a semplificare lo sviluppo.
Ogni strato deve avere una funzione precisa, deve fare da interfaccia tra lo strato inferiore e quello superiore.
Ogni strato superiore utilizza il lavoro fatto dalle classi superiori e implementa altre funzionalità, questo è possibile attraverso il meccanismo dell’ereditarietà e del polimorfismo, per cui da una classe base astratta, vengono costruite man mano classi sempre più complesse fino ad arrivare alle ultime classi utilizzate dai programmatori finali.

Questo sopra è un esempio della struttura del Microsoft .Net Framework 4.6, e come si vede ci sono diversi strati software, ognuno che si interfaccia all’altro.
Lo strato più basso si interfaccia al sistema operativo di base, mentre man mano che si sale più le classi diventano specializzate in alcune categorie di funzioni.

Questo è l’esempio della struttura del sistema operativo Windows 8.

E questa di Windows XP.

In questi altri due esempi si capisce meglio come un sistema complesso come un sistema operativo, suddiviso in librerie e classi, possa essere strutturato in maniera tale da poter spezzare le competenze tra gruppi di sviluppo diversi e poter testare individualmente le classi. Ogni strato interagisce con uno o più strati ed il rischio è che un errore in uno strato inferiore possa ripercuotersi sulle classi finali. Ma la struttura gerarchica, consente di testare e trovare l’errore in maniera più agevole rispetto a quanto si faceva nella programmazione classica (la famosa spaghetti-code).

Spaghetti code è un termine dispregiativo per il codice sorgente di quei programmi per computer che hanno una struttura di controllo del flusso complessa e/o incomprensibile, con uso esagerato ed errato di go to, eccezioni, thread e altri costrutti di branching (diramazione del controllo) non strutturati.

Veniva definita così la programmazione prima dell’avvento degli oggetti, una programmazione complessa e poco leggibile e testabile. Un groviglio di codice fatto di salti da una parte ad un’altra senza costrutto e spesso senza logica.
La programmazione ad oggetti ha “costretto” i programmatori a diventare più ordinati, logici e organizzati.
Con questa organizzazione gerarchica, il programmatore si vede obbligato a costruire le classi in maniera più simile al modo di pensare umano.

Negli anni 80, la struttura dei sistemi operativi e dei programmi applicativi era decisamente più semplice e limitata.
L’interfaccia utente, l’I/O, la gestione dispositivi, il networking era decisamente molto limitato.
Adesso un Sistema Operativo deve interagire con dispositivi hardware molto più sofisticati, complessi e variegati.
Interfacce di rete, Monitor, Stampanti, Dispositivi vari, interfaccia utente estremamente complessa, strutture dati, strutture logistiche di interfacciamento con il web ed altro ancora, hanno aggiunto sempre più complicazioni e sempre maggiori difficoltà nello sviluppo.

Una volta il programmatore, doveva pensare a poche cose, mentre ora non potrebbe costruire tutto da solo, deve per forza interfacciarsi con un numero sempre maggiore di librerie.
Ognuno deve sfruttare il lavoro fatto da qualcun’altro e dedicarsi solo al proprio campo di interesse.
Come potremmo fare un programma per windows, se dovessimo costruire noi tutto il codice anche solo per costruire una finestra ?
Mi ricordo che quando ho cominciato a programmare in C++ in Windows, per creare una finestra occorrevano diverse decine di righe di codice, mentre ora bastano poche righe.
La complessità è mascherata dal framework sottostante, ed il grosso salto di qualità in casa Microsoft è stato fatto con la creazione del Framework .Net che ha codificato e organizzato tutta la struttura in librerie che anno dopo anno aumentano la capacità di interfacciarsi con hardware e strutture software che nascono anno dopo anno.

La struttura gerarchica, poi consente sostituendo una libreria sottostante con un’altra, di interfacciarsi a nuovi sistemi operativi (come Linux, Android e OSX), di poter gestire nuovi dispositivi come gli smartphone ed i tablet.

Oggigiorno sarebbe impossibile realizzare software così complesso senza poter utilizzare la programmazione ad oggetti.
La complessità del software attuale è talmente grande che, se non potessimo utilizzare librerie specializzate e testate, sarebbe estremamente oneroso per chi sviluppa e per chi acquista il programma.
Gli utenti che utilizzano un semplice programma, non immaginano neanche quanto software ci sia, anche solo per visualizzare un piccolo pulsante sul video.
La stratificazione del software è oramai un dato di fatto e non ne possiamo più fare a meno, ed è anche per questo che sono nati centinaia di gruppi di sviluppatori che creano codice in comune per realizzare software sempre più complesso anche solo per “regalarlo” alla comunità degli sviluppatori.

Nella prossima ed ultima parte, descriverò nel dettaglio come si scrive una classe utilizzando la possibilità di mascherare alcune proprietà e come mi faccio aiutare da un piccolo tool che ho costruito, per scrivere codice per le mie classi.

Please follow and like us:
RSS
Follow by Email
Facebook
Google+
https://www.marcopiumi.it/2017/04/06/la-programmazione-ad-oggetti-seconda-parte/
Twitter

Leave Comment

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

%d blogger hanno fatto clic su Mi Piace per questo: