[C++] Quando usare una classe astratta ?

[mindwings]

@PGI Parliamo due lingue diverse, anche se l'autore non ha il rigore formale della Java Language Specification entrambi riusciamo a capire cosa intende e con questo chiudo.

[mindwings]

Originariamente inviato da Y3PP4

Grazie mille per gli esempi
Molto utili.

@mindwings: Grazie per il link, lo leggerò.

Non mi unisco alla discussione in merito all'articolo primo perchè non l'ho letto, poi perchè non conosco java. Ma se volete discuterne fate pure, tutto può essere utile all'apprendimento .

Non c'e' di che se ho qualcosa di interessante in genere la condivido

[lupin87]

per quanto ne sappia io,l' uso di classi astratte consiste nel definire la classe con i dati memmro e le interfacce delle funzioni membro senza l' implementazione)...l' implementazione dei metodi sarà fatta in una classe derivata(ereditarietà)...non è detto che sia la successiva a definire il metodo,ma potrebbe anche essere la classe derivata della classe derivata...

[Giuseppe Sottile]

Sono d'accordo con lupin87 ed aggiungo anche che da una classe astratta ovviamente non si possono istanziare oggetti e che in C++ una classe è astratta se contiene almeno una funzione virtuale pura.

[Y3PP4]

Originariamente inviato da Giuseppe Sottile

Sono d'accordo con lupin87 ed aggiungo anche che da una classe astratta ovviamente non si possono istanziare oggetti e che in C++ una classe è astratta se contiene almeno una funzione virtuale pura.

Grazie mille, anche a Lupin87.
PS. dal numero di messaggi deduco tu sia nuovo del forum: benvenuto!

[nuovoUtente86]

Originariamente inviato da PGI-Bis

Non c'è nulla di cui dispiacersi, tutto si impara. Il supporto che PHP offre all'orientamento agli oggetti è completo. Bisogna poi vedere com'è trattato nei libri che ne parlano. Io avevo un libro su PHP5 (PHP5 e MySQL o una cosa del genere) che faceva schifo dal punto di vista dell'OOP.

Il primo punto fondamentale, essenziale, imprescindibile è: no, in un sistema osservato da un punto di vista orientato agli oggetti ci sono un sacco di cose che NON sono oggetti.

Cos'è un oggetto nella prospettiva orientata agli oggetti? Un oggetto nella prospettiva orientata agli oggetti è una definizione autonoma.

La definizione è una collezione denominata di predicati.

Predicare è dire qualcosa di: è blu, salta, si trova in (10,5), può contenere un punto, ha un'immagine eccetera.

E' denominata nel senso che al gruppo di predicati si attribuisce un nome.

E' autonoma nel senso che non è parte di altre definizioni.

E' necessario che sia autonoma perchè una definizione che non possieda almeno un carattere unico non è in grado di identificare una parte del sistema. E' come avere due matite sul tavolo: possono essere della stessa forma, colore, materiale, possono essere in tutto e per tutto uguali ma non possono essere identiche perchè se lo fossero non le percepiremmo più come distinte, come "due matite": ne percepiremmo una sola.

Tutta la partita dell'orientamento agli oggetti si gioca sul campo dell'autonomia.

La matita è un corpo tubolare di colore giallo. Quante definizioni ho? Tre, corpo, matita, colore. Quanti oggetti ho? Uno, la matita.

Quando vado a esaminare il sistema e mi trovo con colore, corpo e matita, scopro che tra queste tre definizioni ci sono delle relazioni. E in questo sistema, fatto di questre tre definizioni, chi è autonomo, nel senso di non essere parte di altre definizioni?

Colore: è parte della definizione di matita.
Corpo: è parte della definizione di matita.
Matita: non è parte di altre definizioni ergo.

Matita è una definizione autonoma ergo è un oggetto, Colore e Corpo sono definizioni ma non sono autonome quindi non sono oggetti.

Il secondo punto fondamentale è: la dipendenza di definizione è transitiva. Se Matita dipende da Colore e Colore dipende da Int allora Matita dipende da Int.

Tutti gli strumenti dei linguaggi orientati agli oggetti - classi, interfacce, classi astratte, moduli, collegamento dinamico, ereditarietà, composizione e via dicendo - e tutti i c.d. pattern, sono funzioni che ti permettono di controllare chi dipende da cosa e, in particolare, permettono di interrompere la catena di dipendenze che deriva dalla transitività della dipendenza.

