fek docet... :)

[71104]

su CodeGuru nella sezione di driver programming per Windows è saltato fuori un thread in cui si discute su come mai i drivers si programmano in C e come mai in C++; io, forte delle lezioni del mio maestro (:D) ho fatto la mia figura; ecco il link al thread:
http://www.codeguru.com/forum/showthread.php?t=386346
il mio nick è mrnt, ma penso che quelli di DC lo capiscono dall'avatar... :asd:

ah fek, se lo leggi, iscriviti al forum e posta: "look mummy, no if!" :D :D :D

[jappilas]

su CodeGuru nella sezione di driver programming per Windows è saltato fuori un thread in cui si discute su come mai i drivers si programmano in C e come mai in C++; io, forte delle lezioni del mio maestro (:D) ho fatto la mia figura; ecco il link al thread:
http://www.codeguru.com/forum/showthread.php?t=386346
il mio nick è mrnt, ma penso che quelli di DC lo capiscono dall'avatar... :asd:

ah fek, se lo leggi, iscriviti al forum e posta: "look mummy, no if!" :D :D :D
c'è anche un altro paio di fattori che avresti potuto tirare in ballo a riprova: embedded C++, come linguaggio (meglio, subset del linguaggio) fatto per conciliare il c++ e la OOP con i requisiti della progranazione embedded e di sistema
MacOsX, o meglio il suo kernel (cioè non esattamente Mach, come spesso si dice, ma XNU, versione pesantemente modificata), il cui sottosistema Device Expert è appunto realizzato in eC++
L4 :: pistachio, come esempio di kernel scritto in c++ per conciliare le prestazioni con la manutenibilità e la portabilità del codice del (micro)kernel stesso
;)

[tomminno]

su CodeGuru nella sezione di driver programming per Windows è saltato fuori un thread in cui si discute su come mai i drivers si programmano in C e come mai in C++; io, forte delle lezioni del mio maestro (:D) ho fatto la mia figura; ecco il link al thread:
http://www.codeguru.com/forum/showthread.php?t=386346
il mio nick è mrnt, ma penso che quelli di DC lo capiscono dall'avatar... :asd:

ah fek, se lo leggi, iscriviti al forum e posta: "look mummy, no if!" :D :D :D

Quoto l'ultima parte del codice C++ che hai postato:


void DeterminingFunction(BaseEntity *entity) {
entity->Behave();
}


Questo metodo non ha molto senso, dovevi postare il codice che istanzia entity.
Per riprendere l'esempio C da qualche parte in C++ avrai un qualcosa tipo


void DeterminingFunction(PENTITY Entity) {
switch (Entity->Type) {
case ENTITY_TYPE_1:
entity = new Entity1();
break;
case ENTITY_TYPE_2:
entity = new Entity2();
break;
case ENTITY_TYPE_3:
entity = new Entity3();
break;
.
.
.
default:
ManageError();
break;
}
}


altrimenti come fai a stabilire quale classe devi istanziare?
Il codice non è poi diverso da quello C.
Sinceramente non saprei come trovare un metodo alternativo per istanziare entity qualora dipendesse dal valore di Entity->Type.
Ma si può sempre imparare qualcosa di nuovo ;)

[jappilas]

