[C++] Quando usare una classe astratta ?

[Y3PP4]

Sera,

stò facendo vari test con il C++ per "riprendere" l'ottica OOP.
In questo momento stavo pensando di semplificare l'utilizzo delle varie funzioni utilizzando una sola classe generale che a sua volta quindi inizializza tra i propri elementi private le altre classi.

Mi è sorto però un dubbio.
Anzichè scrivere nella classe, sempre qualcosa come:

//definizione e dichiarazione della classe AltraClasse;
class TestMe
{
private:
    AltraClasse* riferimento;
public:
    TestMe();
    ~TestMe();
};
}
TestMe::TestMe
{
    this->riferimento = new AltraClasse;
}

TestMe::~TestMe
{
    delete this->riferimento;
}

Ho volutamente tralasciato la dichiarazione e definizione della classe AltraClasse perchè priva di interesse.
La questione è: mi converrebbe, invece che fare come sopra, dichiarare AltraClasse come astratta (con le funzioni virtual) e quindi fare ereditare dalla classe TestMe i metodi astratti di AltraClasse ?

In cosa consisterebbe la convenienza?

Spero di essere stato chiaro

La classe TestMe (nome di pura fantasia) gestisce interamente le altre classi (quella per l'eccezione degli errori, etc...).

Quindi, quando usare (praticamente parlando) la classe astratta? Sempre ogni qual volta non la uso nel programma direttamente, ma ne uso i metodi solo tramite altre classi ?

Grazie mille.

[dierre]

Una classe astratta ha senso quando hai bisogno di una classe più generica che non istanzierai mai in cui metti la base, ma poi definisci più classe figlie specializzate dove metti tutto.

[PGI-Bis]

Stai cercando di riprendere in mano l'OOP eppure nel tuo intero post non c'è una sola volta la parola "oggetto". C'è qualcosa che non va.

Non c'è alcuna convenienza nell'uso di una classe astratta rispetto ad un modulo piuttostoche ad una funzione.

Tutto quello che c'è sono gli oggetti che compongono il tuo sistema: è dalle caratteristiche di questi oggetti che ricavi la necessità di usare una classe totalmente o parzialmente definita o di non usarla affatto.

Quando usi una classe? Be', quando nel sistema hai una pluralità di oggetti che si comportano tutti quanti nello stesso modo.

Dunque domanda numero 1: nel tuo sistema hai una pluralità di oggetti che si comportano tutti quanti nel modo definito in AltraClasse? Se sì, AltraClasse è una classe, altrimenti, in C++, è un modulo.

Lo stesso vale per TestMe: pluralità -> classe, altrimenti modulo.

E veniamo all'astrazione. TestMe dev'essere una classe astratta? Be', bisogna capire cosa diamine sia quest'astrazione, no?

Abbiamo detto che una classe è la rappresentazione di una pluralità di oggetti i quali si comportano allo stesso modo. Ho diecimila oggetti che hanno un nome e un cognome - o due, pluralità è più di uno. La manifestazione di quel nome e cognome è il comportamento che tutti gli oggetti di tipo X condivide.

Per le classi astratte il principio è identico: più d'un oggetto ha uno stesso "set" di comportamenti. Tra questi comportamenti che tutti quanti gli oggetti di tipo X possiedono almeno uno consiste nella definizione di un comportamento. Ho un nome, ho un cognome e devo dire come faccio a camminare.

Che significa dire AltraClasse è una classe il cui metod abc è astratto? Esattamente come succederebbe per una classe "normale" significa dire che c'è più di un oggetto che si comporta come descritto in AltraClasse. Siccome AltraClasse dice che tra le sue caratteristiche c'è la definizione di un comportamento, ogni oggetto AltraClasse avrà questa caratteristica, avrà cioè la definizione di quel comportamento.

Da cui la domanda numero 2: posto che alla 1 tu abbia detto sì, tra le caratteristiche di questa pluralità di oggetti che si comporta come descritto in AltraClasse c'è la definizione di un comportamento? Oltre ad avere N nasi ed M bocche, gli oggetti di tipo AltraClasse devono anche definire qualcosa?

E per ultima la numero 3: TestMe è la definizione di un oggetto di tipo AltraClasse? - parlo di oggetto anche se TestMe è una classe C++ perchè in C++ un modulo non è polimorfico e quindi occorre usare le classi anche per definire gli oggetti.

Questo è OOP. Iniziare il discorso dalle classi tout-court è fare orientamento alle classi, prospettiva che al momento è nota solo a certi autori dalla mente confusa.

[Y3PP4]

Originariamente inviato da dierre

Una classe astratta ha senso quando hai bisogno di una classe più generica che non istanzierai mai in cui metti la base, ma poi definisci più classe figlie specializzate dove metti tutto.

Chiarissimo. Quindi nell'esempio citato, avendo varie classi specifiche e una che permette di gestire il tutto senza dover richiamare (per semplice comodità), mi conviene dichiarare le classi specifiche come classi astratte e poi derivarne la classe che gestisce il tutto o lasciare tutto com'è - ovvero le classi vengono inizializzate con riferimenti tra gli oggetti privati della classe - ?

Sò che è una cosa molta relativa, ma mi piacerebbe avere un parere, magari motivato, del perchè fare una scelta o un'altra.
Il tuo caso specifico (classe generica da cui si derivano quelle specifiche) mi è chiaro, ma questo non è il mio caso dato che ogni classe assolve un compito preciso che viene gestito da un metodo della classe "principale".

Es. la classe CancellaStringa contiene i suoi metodi per riconoscere e cancellare la stringa, e con la classe TestMe istanzio il metodo Cancella in cui esegue automaticamente tutti i passaggi necessari.

Grazie, ciao.

[Y3PP4]

Originariamente inviato da PGI-Bis

Stai cercando di riprendere in mano l'OOP eppure nel tuo intero post non c'è una sola volta la parola "oggetto". C'è qualcosa che non va.

L'OOP l'ho utilizzato con PHP 5 (e se lo conosci capisci di che OOP parliamo). L'ho però studiato su un buon manuale di PHP interamente dedicato all'OOP (un bel mattone) e quindi ne parlava molto anche generalmente, introducendolo, prima di passare all'OOP versione PHP5.
Appena iniziai comunque lasciai PHP (e si parla di un buon annetto fà) quindi ho appreso le basi, sviluppato qualcosa e dato interessa all'OOP secondo le necessità.

Mi spiace se non ho ancora la terminologia adatta, cercherò di rimediare.
Inoltre in OOP tutto è un oggetto no? parlare di oggetto è generico (se ho ragione), quindi metodi e proprietà sono d'obbligo per farsi capire (sempre se ho ragione).

Non c'è alcuna convenienza nell'uso di una classe astratta rispetto ad un modulo piuttostoche ad una funzione.

Tutto quello che c'è sono gli oggetti che compongono il tuo sistema: è dalle caratteristiche di questi oggetti che ricavi la necessità di usare una classe totalmente o parzialmente definita o di non usarla affatto.

Quando usi una classe? Be', quando nel sistema hai una pluralità di oggetti che si comportano tutti quanti nello stesso modo.

Chiarissimo.

Dunque domanda numero 1: nel tuo sistema hai una pluralità di oggetti che si comportano tutti quanti nel modo definito in AltraClasse? Se sì, AltraClasse è una classe, altrimenti, in C++, è un modulo.

L'esempio è inventato sul momento, ma si, nel mio caso AltraClasse accetta solo oggetti che si comportano in quel modo, altrimenti usa una altra classe. Esempio la classe di gestione delle Eccezioni, l'ho realizzata sia perchè tutte le eccezioni vanno gestite in quel modo sia per poter mantenere meglio il codice e in vista di cambiamenti mi basta modificare quella classe o i suoi metodi e sono apposto.

Lo stesso vale per TestMe: pluralità -> classe, altrimenti modulo.

TestMe viene utilizzata per usufruire delle funzionalità delle altre classi. Anzichè dichiarare nel codice stesso un:
Exception* eccezioni = new Exception();
o nel caso AltraClasse* test = new AltraClasse();
Uso la classe TestMe che inizializza tutte le classi necessarie e quindi al verificarsi di date condizioni utilizzo i metodi previsti nella classe TestMe anzichè la classe specifica direttamente. E' un test che stò facendo supponendo di avere numerossime classi e che siano tutte utili al programma. Sono test che faccio per iniziare poi a scrivere un semplice engine 2D, in modo da poter utilizzare la classe Engine e gestire finestre e tutto da lì (anche se ogni cosa ha la sua classe specifica che ne definisce i metodi e le proprietà). Quindi a questa tua domanda, se TestMe è una classe o un modulo, sinceramente non saprei rispondere.

E veniamo all'astrazione. TestMe dev'essere una classe astratta? Be', bisogna capire cosa diamine sia quest'astrazione, no?

Abbiamo detto che una classe è la rappresentazione di una pluralità di oggetti i quali si comportano allo stesso modo. Ho diecimila oggetti che hanno un nome e un cognome - o due, pluralità è più di uno. La manifestazione di quel nome e cognome è il comportamento che tutti gli oggetti di tipo X condivide.

Per le classi astratte il principio è identico: più d'un oggetto ha uno stesso "set" di comportamenti. Tra questi comportamenti che tutti quanti gli oggetti di tipo X possiedono almeno uno consiste nella definizione di un comportamento. Ho un nome, ho un cognome e devo dire come faccio a camminare.

Che significa dire AltraClasse è una classe il cui metod abc è astratto? Esattamente come succederebbe per una classe "normale" significa dire che c'è più di un oggetto che si comporta come descritto in AltraClasse. Siccome AltraClasse dice che tra le sue caratteristiche c'è la definizione di un comportamento, ogni oggetto AltraClasse avrà questa caratteristica, avrà cioè la definizione di quel comportamento.

Quindi astratto o meno lo scopo del metodo è sempre lo stesso, mi pare di capire: dire che l'oggetto X possiede il metodo Y.

Da cui la domanda numero 2: posto che alla 1 tu abbia detto sì, tra le caratteristiche di questa pluralità di oggetti che si comporta come descritto in AltraClasse c'è la definizione di un comportamento? Oltre ad avere N nasi ed M bocche, gli oggetti di tipo AltraClasse devono anche definire qualcosa?

Può essere considerato comportamento anche il semplice settaggio delle variabili dell'oggetto ? E la sua lettura? Insomma, i metodi (volgarmente mi verrebbe da dire le funzioni definite nella classe) sono le definizioni del comportamento, no?

E per ultima la numero 3: TestMe è la definizione di un oggetto di tipo AltraClasse? - parlo di oggetto anche se TestMe è una classe C++ perchè in C++ un modulo non è polimorfico e quindi occorre usare le classi anche per definire gli oggetti.

TestMe permette di definire un oggetto che tra i propri metodi ha quelli per gestire proprietà e oggetti attraverso i metodi di AltraClasse. In questo modo non ha senso, ma realmente si occupa di fornire tutti i metodi necessari al funzionamento del programma. In poche parole anzichè definire io nel codice una marea di oggetti, la classe TestMe li definisce tra i propri oggetti privati, mettendo a disposizione poi dei metodi per gestirli (il vantaggio è la comodità di dichiarare in seguito un solo oggetto e poter gestire tutto il funzionamento con i metodi a disposizione - che a loro volta gestiscono oggetti privati della classe -). Detta così è complicata, sicuramente per via della mia carenza in tecnicismi, ma spero di aver resto l'idea. Nel caso ti prego di dirmelo e provvederò quando prima a porvi rimedio in qualche modo.

Questo è OOP. Iniziare il discorso dalle classi tout-court è fare orientamento alle classi, prospettiva che al momento è nota solo a certi autori dalla mente confusa.

Ti ringrazio mille, alla solita sei molto completo ed esaustivo nella risposta.
Purtroppo ho molte carenze e quel poco che sò (sapevo) si è arrugginito.



Grazie mille della pazienza e del tempo dedicato,

buona notte.

[dierre]

Originariamente inviato da Y3PP4

Chiarissimo. Quindi nell'esempio citato, avendo varie classi specifiche e una che permette di gestire il tutto senza dover richiamare (per semplice comodità), mi conviene dichiarare le classi specifiche come classi astratte e poi derivarne la classe che gestisce il tutto o lasciare tutto com'è - ovvero le classi vengono inizializzate con riferimenti tra gli oggetti privati della classe - ?

Sò che è una cosa molta relativa, ma mi piacerebbe avere un parere, magari motivato, del perchè fare una scelta o un'altra.
Il tuo caso specifico (classe generica da cui si derivano quelle specifiche) mi è chiaro, ma questo non è il mio caso dato che ogni classe assolve un compito preciso che viene gestito da un metodo della classe "principale".

Es. la classe CancellaStringa contiene i suoi metodi per riconoscere e cancellare la stringa, e con la classe TestMe istanzio il metodo Cancella in cui esegue automaticamente tutti i passaggi necessari.

Grazie, ciao.

Data l'ora tarda potrei dire una fesseria, ma mi sembra di capire che vuoi fare questo http://en.wikipedia.org/wiki/Fa%C3%A7ade_pattern . Sbaglio?

[PGI-Bis]

Originariamente inviato da Y3PP4

Mi spiace se non ho ancora la terminologia adatta, cercherò di rimediare.

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.

[Y3PP4]

Originariamente inviato da dierre

Data l'ora tarda potrei dire una fesseria, ma mi sembra di capire che vuoi fare questo http://en.wikipedia.org/wiki/Fa%C3%A7ade_pattern . Sbaglio?

Mitico! Questo è quello che vorrei realizzare con la classe "principale" (facade!?!). Ovvero che attraverso l'oggetto istanziato con quella classe (o modulo, a sto punto PGI-Bis mi ha fatto sorgere un dubbio, dato che un solo oggetto verrà istanziato con quella classe... ovvero quello che poi mi permette di accedere ai vari metodi) posso utilizzare dei metodi che forniscono una astrazione su operazioni più complesse realizzate tramite i metodi di altri oggetti privati. Anche se spesso i metodi sono 1=1 ovvero semplicemente creo un metodo che corrisponde alla chiamata del metodo di un oggetto privato, per semplice comodità e facilità di utilizzo.

Da quel che vedo in wiki istanzia i vari oggetti, non estende la classe con le altre, quindi al mio quesito "se mi conviene, in questo caso creare classi astratte per derivarne la classe TestMe" suppongo che mi convenga lasciare ogni classe "normale" e istanziare gli opportuni oggetti private in TestMe !?!

[Y3PP4]

Wow! Ti ringrazio per la chiarezza, tutto liscio come l'olio

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.

Uhm. Il mio si intitolava (a caratteri cubitali gialli) PHP5, un bel blocco di 600 pagine se non ricordo male, che parlava anche dell'interazione con MySQL e addirittura della classe mysqli.

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.

Oh, questa premessa ci stava a pennello, mi hai risolto molti dubbi.

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

Chiarissimo.

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.

Ti ringrazio per l'esempio, in questo modo hai evitato successive domande in merito all'autonomia.

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

Giustissimo.

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.

Questa parte non mi è molto chiara. Quello che hai detto si, ma dovrò vedermi in che modo interrompono la catena delle dipendenze.

TestMe c'è, è una definizione, ma non è autonoma, quindi non è un oggetto.

Questo l'ho capito grazie all'esempio della matita in seguito

Come faccio a preservare l'autonomia di TestMe?

Attraverso l'astrazione.

Oh! finalmente inizia ad essermi chiaro il motivo dell'astrazione.

// ...
class TestMeType {

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

Qui ho bisogno di chiederti due cose, dato che sul web i casi sono rari e non spiegano il perchè:
- perchè dopo la dichiarazione delle funzioni virtuali usi la keyword const ? non ne capisco il significato...
- il significato di " = 0" ? Ho fatto qualche ricerca ma idem, non se ne parla. Ho però visto un esempio di una funzione dichiarata senza la keyword const che usa "= 0" ma alla solita si sofferma sull'esempio in generale.

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.

Tutto chiarissimo. Se però dovessi cambiare la definizione della funzione in TestMe mi aspetto comunque un cambiamento anche in UtenteTestMe.
Ho comunque capito quello che intendi, in questo modo modificare TestMe non compromette UtenteTestMe.
Se invece dichiarassi due classi che ereditano dalla classe astratta e definiscono entrambi una versione differente dei metodi astratti secondo quale logica dovrei aspettarmi l'utilizzo di questo o quello?
Ho letto su una guida che la scelta della funzione avviene dinamicamente da parte del compilatore, in modo che corrisponda al tipo dell'oggetto, ma qui l'oggetto è dichiarato come puntatore alla classe astratta.

Proverò qualche esempio incrociato in modo da definire anche con la pratica come si comporta in questa condizione, ma se sai come si comporta mi faresti un (ulteriore) favore

Ti ringrazio per il tempo dedicatomi per la spiegazione di questo concetto.
Sei stato davvero molto gentile ed esaustivo.
Facendo pochissimo sforzo, potresti raccogliere il contenuto di questi post e farne una guida per il forum L'hai praticamente già fatta, e inoltre è molto dettagliata -cosa rara in rete, quando si parla di OOP-.

Grazie ancora e buona giornata!

[EDIT]
Ho letto un tutorial in rete sulle funzioni virtuali, e ho risolto il quesito del "multiplo overloading" di una funzione virtuale. Quello che mi sfuggiva era:

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

Qui passi il tipo di classe che voglio utilizzare assegnando il valore a utils.
Nel caso quindi passerò TestMe per usare la sua funzione, se ho ben capito.
Quindi ora anche questo mi torna chiaro
In questo modo posso anche evitare di accedere ad altre funzioni di TestMe se non sbaglio! (non essendo le altre dichiarate nella classe astratta).

[PGI-Bis]

const dopo la lista di argomenti indica che la funzione non può modificare i dati membro dell'oggetto.

class Base {

	private:
		int valore;

	public:
		void funzione() const {
			valore = 10; //non compila, funzione() è const, non può modificare il membro "valore"
		}
};

Se non metti "const" allora la funzione può modificare i dati membro.

class Base {

	private:
		int valore;

	public:
		void funzione() {
			valore = 10; //ok
		}
};

Ci sono tante ragioni per dichiarare const una funzione. Una è che se la funzione dichiara di non modificare dati membro allora essa sarà in grado di operare su istanza dichiarate const. Se ho un'istanza b costante:

const Base* b = qualcosa;

su b non posso invocare funzioni membro non costanti.

= 0 indica che la funzione virtuale è "pura" cioè la classe base non da una definizione di quella funzione ma saranno le singole sottoclassi non astratte a dover necessariamente definire quella funzione. Nota che "= 0" è una cosa e "const" è un'altra: l'uno non richiede l'altro.

[fero86]

Originariamente inviato da PGI-Bis

const dopo la lista di argomenti indica che la funzione non può modificare i dati membro dell'oggetto.

per l'esattezza i qualificatori messi dopo la lista di argomenti sono qualificatori tramite i quali viene definita la versione di this passata al metodo, quindi se ci metti const non ti arriva un puntatore ad un oggetto ma un puntatore ad un oggetto const.

anzi, siccome this é un puntatore const la frase é meglio formulata come: non ti arriva un puntatore const ad un oggetto ma un puntatore const ad un oggetto const.

dopodiché i campi non sono modificabili perché i campi di un oggetto o struttura const sono anch'essi const.

[banryu79]

Ehm, illuminante il post di PGI sull'OOP...
Tra le varie spiegzioni/descrizioni di questa prospettiva che ho letto non avevo mai trovato delle definizioni così precise circa l'oggetto e le sue relazioni: devo dire che vista così mi sembra una cosa meno campata in aria e più precisa, circostanziata.

Ma dove si trovano queste informazioni? Cioè, c'è qualche testo serio che definisca in questo modo la prospettiva OOP? Magari agnostico rispetto al linguaggio di programmazione?

Insomma, qualcosa che spieghi come ha fatto PGI qui, le conseguenze delle varie relazioni di dipendenza tra le definizioni di un sistema OOP e le conseguenze per gli oggetti che si vanno così' definendo... sarebbe estremamente utile e interessante

[Y3PP4]

Grazie mille a tutti

Per le spiegazioni, in particolar modo a PGI-Bis per l'esaustiva spiegazione di quanto chiesto "e oltre"!

Visto che godiamo di un così abile elemento nell'OOP se avrò altri dubbi che non riesco a risolvere posterò nuovamente sul forum

[Ikon O'Cluster]

Non ho letto gli altri post, ma se vuoi un procedimento logico per capire quando usare una classe astratta e più in generale la derivazione e quando utilizzare il polimorfismo considera questi due esempi:

class Persona {
char* Nome;
unsigned int anni;
// ...
}

class Lavoratore : public Persona {
// ...
}

class Studente : public Persona {
// ...
}

In questo caso tra le Persone e i Lavoratori e Studenti vi è una relazione di tipo "è un". Ad esempio "Persona è un Lavoratore", ma vale anche che "Lavoratore è una Persona". In questi casi la relazione essendo di tipo "è un" va tradotta con una derivazione ed in particolare se ad esempio tutte le persone considerate possono essere o Lavoratori oppure Studenti allora Persona potrà tranquillamente essere una classe astratta. In generale una classe astratta definisce una "interfaccia" cioè una serie di funzioni e di variabili che devono essere presenti in tutte le classi che derivano da essa. Ad esempio:

class Contenitore {

Oggetto* lista;

public:

virtual Oggetto leva() = 0;
virtual void metti(Oggetto* o) = 0;

}

class Portagioielli : public Contenitore;
class Gioiello : public Oggetto;

In tal caso un contenitore di per sé è un concetto astratto quindi non istanziabile, però se si parla di gioielli un contenitore di gioielli è un portagioielli. Le funzioni "leva" e "metti" dipendono dal particolare tipo di contenitore. Per esempio la classe:

class Scatolone : public Contenitore;

Avrà una funzione "metti" del tipo:

void metti(Oggetto* o) {
if(!pieno) {
accoda(o, lista);
return;
}

if(!chiuso) imballa_con_scotch();
}

Quindi come vedi il Portagioielli non potrebbe essere imballato con scotch... quindi bisogna specializzare, però in sostanza il concetto di "mettere" oggetti all'interno è sempre lo stesso.

class Persona {
//...
Animale* animale_domestico;
}

class Animale {
//...
Persona* padrone;

public:
virtual char* emetti_verso() = 0;
}

class Gatto : public Animale {
public:
virtual char* emetti_verso() {return "miao"};
}

class Cane : public Animale {
public:
virtual char* emetti_verso() {return "bau"};
}

Puoi anche notare come ho fatto un esempio ulteriore di derivazione dove "Animale è un Cane" e "Animale è un Gatto" e si nota come non esistano in natura "istanze" di Animale (del quale non si conoscerebbe il verso). Esistono solo istanze di Gatti, Cani, ecc... Tuttavia tutte le sotto-classi hanno caratteristiche comuni: ad esempio emettono un verso, hanno un padrone, ecc.... Quindi hanno la stessa "interfaccia".

Inoltre c'è nel mezzo anche una nuova relazione: "Persona ha un Animale" mentre "Animale ha una Persona" (cioè ha un padrone...). Questa relazione "ha un" puoi rappresentarla con il polimorfismo. QUesto ti permette di fare in modo che il proprietario di cane sia un Lavoratore o uno Studente. Mentre a un Lavoratore o a uno Studente puoi associare un Cane o un Gatto o un Coccodrillo! O_O

Esempi banalissimi, ma quando ti trovi a progettare il codice devi necessariamente assorbito queste primitive di OOP in modo da applicare la giusta soluzione in ogni occasione. Spesso quando ti accorgi che le cose non tornano perchè si cominciano ad ingarbugliare è proprio perchè una gerarchia di classi è sbagliata o altre questioni di progettazione. Alla fine scrivere il codice (sviluppo) è una cosa, invece progettarlo ne è un'altra. Bisognerebbe spiegarlo a quelli che mandano gli Informatici a fare lo stesso esame di stato che fanno gli Ingegneri Informatici... così alla fine diventa Ingegnere anche uno che la progettazione non ce l'ha nella testa, malgrado capisca l'UML!

[mindwings]

Il termine astrazione e' usato in maniera impropria... Dovremmo parlare di *INDIREZIONE* che appunto viene usata per rompere la dipendenza dall'implementazione concreta. La dipendenza non sparisce magicamente ma viene sostituita la dipendenza concreta con una non concreta. Qui c'e' un bell'articolo a riguardo -> http://www.zedshaw.com/essays/indire...straction.html

[PGI-Bis]

Non credo che l'autore parli di questioni relative all'orientamento agli oggetti. Altrimenti non direbbe:

"Even more proof comes from the fact that Java uses the keyword “abstract” to create objects which actually support indirection."

Spiegare concetti di OOP attraverso un linguaggio OOP significa usare una conseguenza per giustificare una causa.

La causa di un incidente in macchina non è il fatto di aver abbattuto un albero: sarà stata la distrazione, la perdita di controllo, qualsiasi cosa che è venuta prima della conseguenza.

E non va meglio con la definizione precedente:

“(v) The process of separating the interface to some functionality from the underlying implementation in such a way that the implementation can be changed without changing the way that piece of code is used. (n) The API (interface) for some piece of functionality that has been separated in this way.”

Anche qui, il codice è una conseguenza. Programmazione orientata agli oggetti è la traduzione della rappresentazione di un fenomeno interpretato alla luce dei principi dell'orientamento agli oggetti.

Esattamente come programmazione procedurale è la traduzione della rappresentazione di un fenomeno interpretato alla luce dei principi di funzionamento di un calcolatore.

Fa un discorso su Java e peraltro su un aspetto molto specifico del linguaggio. Col quale, a onor del vero, non sembra avere grande dimestichezza.

[mindwings]

Originariamente inviato da PGI-Bis

Non credo che l'autore parli di questioni relative all'orientamento agli oggetti. Altrimenti non direbbe:

"Even more proof comes from the fact that Java uses the keyword “abstract” to create objects which actually support indirection."

Spiegare concetti di OOP attraverso un linguaggio OOP significa usare una conseguenza per giustificare una causa.

La causa di un incidente in macchina non è il fatto di aver abbattuto un albero: sarà stata la distrazione, la perdita di controllo, qualsiasi cosa che è venuta prima della conseguenza.

L'articola discute circa il significato di astrazione e indirezione... Nessuno ha detto che discute l'oop nella sua interezza nemmeno l'autore.
Ecco l'argomento in esame dell'articolo:

The point I’ll be trying to make throughout the essay is simple: Abstraction and indirection are very different yet cooperating concepts with two completely different purposes in software development. Abstraction is used to reduce complexity. Indirection is used to reduce coupling or dependence. The problem is that programmers frequently mix these up, using one for the other purpose and just generally screwing things up.

Originariamente inviato da PGI-Bis

E non va meglio con la definizione precedente:

There’s one “definition” of abstraction that lays out the entire basis for my argument very clearly:

“(v) The process of separating the interface to some functionality from the underlying implementation in such a way that the implementation can be changed without changing the way that piece of code is used. (n) The API (interface) for some piece of functionality that has been separated in this way.”

Notice that this definition is entirely different from the others. It doesn’t mention words like “abridged, summarize, concentrate, concrete, general, or common”?

E' chiaro che se quoti alcuni pezzi omettendone altri non si capisce cosa vuole dire l'autore... Ho aggiunto i pezzetti da te omessi in bold.
Altro "E non va meglio con la definizione precedente", critichi l'autore su una definizione che non piace nemmeno all'autore...

Originariamente inviato da PGI-Bis

Fa un discorso su Java e peraltro su un aspetto molto specifico del linguaggio. Col quale, a onor del vero, non sembra avere grande dimestichezza.

Da cosa lo deduci? Sfera di cristallo?!

Invito chiunque sia interessato a leggere l'articolo e di non accontentarsi
dei riassuntini di nessuno. Le informazioni vanno contestualizzate e analizzate

[PGI-Bis]

Io ho a volte ho la seria impressione di parlare una lingua sconosciuta.

Io parlo di orientamento agli oggetti. E il mio punto relativo a quel blog è quello che ho messo come prima frase nella mia risposta:

Originariamente inviato da io

Non credo che l'autore parli di questioni relative all'orientamento agli oggetti.

Naturalmente con ciò presuppongo che qui noi stiamo affrontando un problema di orientamento agli oggetti. E per questo dico: attenzione che quel blog parla di un'altra cosa.

E porto due indizi a giustificazione di questa mia affermazione. Il fatto che l'autore tiri in ballo un aspetto molto specifico di un particolare linguaggio di programmazione e il fatto che discuta una definizione che è altrettanto particolare.

Ho forse scritto che l'autore aderisce ad una definizione e dimostrato che quella definizione è sbagliata? Non mi sembra.

Sono più che d'accordo sul fatto che quando uno cita un pezzo di un testo c'è sempre il rischio che si perda o addirittura si stravolga il significato di quella parte di testo. A me però non interessava la conclusione dell'autore sulla definizione che cita ma il fatto che argomentando intorno a quella definizione risultasse chiara l'estraneità della discussione al tema dell'orientamento agli oggetti.

Sul fatto che parlando di Java dimostri una scarsa conoscenza del linguaggio, lo confermo. Non è la sfera di cristallo a dirmelo ma la conoscenza teorica e pratica del linguaggio, unita alle stupefacenti imposizioni che l'autore attribuisce alla parola chiave abstract.

Even more proof comes from the fact that Java uses the keyword “abstract” to create objects which actually support indirection. Think about it, the “abstract” keyword doesn’t reduce, summarize, or generalize a more concrete implementation, but rather creates an indirect path to the real implementation of that function. If this “abstract” class were to follow the previous definitions it would simply reduce the number of functions needed to use the actual concrete implementation. But, when you implement an “abstract” Java class you must implement the same number of functions including the abstract functions just to get it work.

Le due frasi in grassetto sono sbagliate: non dico imprecise, dico proprio sbagliate. Presuppongono regole di un linguaggio diverso da Java.

[banryu79]

Sono d'accordo con PGI per quanto riguarda il fatto che l'autore di quell'articolo non parla di questioni rientranti nella prospettiva di programmazione orientata agli oggetti.

Originariamente inviato da PGI-Bis

Le due frasi in grassetto sono sbagliate: non dico imprecise, dico proprio sbagliate. Presuppongono regole di un linguaggio diverso da Java.

Sì, ma bisogna, secondo me, interpretarle usando come filtro le premesse fatte dall'autore dell'articolo. Ovvero che tutto il suo discutere riguarda la precisa definizione della parola "abstract" nella lingua iglese, e di quello che invece comporta la stessa parola nel linguaggio Java.

Ammetto però che l'autore dell'articolo mi sembra peccare di ingenuità: secondo lui la keyword "abstract" in Java è misleading per il novello programmatore perchè il suo significato non è isomorfo a quello della parola "abstract" nel linguaggio naturale...
Essendo Java un linguaggio di programmazione, uno ne tiene conto e non può aspettarsi che ogni parola usata come keyword nel linguaggio formale abbia lo stesso significato della stessa parola usata nel linguaggio naturale...

[Y3PP4]

Originariamente inviato da Ikon O'Cluster

Non ho letto gli altri post, ma se vuoi un procedimento logico per capire quando usare una classe astratta e più in generale la derivazione e quando utilizzare il polimorfismo considera questi due esempi:

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 .