OOD/OOP

La programmazione ad oggetti


Questi due articoli possono risultare utili a chi si avvicina alle problematiche dell’Object Orientation, perché forniscono una buona panoramica generale, toccando i concetti fondamentali con cui si trova ad avere a che fare il programmatore OO.

Il primo articolo tratta principalmente di incapsulamento ed ereditarietà. “Incapsulare” significa tenere nascosti i dettagli implementativi di una determinata funzionalità, in modo da aumentare la separazione fra i diversi moduli di un programma, per poterli sostituire o riutilizzare in altre situazioni. Ciò costituisce uno dei presupposti fondamentali per semplificare la scrittura del codice.

Nel mondo reale gli oggetti sono classificabili secondo caratteristiche comuni: nell’OO lo stesso principio si può applicare agli oggetti di un programma; la classificazione avviene definendo un nuovo tipo come estensione di un tipo preesistente: in questo senso l’ereditarietà consente di realizzare la relazione generico-specifico tra due classi di oggetti;

Tema del secondo articolo è invece il polimorfismo, ovverosia la possibilità di poter:

1) fare riferimento a oggetti di classi diverse secondo la stessa modalità;

2) svolgere la stessa azione in modi diversi a seconda dello specifico contesto in cui ci si trova.

Viene inoltre messo in risalto il ruolo fondamentale rappresentato dall'astrazione: essa è un approccio che contribuisce a nascondere i dettagli implementativi, aumentando la chiarezza e diminuendo i tempi di sviluppo.

Interessante è infine la spiegazione della relazione tutto-parti, che non è sempre facile da identificare nel corso dei progetti reali, perché spesso confusa con l’ereditarietà: la programmazione OO utilizza continuamente questa relazione per modellizzare la situazione di aggregazione tra le varie parti di un oggetto.

Gli articoli risultano di facile comprensione, anche per la chiarezza degli esempi proposti, a chi si avvicina per la prima volta al mondo Object Oriented.



 

La riusabilità: grande scommessa dell’OO


L’OO nasce come tentativo di risposta all’esigenza di avvicinare lo sviluppo del software a quello dell’industria hardware, basata sullo sviluppo di componenti, per poterli riutilizzare nel maggior numero di contesti possibile.
Sebbene l’OO permetta di affrontare problemi complessi semplificandoli, e faciliti il raggiungimento degli obiettivi rispettando i tempi stabiliti, il problema della riusabilità è oggi tutt’altro che risolto; in particolare l’autore dell’articolo segnala come lo sviluppo di un componente software riusabile costi circa il doppio rispetto ad uno non riusabile (in termini di ingegnerizzazione, generalizzazione, testing e documentazione). Particolarmente interessanti risultano le tre regole segnalate alla fine dell’articolo relative al costo della riusabilità.


: http://www.tecnetdati.it/uml/riusabil.asp


 

Il designer dell’Object Orientation


Lo sviluppo delle metodologie OO ha fatto emergere la figura del designer, intermedia tra l’analista, il cui compito dovrebbe essere quello di saper capire ed esprimere cosa il cliente vuole, e il programmatore che implementa il software necessario.
Il designer deve:

1) avere una buona capacità di astrazione e generalizzazione;

2) avere una sufficiente competenza nel dominio applicativo, per poter progettare il sistema software;

3) destreggiarsi con uno o più linguaggi di programmazione e di modellazione (UML);

4) avere comunque una preparazione tecnica per saper realizzare un’implementazione semplice, oppure un prototipo del suo progetto, e per poter fornire le linee guida al team di sviluppo.

Inizialmente uno degli obiettivi principali dell’OO è stato quello di favorire il riuso del codice; con l’andar del tempo si è giunti a una diversa concezione di riusabilità: ciò che è veramente riusabile è l’architettura dei ruoli rivestiti dai vari componenti del sistema e delle loro relazioni: l’autore giunge così al concetto di design pattern e osserva che spesso da questo tipo di riusabilità discende poi un riuso effettivo del codice.


: http://space.tin.it/computer/csadun/articoli/design_oo.html


 

Oggetti ed Interfacce


L’interfaccia rappresenta una sorta di contratto fra le classi che la implementano ed il mondo esterno; essa vincola la classe ad implementare tutte le funzioni dichiarate nell’interfaccia. In questo articolo viene messo in evidenza il ruolo fondamentale dell’uso delle interfacce nel design per raggiungere due importanti obiettivi: il riuso e l’estendibilità.
Separando la classe che utilizza l’interfaccia da quella che la implementa, si diminuisce l’accoppiamento fra le due, e quindi la probabilità che se dovesse mutare una classe questo mutamento possa coinvolgere anche l’altra; inoltre, se nel design si considera l’introduzione di un’interfaccia ogni qual volta nasca un’esigenza di estendere il comportamento di un sistema, questo consente di sostituire parte di un sottosistema, ad esempio per cambiarne l’implementazione, senza influire sulle parti che ne fanno uso, proprio perché l’interfaccia rappresenta un contratto, un vincolo fra le “parti” in gioco.
Dopo aver approfondito questi temi con esempi realistici e concreti, l’autore si sofferma a considerare come spesso progettare un’interfaccia sia tutt’altro che semplice, a causa del fatto che non basta specificare una “signature” per le funzioni dichiarate nell’interfaccia per garantire la chiarezza del contratto, del vincolo da stabilire.