Sinceramente non saprei come trovare un metodo alternativo per istanziare entity qualora dipendesse dal valore di Entity->Type.
Ma si può sempre imparare qualcosa di nuovo ;)
state design pattern (http://wiki.ugidotnet.org/default.aspx/UGIdotNETWiki/PatternState.html), per dirne uno ;)
può non essere sempre applicabile o la soluzione migliore, quindi di modi ne esistono e se ne applicano parecchi altri, che spaziano dal factory method, all' uso di qualche if ...

[tomminno]

state design pattern (http://wiki.ugidotnet.org/default.aspx/UGIdotNETWiki/PatternState.html), per dirne uno ;)
può non essere sempre applicabile o la soluzione migliore, quindi di modi ne esistono e se ne applicano parecchi altri, che spaziano dal factory method, all' uso di qualche if ...

Sarà che mi manca di vedere un codice completo di un design pattern tipo il Factory Method, gli esempi che trovo in rete non mi hanno mai chiarito le idee a riguardo perchè sono sempre brandelli di codice separati. Ho pure il libro della GOF, ma le idee non mi si sono chiarite per niente, ho capito quando usarlo, ma non come realizzarlo.
Il Factory Method si usa quando una classe non sa quale tipo di sottoclasse istanziare, quindi la si demanda ad una classe Creator (generalmente astratta) il compito di decidere quale. Questa classe Creator generalmente si specializza in base alle classi che possono essere istanziate.
Ma nel caso della parametrizzazione, come il suddetto esempio, il Factory Method utilizza anche lui uno switch (almeno sempre negli esempi che ho potuto trovare) e sinceramente non riesco a vedere una soluzione alternativa.

Mi interesserebbe capire veramente come farlo semplicemente usando il subclassing e senza l'utilizzo dello switch.

[thebol]

Sarà che mi manca di vedere un codice completo di un design pattern tipo il Factory Method, gli esempi che trovo in rete non mi hanno mai chiarito le idee a riguardo perchè sono sempre brandelli di codice separati. Ho pure il libro della GOF, ma le idee non mi si sono chiarite per niente, ho capito quando usarlo, ma non come realizzarlo.
Il Factory Method si usa quando una classe non sa quale tipo di sottoclasse istanziare, quindi la si demanda ad una classe Creator (generalmente astratta) il compito di decidere quale. Questa classe Creator generalmente si specializza in base alle classi che possono essere istanziate.
Ma nel caso della parametrizzazione, come il suddetto esempio, il Factory Method utilizza anche lui uno switch (almeno sempre negli esempi che ho potuto trovare) e sinceramente non riesco a vedere una soluzione alternativa.

Mi interesserebbe capire veramente come farlo semplicemente usando il subclassing e senza l'utilizzo dello switch.

Vero, ma il vantaggio del factory e che la scelta avviene una volta sola(la cosa non è magari sempre fattibile), mentre invece in C con lo switch ci passi sempre.

Il trade-off è probabilmente nell'occupazione di memoria dell'oggetto instanziato, ma quella varia da caso a caso(e puo essere minima)

[tomminno]

Vero, ma il vantaggio del factory e che la scelta avviene una volta sola(la cosa non è magari sempre fattibile), mentre invece in C con lo switch ci passi sempre.

Il trade-off è probabilmente nell'occupazione di memoria dell'oggetto instanziato, ma quella varia da caso a caso(e puo essere minima)

In realtà puoi evitarlo anche con il C usando i puntatori a funzione, usi una volta sola lo switch e poi il puntatore.
Il problema però si ripresenta immutato se devi switchare tra un metodo e l'altro in continuazione al variare degli ingressi. Fortunatamente in tutti i casi che mi sono capitati lo switch lo uso una volta sola.
In un caso come quello riportato se quello che cambia è solo un metodo io userei un puntatore a metodo invece del subclassing (ma anche qui è tutto da vedere).

Però mi rimane il dubbio, se si può fare effettivamente senza usare lo switch, vorrei capire come fare.

[thebol]

In realtà puoi evitarlo anche con il C usando i puntatori a funzione, usi una volta sola lo switch e poi il puntatore.
Il problema però si ripresenta immutato se devi switchare tra un metodo e l'altro in continuazione al variare degli ingressi. Fortunatamente in tutti i casi che mi sono capitati lo switch lo uso una volta sola.
In un caso come quello riportato se quello che cambia è solo un metodo io userei un puntatore a metodo invece del subclassing (ma anche qui è tutto da vedere).

Però mi rimane il dubbio, se si può fare effettivamente senza usare lo switch, vorrei capire come fare.

per come la vedo io, è impossibile non usarli. Ma li si puo limitare a oggetti factory o cmq alla creazione dell'oggetto stesso. Questo soprattutto quando hai a che fare con oggetti vicini al basso livello. Che li fornisce qualche if lo dovra avere, il vantaggio deve essere in chi li usa.

[jappilas]

per come la vedo io, è impossibile non usarli. Ma li si puo limitare a oggetti factory o cmq alla creazione dell'oggetto stesso. Questo soprattutto quando hai a che fare con oggetti vicini al basso livello. Che li fornisce qualche if lo dovra avere, il vantaggio deve essere in chi li usa.
in realta' in certi, magari rari, casi si puo' evitare anche l' if o quantomeno evitare degli switch laddove si pensa di doverne usare...
come ho imparato tramite diamonds si possono usare oggetti "stato" che, quando invocato un loro metodo getNext(), o update(), o... , ritornano o se stessi, o l' oggetto corrispondente allo stato successivo della state machine , contenuto in una variabile membro sul tipo private nextConcreteState newstate;

certo, in altri casi qualche if incapsulato in un metodo creatore sara' comunque una soluzione migliore (piu' semplice ed efficiente) di questo schema...
quindi alla fine si ricade nel primo punto del fek - insegnamento, cioe' saper scegliere lo strumento migliore a seconda delel circostanze e usarlo... :D

[thebol]

in realta' in certi, magari rari, casi si puo' evitare anche l' if o quantomeno evitare degli switch laddove si pensa di doverne usare...
come ho imparato tramite diamonds si possono usare oggetti "stato" che, quando invocato un loro metodo getNext(), o update(), o... , ritornano o se stessi, o l' oggetto corrispondente allo stato successivo della state machine , contenuto in una variabile membro sul tipo private nextConcreteState newstate;

quel o sarà un if nello stato ;)
o meglio non sempre(se quell'o puo essere deciso a tempo di creazione dell'oggetto, si possono fare + costruttori)(oppure con factory, come dicevi tu).

