PDA

Visualizza la versione completa : concetto OOP


peppe79
16-01-2004, 00:12
ciao ragazzi,
è un po che cerco di capire il concetto dell'OOP ma con scarsi risultati. -------------->>>>>>>>>> :dhò:
Qualcuno può gentilmente farmi un esempio più esplicito?
Per esempio, mettiamo il caso io voglia scrivere una Classe per un Form, come decido quali classi scrivere e con quali collegamenti (Classe madre -> subclasse) avranno tra loro?
È di letale importanza per me capire questo concetto :)

Spero di essere stato chiaro nella mia richiesta e vi ringrazio in anticipo. :dhò:

infinitejustice
16-01-2004, 05:54
Ti faccio un esempio abbastanza stupido.

Pensa a tutte le biciclette che conosci, ai vari tipi: triciclo, tandem, mountain bike, ...

Tutte hanno in comune tante cose come le ruote, il manubrio, la catena... tutte appartengono alla classe bicicletta, ovvero hanno proprietà comuni.

Ogni oggetto appartenente a quella classe avrà quindi tutte quelle proprietà proprie della classe. Poi però ci sono diversi tipi di bicicletta, ovvero delle sottoclassi. Ad esempio il triciclo ha tre ruote, ovvero ha tutte le proprietà della classe bicicletta piu alcune sue proprietà esclusive che gli altri membri della classe bicicletta non hanno.

In questo modo ad esempio crei una tua sottoclasse estendendo una classe gia esistendo. Avrà quindi tutte le proprietà della classe, piu delle nuove sue esclusive.

peppe79
16-01-2004, 11:14
grazie per la tua piccola spiegazione. Però ho ancora un dubbio, come capire quale Classe deve ereditare da quale Classe?
Cioè un esempio con un lista di operai...qual'è il modo più corretto per arrivare a far diventare operaio una classe?
Sono stato chiaro? :master:

alka
16-01-2004, 12:33
Originariamente inviato da peppe79
grazie per la tua piccola spiegazione. Però ho ancora un dubbio, come capire quale Classe deve ereditare da quale Classe?
Cioè un esempio con un lista di operai...qual'è il modo più corretto per arrivare a far diventare operaio una classe?
Sono stato chiaro? :master:
Stai parlando della famosa..."classe operaia"? :)

Scherzi a parte, l'ereditarietà non è sempre un obbligo...va usata con parsimonia, quando il dominio del problema lo richiede.

Ti faccio un paio di esempi calzandi prendendo come riferimento l'ambiente in cui lavoro di solito: Borland Delphi.

In Delphi esistono dei controlli visuali, cioè delle classi che incapsulano le funzionalità di pulsanti, caselle di testo, ecc.

Queste tipologie di controlli hanno una serie di caratteristiche in comune: una dimensione (altezza e larghezza), una posizione (distanza da margine sinistro e superiore del form), un cursore che appare quando il mouse si sposta sul controllo e così via.

Le caratteristiche in comune vengono gestite tutte allo stesso modo, quindi risulta vantaggioso - come poi è stato fatto - costruire una classe in grado di fornire tutte le suddette caratteristiche consentendo di definirle e salvarle nel progetto dell'applicazione in modo che possano essere ripristinate e utilizzate.

La rappresentazione grafica di ciascun controllo si ottiene con un metodo Paint, che però nella classe base, quella che possiede le caratteristiche relative alle dimensioni e alla posizione, è vuoto. Perchè? Semplicemente perchè pur sapendo quando è grande il controllo e dove deve essere posizionato, non è in grado di disegnarlo o meglio non sa come farlo poichè stiamo parlando di un controllo generico ma non abbiamo ancora definito di quale controllo si tratta.

A tal proposito, è possibile creare un discendente di questa classe il quale eredita tutto ciò che è presente nella classe di base in maniera automatica e imprescindibile, ma ridefinendo il metodo Paint affinchè, utilizzando le caratteristiche fornite dalla classe base, implementiamo questo metodo per disegnare ciò che vogliamo noi.

In generale, mentre nella programmazione procedurale si tende a scomporre un problema dal punto di vista delle istruzioni necessarie per risolverlo, raggruppandole in una o più funzioni e procedure quando queste si ripetono, il paradigma ad oggetti si orienta maggiormente sull'individuazione, nel sistema in cui è presente il problema da risolvere informaticamente, delle varie entità che partecipano a tale problema; successivamente, analizzandole, è possibile costruire una classe, la rappresentazione software di un singolo elemento in cui inserire al suo interno i dati con cui esso lavora e le procedure in grado di manipolarli; la classe rappresenta un modello, così come il progetto di un'automobile è la classe dell'automobile stessa, mentre si usa indicare con "oggetto" o "istanza" una realizzazione effettiva di una classe, cioè quello che una automobile rappresenta rispetto al suo modello concettuale.

L'ereditarietà consiste nel ridurre il codice scritto raggruppando le istruzioni condivise in classi basi e creando discendenti che vanno, via via, ad estendere il modello.

Non si tratta comunque di uno schema organizzativo "pratico" ma concettuale; mi spiego: non occorre abusare dell'ereditarietà solo per scrivere meno, ma ci deve essere anche un legame logico tra le entità affinchè l'intera struttura abbia un senso.

Ad ogni modo, ci sono molti testi introduttivi di linguaggi e ambienti che richiamano a concetti inerenti alla programmazione ad oggetti; magari scarica qualche ambiente che ti permetta di fare delle prove per capire come cambia l'approccio di risoluzione del problema rispetto al modo con cui probabilmente affronti le cose in questo momento, che suppongo siano diverse dato che chiedi informazioni a riguardo. ;)

Ciao! :ciauz:

peppe79
16-01-2004, 13:01
ciao alka,
ti ringrazio per la tua dettagliata spiegazione.
Adesso ho le idee più chiare, almeno per quanto riguarda l'eredità :) poi ho ancora dei dubbi sulle interface e sulle classi abstract (------> :dhò: )
Di manuali Java ne ho letti davvero letti tanti (italiani e tedeschi)...mi toccherà rileggerli altre 10 volte :)

grazie ancora
peppe

Loading