Prendiamo il caso di TestMe. Diciamo che nel tuo sistema lo consideri un oggetto, lo consideri una parte autonoma del fenomeno che stai rappresentando. Supponiamo, per non farla troppo "strana", che in C++ una classe possa essere considerata la definizione di un oggetto - e non di una pluralità di oggetti tutti con lo stesso comportamento. E' vero, nel codice che segue, che TestMe è un oggetto?

#include <cstdlib>
#include <iostream>

using namespace std;

class TestMe {

	public:
		void funzioneUno() const {
			cout << "funzione uno" << endl;
		}

		void funzioneDue() const {
			cout << "funzione due" << endl;
		}
};

class UtenteTestMe {

	private:
		TestMe utils;

	public:
		UtenteTestMe(TestMe u) {
			utils = u;
		}

		void funzioneUtente() const {
			utils.funzioneUno();
		}
};

Numero di definizioni: due. TestMe e UtenteTestMe. Numero di oggetti?

TestMe è parte di UtenteTestMe
UtentTestMe usa TestMe e non è parte di nessuno.

Due definizioni, un oggetto... UtenteTestMe!

E TestMe che fine ha fatto? TestMe c'è, è una definizione, ma non è autonoma, quindi non è un oggetto.

Ci sono tante conseguenze per il fatto che una definizione non sia la definizione di un oggetto. Una importante è questa: una definizione che non sia la definizione di un oggetto è immutabile.

Deve essere considerata immutabile perchè se è parte di un'altra definizione - e prima o poi parte di uno o più oggetti - qualsiasi intervento su quella parte incide, possibilmente in modi disastrosi, su altre definizioni.

Ho il mio bell'oggetto matita, lì sul tavolo che mi guarda sorridendo, cambio la definizione di "corpo" e PAF, la matita mi diventa un'accendino, il resto del programma non lo sa, cerca di usarla per scrivere e, morale della favola, mi ritrovo con la scrivania in fiamme!

Come faccio a preservare l'autonomia di TestMe?

Attraverso l'astrazione.

#include <cstdlib>
#include <iostream>

using namespace std;

class TestMeType {

	public:
		virtual void funzioneUno() const = 0;
		virtual void funzioneDue() const = 0;
};

class TestMe : public TestMeType {

	public:
		virtual void funzioneUno() const {
			cout << "funzione uno" << endl;
		}

		virtual void funzioneDue() const {
			cout << "funzione due" << endl;
		}
};

class UtenteTestMe {

	private:
		TestMeType* utils;

	public:
		UtenteTestMe(TestMeType* u) {
			utils = u;
		}

		void funzioneUtente() const {
			utils->funzioneUno();
		}
};

Numero di definizioni: tre. TestMeType, TestMe, UtenteTestMe.

TestMeType è usata da TestMe e UtenteTestMe.
TestMe usa TestMeType e non è usata da nessuno.
UtenteTestMe usa TestMeType e non usata da nessuno.

Numero di definizioni che sono anche definizioni di oggetto? Due: TestMe e UtenteTestMe.

Bingo.

L'astrazione di TestMeType permette a UtenteTestMe di "usare" TestMe senza dipendere da TestMe. E questa indipendenza permette a UtenteTestMe e TestMe di essere oggetti. Una delle conseguenze del fatto che UtenteTestMe e TestMe sono oggetti sta in ciò che tu a UtenteTestMe e TestMe puoi fare quel che preferisci senza che ciò pregiudichi la reciproca integrità.

Questo è lo scopo e l'applicazione della classi astratte.

Discorso molto dettagliato che riporta al concetto di altà coesione e basso accoppiamento.
Resto perplesso su un punto però

TestMeType è usata da TestMe e UtenteTestMe.
TestMe usa TestMeType e non è usata da nessuno.
UtenteTestMe usa TestMeType e non usata da nessuno.

Numero di definizioni che sono anche definizioni di oggetto? Due: TestMe e UtenteTestMe.

Che nel blocco di codice ad esame è evidentemente vera, ma se analizzassimo un progetto più ampio ad un certo punto troveremmo sicuramente qualche definizione che utilizza o delaga UtenteTestMe, e cosi andando a ritroso si arriverebbe ad avere solo la classe o modulo di startup(main) pienamente autonoma e quindi eventualmente definibile oggetto se accettiamo la definizione data su. Anche perchè in un contesto OO un oggetto (o definizione)pienamente autonomo, ovvero a tenuta stagna, sarebbe un' entità inutile se non "stimolata" dall' esterno a svolgere qualcosa.

[PGI-Bis]

Originariamente inviato da nuovoUtente86

Discorso molto dettagliato che riporta al concetto di altà coesione e basso accoppiamento.
Resto perplesso su un punto però

