Newsgroup: it.comp.lang.c++
Titolo: design: algoritmo su gerarchia di classi

Ciao a tutti, il problema del giorno e' il seguente [ :-) ]:
Ho una gerachia di classi che contengono praticamente dei dati numerici
provenienti da sensori, singoli od in vettori, mappe etc... comunque
eterogenei.
La gerarchia e' variabile nel tempo, quindi in futuro si potranno aggiungere
classi in base alle nuove "informazioni" che si potranno aggiungere.
Nota: l'ereditarieta' potrebbe dover essere anche multipla, devo usare l'er.
virtuale?
Su queste informazioni (e quindi su queste classi) devono essere elaborate
da un algoritmo, che dara' in uscita sempre la stessa informazione
"raffinata"
ma che agira' in maniera diversa a seconda della classe che le viene
"passata".
Questo in generale, ma ci potrebbero essere "eccezioni", nel senso che se
Algo agisce su Info3 (vedi schema sotto) allora un "pezzo di codice" sara'
probabilmente preso dall'Algo che agisce su Info2 ed un altro dall'Algo che
agisce su Info1, piu' un "pezzo proprietario" di Info3, che magari confronta
e "pesa" i due risultati sulla base delle info private di info3
(sull'algo ho idee poche ma confuse, effettivamente l'implementazione e'
ancora mooolto vaga!).
per avere un buon design e molta flessibilita' senza troppo copia-incolla di
codice, come potrei per voi modellare questa cosa?
ereditarieta' (anche virtuale), template e specializzazioni, RTTI ...,
pattern vari ... sono un po' confuso!
ad esempio, di getto:
class BaseInfo(){....};
class Info1, (virtual,vero?) public BaseInfo{....};
class Info2, (virtual,vero?) public BaseInfo{....};
class Info3,  public Info1, public Info2{...};
<template class T>
class Algo{
    classe_uscita esegui(T){...};
};
/*qui il problema e' che il metodo esegui, in generale, differisce di molto
da caso a caso, e dovrei introdurre specializzazioni parziali, credo...
e cio' non penso sia bello!*/
nota: vorrei tenere separate le classi Algo e Info...
grazie 1000!
--
Ciao by Allanon
Q: Why do programmers always mix up Christmas and Halloween?
A: Because 25 Dec = 31 Oct

 codice, come potrei per voi modellare questa cosa?
A naso quello che ti serve e' il pattern Observer, ma non ho riferimenti
sottomano, a parte il classico "Design Patterns" di Gamma, Helm,
Johnson, Vlissides.
Ciao,
Nicola

 };
Perchè vuoi fare dell'algoritmo una classe separata. Dichiara il metodo esegui come virtuale puro in BaseInfo.
ridefiniscilo in Info1 ed Info2 ed in Info3 richiamalo con la sintassi di scope resolution
Info3* esegui( ... )
{
    Info1::esegui( ... );
    Info2::esegui( ... );
    // parte necessaria alla sola Info3
    ...
}
Nota il ritorno per puntatore (sostituibile con un reference, se possibile) necessario per permettere al tipo di ritorno
di variare (sarà Info1* in Info1, Info2* in Info2 e InfoBase* in InfoBase )
Credo che così sia molto meglio.
Ciao,
--
----------------------------------------------
Fulvio Esposito
WWW: 
http://digilander.iol.it/fesposito
E-Mail Contact me at: 
ful...@libero.it
----------------------------------------------

 Johnson, Vlissides.
ho il libro, grazie dell'hint! ci guardo subito!!!
ciao by Allanon

 Ciao,
uhm... potrebbe anche essere una soluzione, ma preferivo tenere la gerarchia
di classi che modellano l'informazione separata da cio' che effettua
praticamente l'elaborazione. cmq adesso ci pensero' meglio, dopo il tuo
esempio.
ciao by Allanon

 esempio.
Perchč separare dati e funzioni. Il paradigma OO ha come scopo proprio l'unificazione in una singola struttura di dati e
funzioni. Altrimenti significa che stai applicando o il modello funzionale o quello relazionale. In effetti i nomi
BaseInfo e Info1, 2 e 3 fanno supporre proprio questo. Adesso non so se č una scelta per evitare di postare tutti i
dettagli o il tuo codice presenta proprio quei nomi. Se č la seconda, non stai pensando ad oggetti. Se č la prima,
probabilmente unificare algoritmi e dati puņ portare a trovare una soluzione migliore dal punto di vista OO. Se poi non
stai applicando alcuna metodologia OO potrebbe essere utile rivedere un po' il design dal punto di vista funzionale!


 Ciao,