Diciamo che tramite l'OOP se ne puo limitare fortemente l'uso..
alla java conference dell'anno scorso, il ragazzo di xpLabs mostro proprio come realizzare un programma di gestione paghe, limitando al max l'uso degli if e facendo in modo che per inserire una nuova funzionalita non si dovesse modificare il codice esistente(o farlo in maniera molto limitata) ma si dovesse solo creare nuove classi/oggetti.

Per quest'anno aveva promesso di mostrarci come non utilizzare i cicli, ma ho visto fa solo le sessioni a pagamento, e non so se ci potrò andare..

[cdimauro]

Con Delphi si possono in parte risolvere ricorrendo ai costruttori virtuali (chiamati anche "meta classi"): http://blogs.borland.com/abauer/archive/2003/10/11/258.aspx

[thebol]

Con Delphi si possono in parte risolvere ricorrendo ai costruttori virtuali (chiamati anche "meta classi"): http://blogs.borland.com/abauer/archive/2003/10/11/258.aspx

in java si puo fare appoggiandosi all'oggetto Class.newInstace(), che usa (se lo trova) il costruttore senza parametri. Utilizzando la reflection si possono usare anche costruttori con paramentri, ma in effetti non è possibile definire un costruttore virtuale per una gerarchia di classi a livello di linguaggio

[tomminno]

Con Delphi si possono in parte risolvere ricorrendo ai costruttori virtuali (chiamati anche "meta classi"): http://blogs.borland.com/abauer/archive/2003/10/11/258.aspx

Chissà perchè mi ricordano un pò il Factory Method realizzato con metodi template :)

Comunque siamo punto e da capo prendendo il codice Delphi, te sai che AComponent è un TMyComponent, e AnotherComponent è un TMyOtherComponent. Direi proprio che sono noti a compile-time, non a run-time.

procedure CreateComponents;
var
AComponent: TComponent;
AnotherComponent: TComponent;
begin
AComponent := CreateComponent(TMyComponent);
AnotherComponent := CreateComponent(TMyOtherComponent);
end;

Come lo scriveresti il codice se AComponent dovesse essere TMyComponent o TMyOtherComponent a seconda del valore di un qualche parametro fornito al costruttore della classe? Cioè se il loro tipo fosse noto a run-time?

[cdimauro]

Chissà perchè mi ricordano un pò il Factory Method realizzato con metodi template :)

Comunque siamo punto e da capo prendendo il codice Delphi, te sai che AComponent è un TMyComponent, e AnotherComponent è un TMyOtherComponent. Direi proprio che sono noti a compile-time, non a run-time.

procedure CreateComponents;
var
AComponent: TComponent;
AnotherComponent: TComponent;
begin
AComponent := CreateComponent(TMyComponent);
AnotherComponent := CreateComponent(TMyOtherComponent);
end;

Come lo scriveresti il codice se AComponent dovesse essere TMyComponent o TMyOtherComponent a seconda del valore di un qualche parametro fornito al costruttore della classe? Cioè se il loro tipo fosse noto a run-time?
Dipende da quello che ci devi fare. Quello era soltanto un esempio, e per forza di cose dev'essere semplice: l'obiettivo è quello di far capire il concetto di costruttore virtuale (o meta classe che dir si voglia).