Che nel blocco di codice ad esame è evidentemente vera, ma se analizzassimo un progetto più ampio ad un certo punto troveremmo sicuramente qualche definizione che utilizza o delaga UtenteTestMe, e cosi andando a ritroso si arriverebbe ad avere solo la classe o modulo di startup(main) pienamente autonoma e quindi eventualmente definibile oggetto se accettiamo la definizione data su. Anche perchè in un contesto OO un oggetto (o definizione)pienamente autonomo, ovvero a tenuta stagna, sarebbe un' entità inutile se non "stimolata" dall' esterno a svolgere qualcosa.

Se intendo correttamente, è il "problema del new".

La questione è pratica ed è anche molto delicata. E' il problema della creazione che non è un problema di prospettiva orientata agli oggetti ma di programmazione orientata agli oggetti - cioè di rappresentazione di ciò che è visto in termini orientati agli oggetti.

In un sistema orientato agli oggetti non c'è bisogno di creare gli oggetti: ci sono già, sono lì, esistono in quanto parte del sistema - che è una delle tre cose che in un sistema orientato agli oggetti non è oggetto e che pertanto non li assorbe.

In un programma oo invece gli oggetti bisogna crearli.

Due soluzioni.

La prima è creare gli oggetti - nel senso tecnico di istanziarli - in un unico punto del programma e "far finta" che quello sia il sistema, nel senso predetto.

Non è formalmente rigoroso perchè, come hai già notato, quello diventa il punto in cui tutte le definizioni di oggetto appaiono insieme e, quindi, perdono la loro autonomia.

Per me in Java o C++ è la soluzione preferibile perchè è molto semplice: metti i new nel main e via.

Sarebbe tuttavia preferibile usare meccanismi di caricamento dinamico. Ad esempio in Java è piuttosto comune che per sistemi c.d. modulari l'istanziazione non avvenga direttamente con un new Pippo() ma sfrutti i ClassLoader e dica Class.forName("pippo").

Il Class.forName("pippo") rispetta l'autonomia degli oggetti sia formalmente (c'è una stringa non c'è la classe pippo) sia praticamente (il forName è delegabile quindi io posso caricare una qualsiasi classe partendo da quella stringa).

Ma si può fare anche in C++ con una factory che crea istanze di un tipo specificato in una classe base astratta usando delle librerie dinamiche.

All'atto pratico, per un linguaggio che richiede una pre-compilazione, un sintomo del fatto che esso è propriamente diviso in oggetti si evince nel momento in cui rimuovendo quella parte del programma che corrisponde ad una definizione di oggetto il programma rilsuta comunque compilabile.

Una volta adottatta "'istanziazione dinamica" si risolve anche il problema dell'impossibilità da parte di un oggetto in senso proprio di offrire effettivamente un servizio agli altri oggetti.

[nuovoUtente86]

Si inquadrando la questione dal punto di vista di un software orienta agli oggetti una delle questioni basilari è l' istanziazione, ma dopo tale fase utilizzerò in qualche modo l' oggetto, ed evidentemente se ho utilizzato un forte accoppiamento in caso di modifiche mi ritroverò in un mare di guai...e questo purtroppo è un dato di fatto.
Dal lato prospettiva ad oggetti invece resto ancora dubbioso: se ho ben capito il tuo discorso, la definizione di oggetto porta alla soluzione black-box (che dovrebbe cmq essere intrinseca di una classe) però senza via di comunicazione con l' esterno, pena la perdità di autonomia e la classificazione ad oggetto. Se la definizione A è in rapporto di Has-a con B, B non è un oggetto. Ma se B fosse autonomo sarebbe anche inutilizzato, e quindi di nessuna utilità al contesto.

Una curiosità ma cosa indichi con

c.d.

[PGI-Bis]

così detto/a

Un oggetto può essere autonomo e usato al tempo stesso. Basta che chi lo usa non faccia riferimento alla definizione dell'oggetto ma ad una parte di quella definizione - che sarà condivisa e quindi manipolabile solo a patto di sapere che si sta intervenendo su almeno due parti del programma.

L'interfaccia: tipico strumento di comunicazione che preserva l'identità.

interfaccia A
   fai qualcosa

object B extends A
   fai qualcosa ... e fai qualcosa per davvero, magari apre una base dati,
       fa una telefonata o che so io.

interfaccia C
   setA(a:A)

object D extends C
   setA(a:A) ... usa a

A a = (A)carica("B")
C c = (C)carica("D")
if(a != null && c != null) {
    C.setA(a);
}

Qui abbiamo D che usa B, attraverso A ma nè D nè B sono nominati.