ok, hai vinto... ti spiego brevemente il problema. :-)
il primo pezzo dell'applicazione non e' modificabile e, alla fine, si
ottiene
una
std::map<std::string,classettina>
questi dati sono RAW, nel senso che x adesso non hanno significato
(cio' x rendere il prelevamento di essi il piu' generico possibile)
Inoltre essi variano da momento a momento, in base alla query ed alla loro
effettiva disponibilita'
In base alla chiave string, pero', io riesco a sapere come interpretarli.
(se sai cos'e' SNMP, la string non e' altro che l'OID del campo prelevato, e
classettina contiene il valore)
Dopo che li ho interpretati devo utilizzarli per dare in uscita una
informazione utile, ad esempio una classe "Risultato"
adesso quindi devo compiere due passi:
1) interpretazione dei dati in classi strutturate (la mia gerachia BaseInfo
etc...)
2) utilizzo mediante un algoritmo che, prendendo una di queste classi, da in
uscita "Risultato"
   Ovviamente l'algo agira' diversamente in funzione della classe con la
quale e' chiamato
   (nello specifico, deve trovare una posizione: se ha dei dati da GPS fara'
una cosa, se ha dei dati
    di potenza o di tempo di volo del segnale un'altra, se li ha tutti e due
un'altra ancora)
Il problema e' appunto che voglio separare dati e algoritmo, anche xche'
l'algoritmo potrebbe variare
nel breve periodo (e non sara' fatto da me bensi' frutto di una
collaborazione con un'altra universita')
Penso quindi che sia preferibile separare il tutto, in modo che un domani
questi signori "esterni", non debbano mettere le mai sul mio codice e sulle
mie classi di dati, ma debbano solo sapere come sono fatte
le varie classi e la gerachia che c'e' fra di esse.
Penso di avere in testa una buona soluzione per l'interpretazione dei rati
raw nella gerarchia,
e quindi ho la suddetta BaseInfo etc...
adesso pero' sto' maledetto algoritmo come lo piazzo?
purtroppo non ho ancora avuto modo di guardarmi il pattern observer
suggerito da Nicola,
ne sai qualcosa?
Se sei arrivato fin qui ti faccio i mie complimenti e ti ringrazio! :-)
Spero inoltre di essere stato abbastanza chiaro/conciso!


 l'unificazione in una singola struttura di dati e funzioni. 
premetto che sono d'accordo con la soluzione da te proposta nel caso 
specifico, pero` non sono totalmente convinto della generalita` della 
tua frase:
ci sono casi in cui separare i dati dagli algoritmi che li manipolano 
permette di ottenere un design semplice, pulito ed estendibile: il 
risultato piu` eclatante lo abbiamo sotto gli occhi, basta guardare la 
libreria standard.
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 libreria standard.
Non credo che sia un paragone accettabile. Ho notato che la realizzazione di un modello che risolva un problema reale è
ben diversa dalla realizzazione di classi *utility* che servano per l'implementazione. Se mi porti un esempio in cui la
divisione algoritmi/dati porti ad una reale utilità nel mondo reale, ben venga. Ma c'ho pensato a lungo, e a parte
librerie di algoritmi e grafica 3d che sono algoritmici di natura e quindi la separazione è già netta di per se, non ho
trovato alcun problema reale che si affronti e risolva più semplicemente che tale suddivisioni. Daltronde questo è il
passo avanti che tutti imputano al modello OO rispetto ai paradigmi basati su dati o sulle funzioni. Ma sono pronto a
ricredermi se mi porti qualche esempio. Ma ti avverto che neanche Stepanov è riuscito a dare motivazioni convincenti
quando l'ha intervistato Carlo Pescio.


 Spero inoltre di essere stato abbastanza chiaro/conciso!
Spero di averti convinto, anche se non avendo maggiori informazioni sui requisiti potrei aver fatto completamente
cilecca!
Spero comunque di essere stato abbastanza chiaro!


 // 2° soluzione (di tipo funzionale, come credo voglia impostare tu )
[cut]
grazie degli esempi che mi hanno schiarito le idee...
ed effettivamente le argomentazini che porti mi hanno convinto...
adesso vado a guardarmi il pattern "abstract factory" che dicevi
(mannaggia, il GoF dovro' leggerlo tutto, prima o poi... :-( )
grazie 1000 x l'aiuto!


 Non credo che sia un paragone accettabile. 
non capisco perche` il paragone non sia accettabile.
Tu hai detto che in generale separare dati e algoritmi e` sbagliato.
Io ti ho detto che non e` sempre vero e ti ho mostrato un controesempio.


 ho il libro, grazie dell'hint! ci guardo subito!!!
Ho scritto una stupidaggine; intendevo Visitor e non Observer. In
effetti, come ti hanno detto altri, puo' risultare piu' semplice
implementare il tuo algoritmo all'interno della gerarchia, a meno che tu
non voglia riservarti la possibilita' di avere piu' algoritmi
intercambiabili o l'algoritmo non svolga una funzione che e'
concettualmente distante dallo scopo fondamentale delle classi della
gerarchia.
Ciao,
Nicola

 Nicola
grazie dei consigli, Visitor lo guardero' subito...
cmq alla fine ho implementato algo + dati nella stessa classe,
con una soluzione che mi sembra abbastanza efficiente.
Grazie a tutti!