Torniamo all'esempio di cui si stava parlando, così magari si capisce meglio. Nel caso dello switch, il codice lo scriverei in maniera similare (a parte lo switch chiaramente). Mi spiego.

Qualcuno dovrà pur avere settato quel valore che viene passato alle varie funzioni, giusto? Finché poi non giunge al codice in cui c'è quello switch che serve a costruire finalmente la classe in questione.

Bene, il concetto è esattamento lo stesso, salvo che al posto di settare un ben preciso valore e trascinarselo dietro fino allo switch, come valore passo il riferimento alla classe che m'interessa.

Questo per rispondere alla domanda che ponevi. Quindi il concetto è quello di passare riferimenti a classi anziché valori "classici" (numeri, enumativi, stringhe, ecc.).

In questo modo, quando arriverà al codice in oggetto, anziché eseguire lo switch, si eseguirà semplicemente AComponent.Create() e otterremo l'istanza della classe desiderata.

In soldoni il codice, usando i costruttori virtuali (con la sintassi del C++), sarebbe il seguente:
void DeterminingFunction(ENTITYCLASS Entity) {
entity = new Entity();
entity->Behave();
}
Semplice, no? :p

Io l'ho usato come il pane nei miei progetti con Delphi. E' uno strumento sintattico molto utile.

EDIT. Dimenticavo. Anche in Python si può fare la stessa cosa:
class Pippo():

def Mostra(self):
print 'Prova pippo'

class Pluto():

def Mostra(self):
print 'Prova pluto'


def Prova(Classe):

a = Classe()
a.Mostra()


Prova(Pippo) # --> 'Prova pippo'
Prova(Pluto) # --> 'Prova pluto'
Python rulez. :p

[thebol]

Bene, il concetto è esattamento lo stesso, salvo che al posto di settare un bel preciso valore e trascinarselo dietro fino allo switch, come valore passo il riferimento alla classe che m'interessa.

Questo per rispondere alla domanda che ponevi. Quindi il concetto è quello di passare riferimenti a classi anché valori "classici" (numeri, enumativi, stringhe, ecc.).

In questo modo, quando arriverà al codice in oggetto, anziché eseguire lo switch, si eseguirà semplicemente AComponent.Create() e otterremo l'istanza della classe desiderata.

e per questo che dicevo che piu usi oggetti vicino al basso livello, o cmq oggetti su cui non hai il controllo, piu è facile dover'usare gli if. Certo che si puo realizzare uno strato, che faccia questo lavoro ;)

[Angus]

Il trade-off è probabilmente nell'occupazione di memoria dell'oggetto instanziato, ma quella varia da caso a caso(e puo essere minima)

Personalmente credo che hai colto il punto della questione: trade-off tra diversi aspetti di complessità. In C++ posso scrivere apparentemente codice meno esoso di CPU ma più esoso di memoria rispetto al C. Dico apparentemente perchè conosco solo superficialmente i meccanismi dei rispettivi compilatori: sarebbe opportuno confrontare il codice macchina prodotto per misurare l'effettivo overhead.

[cdimauro]

e per questo che dicevo che piu usi oggetti vicino al basso livello, o cmq oggetti su cui non hai il controllo, piu è facile dover'usare gli if. Certo che si puo realizzare uno strato, che faccia questo lavoro ;)
Beh, coi costruttori virtuali siamo comunque a un livello basso, dal punto di vista implementativo, visto che viene sostanzialmente passato un puntatore alla VMT della classe, in giro per il codice. :p

La differenza è che qui hai un controllo maggiore / migliore, perché non puoi sbagliare a passare una costante: il compilatore Delphi ti sega le mani alla prima passata del sorgente, appena ci provi. :asd:

Inoltre il codice è molto più chiaro e leggibile (e senza if).

Certo, può essere un prezzo salato da pagare, visto che si deve istanziare una classe, ma dipende al tipo di codice che si sta realizzando.

Come dicevi tu, c'è un tradeoff da considerare, ma fra questi c'è pure quello relativo all'assenza di if, che evita i salti ed eventuali svuotamenti della pipeline del processore, ad esempio. ;)

[tomminno]