non so se l'ho ricordato: la dipendenza di definizione è transitiva ma NON E' riflessiva: se X dipende da Y, Y non è detto che dipenda da X.

Mi premerebbe tuttavia sottolineare un punto. Non è che siccome quello pesudocodice è fatto com'è fatto allora è OO mentre non è OO una cosa che sia diversa da quella. Parliamo di prospettiva, di interpretazione del codice. Parliamo delle conseguenze che derivano dall'avere o non avere certe dipendenze. Non c'è un mitologico "buon orientamento agli oggetti" o un codice che sia "più orientato agli oggetti di un altro". C'è solo l'orientamento agli oggetti.

[nuovoUtente86]

Originariamente inviato da PGI-Bis

così detto/a

non so se l'ho ricordato: la dipendenza di definizione è transitiva ma NON E' riflessiva: se X dipende da Y, Y non è detto che dipenda da X.

Spunto interessante per fare una riflessione sul rapporto autonomia e dipendenza. Un oggetto autonomo è tale se non crea dipendenza ad alcuno, ma non è immune dai cambiamenti altrui (di chi ingloba nella propria definizione). Credo questo sia un punto delicato che può indurre a volte in errore, intendendo l' autonomia come la non dipendenza da altre definizioni.

Facendo un sunto possiamo affermare?(punto interrogativo) che ogni definizione(che non possa essere immutabile) non autonoma, per diventare tale, debba essere astratta al suo "contratto" e legata, con opera di bridging,ad una sua implementazione reale (magari con approccio lazy).

[PGI-Bis]

Sui principi io resterei "generico", nel senso di limitare il discorso a definizioni che sono parti di altre e definizioni che non lo sono e che quindi sono definizioni di oggetti. E' questo il senso di quel "autonoma": che non è parte di.

Come si realizza in codice questa autonomia - in particolare quando ci si trova di fronte alla normale necessità di far parlare due oggetti - dipende dal linguaggio.

Ci sono strumenti comuni. Se uno va a guardare un modo diffuso per passare ad un oggetto un riferimento ad un altro oggetto senza che il primo riceva l'intera definizione del secondo nota la sequenza astrazione-ereditarietà-composizione-polimorfismo.

Non credo però che sia l'unico modo. Anche un programma che non facesse uso di astrazione o ereditarietà o composizione o polimorfismo potrebbe dirsi orientato agli oggetti se dall'esame del codice risultasse l'esistenza di almeno due oggetti.

Ad esempio un listato C, senza particolari escamotage, risulta composto di un unico oggetto che racchiude in sè tutte le funzioni del sistema, ma se iniziassimo ad appoggiarci al caricamento dinamico di librerie probabilmente saremmo in grado di ottenere quel tanto di separazione necessaria e sufficiente affinchè parti diverse del sistema siano definibili autonome.

Io penso che si debba stare attenti nel passaggio dalla prospettiva orientata agli oggetti alla programmazione orientata agli oggetti a non confondere le proprietà di un linguaggio con i principi della prospettiva.

[banryu79]

PGI, da qualche parte ho letto la tua affermazione circa il fatto che in un sistema orientato agli oggetti ci sono almeno 3 cose che non sono oggetti, e che il sistema stesso è una di queste, dico bene?

Quali sarebbero le altre 2, che non sono oggetti?
E perchè il sistema non dovrebbe essere un oggetto?

Nel senso: se prendo Java, da un certo punto di vista potrei considerare la definizione della così detta Main Class del mio applicativo come una definizione autonoma, quindi come un oggetto, che tra l'altro equivale al sistema.
O forse mi perdo da qualche parte?

[PGI-Bis]

In un sistema orientato agli oggetti le tre cose che non sono oggetti sono:

i predicati;
le definizioni non autonome;
il sistema;

i predicati sono definizioni di principio preesistenti e, qualora debbano essere condivisi, di natura convenzionale. Io assumo una certa definizione di "colore rosso" o di "colorato" o di "mobile" eccetera, dopodichè vado a guardare il sistema attribuendo quei predicati.

le definizioni non autonome sono quelle definizioni che non partecipano ad altre definizioni.

il sistema (di oggetti) è la rappresentazione che risulta dall'osservazione del fenomeno dal punto di vista orientato agli oggetti.

Se considerassimo il sistema come un oggetto allora sarebbe anche l'unico oggetto (il sistema è ciò di cui tutti gli oggetti sono parte, un oggetto che è parte di un oggetto non è esso stesso un oggetto, quindi gli oggetti decadono a definizioni non autonome).

Considerare il sistema come oggetto andrebbe anche bene, non fa un grinza rispetto ai principi, ma non è molto utile.

L'orientamento agli oggetti non è un modo per scrivere programmi con meno linee di codice o per scrivere programmi più velocemente o più veloci o chissà che. E' un modo per scrivere programmi complessi.

La divisione in oggetti permette di gestire quella complessità nel senso ultimo di conoscere le conseguenze di un intervento su una parte del programma PRIMA di intervernire. So che io posso modificare un oggetto e tu puoi modificarne un altro in parallelo ma non possiamo intervenire su due definizioni non autonome perchè corriamo il rischio di metterci vicendevolmente i bastoni tra le ruote. Cose così.

E' chiaro allora che nel momento in cui io vado ad interpretare il sistema stesso in termini OO e lo identifico di conseguenza come l'unico oggetto possibile tutta la "gestione" della complessità va a farsi benedire: qualsiasi modifica diventa possibile e irrilevante perchè comunque sto modificando tutto quanto, non è possibile dividere il lavoro perchè c'è un oggetto solo su cui intervenire eccetera eccetera.

[banryu79]

Ok.
Quindi è un fatto che la Main Class del mio programma Java, osservato dalla prospettiva orientata agli oggetti è un oggetto in quanto definizione autonoma, ma, diciamo così, non mi conviene considerarlo tale, altrimenti i benefici che potrei io essere umano avere, nell'utilizzare tale prospettiva, se ne vanno al diavolo.
C'è qualcosa che non mi torna... o forse non ho analizzato bene a fondo le cose.

[PGI-Bis]

Direi di no. Osserva il programma in termini di definizioni, autonome e non. Risulta uno schema: alcune parti del programma dipendono da altre, alcune non dipendono da nulla.

Se alla fine di questa lettura ti risulta che tutto dipende da tutto, cioè che non ci sono oggetti a parte il programma considerato nella sua interezza, il programma è ok, va bene, ma la sua complessità non è gestibile in termini di orientamento agli oggetti.

Si può sempre fingere che un particolare punto del programma sia il "sistema" - non è detto che sia il main - ma se non è una cosa voluta sin dall'inizio la divisione in oggetti che ne risulta non corrisponderà al fenomeno che il programma rappresenta.

[banryu79]

Originariamente inviato da PGI-Bis

Direi di no.

Ok, mi sono appena reso conto del mio errore, è che stamattina ho la mente un po'... appannata.
Grazie della pazienza, come al solito.

[nuovoUtente86]

Originariamente inviato da PGI-Bis

Si può sempre fingere che un particolare punto del programma sia il "sistema" - non è detto che sia il main - ma se non è una cosa voluta sin dall'inizio la divisione in oggetti che ne risulta non corrisponderà al fenomeno che il programma rappresenta.

Io ho l' abitudine di veder (o pensare) fin dall' inizio questo punto di accentramento, proprio il cosidetto "sistema" e devo dire di trovarmi bene seguendo questo schema, fermo restando di utilizzare tutti gli strumenti astratti(pattern ad esempio) e offerti dal linguaggio di turno per mantenere il coupling più basso possibile. Magari, è una logica "progettuale" che qualcuno può criticare o non condividere però non credo sia del tutto errata, anzi può rappresentare una buona linea guida oltre che, forse, una semplificazione.

[Ikon O'Cluster]

Ok la discussione filosofica in sé per sé è interessante nella problematica... ma a tratti prende la piega di sega mentale o sbaglio???

[nuovoUtente86]

Originariamente inviato da Ikon O'Cluster

Ok la discussione filosofica in sé per sé è interessante nella problematica... ma a tratti prende la piega di sega mentale o sbaglio???

Visto dalla parte della POO e quindi della realizzazione di un ottimo software anche "modulare" e riutilizzabile. direi di SI.
Dal lato filosofico è molto interessante.

[banryu79]

Originariamente inviato da Ikon O'Cluster

Ok la discussione filosofica in sé per sé è interessante nella problematica... ma a tratti prende la piega di sega mentale o sbaglio???

Giuro che non capisco lo spirito dietro questo commento tagliente.

Perchè, postata in questi termini, la tua domanda da me non viene interpretata come tale ma come una provocazione, e, quello che non capisco, è il motivo che ti spinge a provocare.

Se non posso, usando la tua locuzione, "farmi seghe mentali" in una sezione di un forum specificamente dedicata alla "Programmazione" (e sappiamo tutti quanto numerosi siano i campi del sapere indirettamente collegati a questo termine) dove incontro altre persone che possono stimolarmi delle riflessioni che da solo non farei, mi dici dove dovrei andare a farmele, visto che nel mio caso non ho amici che programmano ne colleghi sul lavoro, ma sono solo?