Qualcuno dovrà pur avere settato quel valore che viene passato alle varie funzioni, giusto? Finché poi non giunge al codice in cui c'è quello switch che serve a costruire finalmente la classe in questione.


Possiamo pure pensare che sia un parametro del costruttore della classe che deve occuparsi di istanziare la classe corretta (il ConcreteCreator per dirla nei termini del Pattern Factory).


Bene, il concetto è esattamento lo stesso, salvo che al posto di settare un bel preciso valore e trascinarselo dietro fino allo switch, come valore passo il riferimento alla classe che m'interessa.


E' qui che non capisco. Come fai a conoscere la classe che ti interessa se non esamini il valore del parametro?


Questo per rispondere alla domanda che ponevi. Quindi il concetto è quello di passare riferimenti a classi anché valori "classici" (numeri, enumativi, stringhe, ecc.).

In questo modo, quando arriverà al codice in oggetto, anziché eseguire lo switch, si eseguirà semplicemente AComponent.Create() e otterremo l'istanza della classe desiderata.

In soldoni il codice, usando i costruttori virtuali (con la sintassi del C++), sarebbe il seguente:
void DeterminingFunction(ENTITYCLASS Entity) {
entity = new Entity();
entity->Behave();
}
Semplice, no? :p

Io l'ho usato come il pane nei miei progetti con Delphi. E' uno strumento sintattico molto utile.

EDIT. Dimenticavo. Anche in Python si può fare la stessa cosa:
class Pippo():

def Mostra(self):
print 'Prova pippo'

class Pluto():

def Mostra(self):
print 'Prova pluto'


def Prova(Classe):

a = Classe()
a.Mostra()


Prova(Pippo) # --> 'Prova pippo'
Prova(Pluto) # --> 'Prova pluto'
Python rulez. :p

Ma se la logica è del tipo:

class Stampa;
class StampaPippo : public Stampa;
class StampaPluto : public Stampa;

Stampa * DecidiStampa(int ID)
{
if (ID == 0)
return new StampaPippo();
if (ID == 1)
return new StampaPluto();
}


Come utilizzi il pattern senza passare dagli if? A run time qualcuno imposta il valore di ID, in base a questo valore io poi devo utilizzare StampaPippo o StampaPluto.

Ho visto anche un'implementazione a template del metodo del tipo:

template <class T> Stampa * Stampa<T>::DecidiStampa()
{
return new T();
}


Il fatto è come decidi il parametro template da passare?

[cdimauro]

Possiamo pure pensare che sia un parametro del costruttore della classe che deve occuparsi di istanziare la classe corretta (il ConcreteCreator per dirla nei termini del Pattern Factory).
Sì, va bene lo stesso (nell'esempio Delphi del link che ho postato usa una semplice funzione, ma possiamo fare quello che vogliamo: è soltanto un parametro).
E' qui che non capisco. Come fai a conoscere la classe che ti interessa se non esamini il valore del parametro?
Perché è il valore stesso a rappresentare la classe. :p

In sostanza, io sto passando un puntatore alla VMT della classe di cui m'interessa creare un'istanza. Sarà poi al momento della creazione dell'istanza, richiamando il costruttore (virtuale) Create (come nell'esempio Delphi) che verrà prelevato dalla VMT il puntatore alla funzione Create specifica per questa classe, e quindi generata l'istanza.
Ma se la logica è del tipo:

class Stampa;
class StampaPippo : public Stampa;
class StampaPluto : public Stampa;

Stampa * DecidiStampa(int ID)
{
if (ID == 0)
return new StampaPippo();
if (ID == 1)
return new StampaPluto();
}


Come utilizzi il pattern senza passare dagli if? A run time qualcuno imposta il valore di ID, in base a questo valore io poi devo utilizzare StampaPippo o StampaPluto.

Ho visto anche un'implementazione a template del metodo del tipo:

template <class T> Stampa * Stampa<T>::DecidiStampa()
{
return new T();
}


Il fatto è come decidi il parametro template da passare?
Il C++ non ha i costruttori virtuali, per cui non c'è un equivalente "diretto".

L'unico modo che mi viene in mente, su due piedi, per fare la stessa cosa, è usando delle funzioni apposite che creano l'apposita istanza della classe a cui sono "legate".

Quindi, in soldoni, definirei un tipo puntatore a funzione, la cui funzione restituisce un puntatore alla classe base Stampa.
Poi creerei due funzioni, una per creare StampaPippo e una per StampaPluto, che tornino le rispettive istanze. Qui si potrebbero benissimo usare due funzioni static dentro le rispettive classi.
A questo punto al factory method passerei come parametro il puntatore alla funzione che mi crea StampaPippo o StampaPluto, a seconda dell'istanza che voglio ottenere.


Anche qui, come "vedi" :D, il codice non conterrà nessun if.

E' soltanto più macchinoso perché il C++ non ha un equivalente sintattico dei costruttori virtuali, ma si può fare esattamente la stessa cosa. ;)

EDIT: qualcosa di questo tipo:
class Stampa;

class StampaPippo : public Stampa {

static Stampa* Create() {
return new StampaPippo();
}

};

class StampaPluto : public Stampa {

static Stampa* Create() {
return new StampaPluto();
}

};

Stampa* DecidiStampa(Stampa* (*Constructor))
{
return Constructor();
}

DecidiStampa(&StampaPippo.Create);
DecidiStampa(&StampaPluto.Create);
E' da un bel po' di anni che non scrivo codice C++: spero di non aver scritto delle castronerie... :p

[tomminno]

A questo punto al factory method passerei come parametro il puntatore alla funzione che mi crea StampaPippo o StampaPluto, a seconda dell'istanza che voglio ottenere.


Proprio qui sta il nodo che non riesco a sciogliere. Come fai a decidere? :muro:
Una volta che sai se hai bisogno di StampaPippo o di StampaPluto la soluzione è chiara, è quando ancora non sai se ti serve StampaPippo o StampaPluto che non mi è chiaro. :cry:

[cdimauro]

Proprio qui sta il nodo che non riesco a sciogliere. Come fai a decidere? :muro:
Una volta che sai se hai bisogno di StampaPippo o di StampaPluto la soluzione è chiara, è quando ancora non sai se ti serve StampaPippo o StampaPluto che non mi è chiaro. :cry:
Ma questo dipende da chi ha scritto il codice: se gli serve StampaPippo o StampaPluto, passerà il puntatore alla funzione "Constructor" che gli interessa. :p

Se ci pensi bene è la stessa cosa che avviene quando, nel codice con lo switch, passi la costante STAMPA_PIPPO o STAMPA_PLUTO alla funzione che dovrà poi creare una delle due istanze: è il "chiamante" che avrà passato il valore che gli interessa.

EDIT: Immagina di dover creare una lista di StampaPluto o StampaPippo. Al factory method passi il costruttore della classe che t'interessa, e lui provvede a generare la lista "giusta" e ritornartela. ;)

P.S. Ho modificato il mio precedente messaggio. ;)

[tomminno]

Ma questo dipende da chi ha scritto il codice: se gli serve StampaPippo o StampaPluto, passerà il puntatore alla funzione "Constructor" che gli interessa. :p

Se ci pensi bene è la stessa cosa che avviene quando, nel codice con lo switch, passi la costante STAMPA_PIPPO o STAMPA_PLUTO alla funzione che dovrà poi creare una delle due istanze: è il "chiamante" che avrà passato il valore che gli interessa.


Infatti il problema è togliere lo switch dal chiamante!
Mettiamo che il chiamante sia la GUI da cui l'utente può selezionare tra diversi tipi di file e ad ognuno (in base all'estensione) sia associato una appropriata classe Reader (interfaccia comune).
Dalla GUI io al massimo posso ricevere il nome del file. Una classe Manager (tanto per rispettare il three level biz) demanderà ad un factory method il compito di istanziare la classe Reader appropriata, ma gli può passare solo l'estensione del file (oppure usare uno switch e decidere qual è la classe giusta :( ). A questo punto hai una stringa in base alla quale devi selezionare la classe giusta. Il chiamante non può passare il valore che gli interessa (cioè la classe corrispondente) perchè non lo conosce, è il chiamato che in base al parametro passato (la stringa contenente l'estensione del file) se ne deve occupare.
Come associare l'estensione di un file all'appropriata classe Reader?

[71104]

tomminno, quello che dici è vero: a monte uno statement decisionale c'è sempre, ma sempre meglio averne uno solo piuttosto che N con N uguale numero di classi derivate dalla classe base eventualmente moltiplicato per M numero di metodi astratti della classe base... :)
cioè, per spiegarmi meglio, ciò che non va fatto ed è rigorosamente da evitare, ma purtroppo spesso si fa, è la seguente cosa: istanziare un oggetto in base al tipo di operazione richiesta (e fin qua non ci si può far nulla, lo switch ci va per forza), dotare la classe di un campo Type che codifichi in qualche modo il tipo di oggetto, scegliere comportamenti successivi relativi all'oggetto in base al valore del campo Type; memorizzare un campo Type è ridondante perché è un'operazione già implicitamente fatta, implementata dal compilatore, e decidere il comportamento in base al valore di questo campo è una pessima scelta di design perché lo potrebbe già fare il compilatore attraverso il sistema delle funzioni virtuali, che guardacaso fek ci insegna risultare su molte architetture addirittura più efficiente dell'if o dello switch, e in fondo lo so pure io: sulla IA32 un CALL con operando di memoria costa sicuramente di meno di un CMP seguito da un Jcc, specialmente se anche il CMP ha operandi di memoria :)
inoltre il CALL avviene per forza, mentre invece la CPU non può sapere se il Jcc avverrà, di conseguenza il CALL "sputtana" di meno la pipeline :p
su questo sinceramente non so dirti di più perché conosco poco i meccanismi di branch prediction

[The3DProgrammer]

cioè, per spiegarmi meglio, ciò che non va fatto ed è rigorosamente da evitare, ma purtroppo spesso si fa, è la seguente cosa: istanziare un oggetto in base al tipo di operazione richiesta (e fin qua non ci si può far nulla, lo switch ci va per forza), dotare la classe di un campo Type che codifichi in qualche modo il tipo di oggetto, scegliere comportamenti successivi relativi all'oggetto in base al valore del campo Type;

violazione di LSP (il ke è male ;))

ciau

[cdimauro]

Infatti il problema è togliere lo switch dal chiamante!
Mettiamo che il chiamante sia la GUI da cui l'utente può selezionare tra diversi tipi di file e ad ognuno (in base all'estensione) sia associato una appropriata classe Reader (interfaccia comune).
Dalla GUI io al massimo posso ricevere il nome del file. Una classe Manager (tanto per rispettare il three level biz) demanderà ad un factory method il compito di istanziare la classe Reader appropriata, ma gli può passare solo l'estensione del file (oppure usare uno switch e decidere qual è la classe giusta :( ). A questo punto hai una stringa in base alla quale devi selezionare la classe giusta. Il chiamante non può passare il valore che gli interessa (cioè la classe corrispondente) perchè non lo conosce, è il chiamato che in base al parametro passato (la stringa contenente l'estensione del file) se ne deve occupare.
Come associare l'estensione di un file all'appropriata classe Reader?
Questa è un'altra problematica che non può certo essere risolta dai costruttori virtuali: non è lo strumento giusto (qui li userei per passare dalla dll all'applicazione il puntatore alla virtual table da associare all'estensione e che servirà poi per poter creare istanze della classe).

Per quello che chiedi le soluzioni sono quelle "classiche":
- catena hash;
- albero binario di ricerca;
- trie (un altro tipo di albero di ricerca, ma non binario);
da aggiornare chiaramente quando viene aggiunta un'altra dll e relativa estensione (o estensioni).

Non si possono usare né "switch" né catene di if, data la natura mutevole del problema (posso caricare quanti plug-in / dll voglio).

Tornando al "togliere lo switch dal chiamate", di cui parlavi prima e ricollegandoci al problema iniziale, non vedo quale sia il problema: se un chiamante conosce ciò di cui ha bisogno, non c'è alcuno switch.
Più chiaramente, se so che il factory dovrà creare liste di StampaPippo anziché StampaPluto, gli passerò il costruttore virtuale di StampaPippo. Ma non c'è alcuno switch né da parte del chiamante né da parte del factory.

[cdimauro]

cioè, per spiegarmi meglio, ciò che non va fatto ed è rigorosamente da evitare, ma purtroppo spesso si fa, è la seguente cosa: istanziare un oggetto in base al tipo di operazione richiesta (e fin qua non ci si può far nulla, lo switch ci va per forza)
No, le soluzioni ci sono: i costruttori virtuali per Delphi, e i puntatori a funzione static che costruiscono poi la classe per C++. ;)