View Full Version : Design della struttura di un applicazione...sono pazzo?
Ciao raghi,
sto mettendo mano ad un'applicazione sviluppata (un po' da cani a mio parere) in java.
Allora in questa applicazione ci sono delle classi statiche che operano con una sorgente dati (che mi è stato ribadito più volte, dovrebbero essere il più trasparenti possibile ed essere in grado di restituire sempre lo stesso formato di dati anche al cambio della sorgente) (chiamiamole classi driver) e delle classi che usano questi driver (chiamiamole classi logiche).
Ora la struttura di queste classi è la seguente:
Driver:
Variabili;
Metodi (non statici) che leggono i dati di un solo specifico oggetto e che popolano le variabili dell'istanza della classe;
Metodi (statici) che leggono i dati di più oggetti e che ritornano un vector semplice con tutte le informazioni degli oggetti inserite in serie;
Logiche:
Metodi che istanziano un oggetto di tipo driver, che richiamano i metodi di tipo B (dell'oggetto istanziato) che passano i dati dall'oggetto istanziato ad un vector e che infine restituiscono il vector;
Metodi che chiamano i metodi B (statici) degli oggetti di tipo driver e che restituiscono a loro volta il vector restituito da questi metodi;
Allora:
sta trasparenza dei driver dov'è? Addirittura senza neanche tener conto del cambio della sorgente di dati restituiscono 2 cose diverse che devono poi essere adattate dalle logiche!
le logiche a che servono?! non fanno niente! ...ah no, è vero, devono adattare i dati restituiti dai driver!
Allora io ho proposto di creare una struttura del genere (perlomeno per i driver e le logiche nuovi che dovranno essere create):
classe elemento che non fa altro che contenere i dati (e i metodi per leggerli e modificarli);
classe driver che legge i dati dalla fonte e popola un'array di elemento;
classe logica che usa le classi driver e gestisce l'array di elemento;
questa è la discussione che abbiamo avuto in seguito alla mia proposta:
lui: :O "ma...la classe elemento non ha senso, possiamo inserirla all'interno della rispettiva classe driver!"
io: :mbe: "perchè non ha senso? definisce una struttura dati! ...altrimenti inseriamo pure il vector dentro al driver no?!"
lui: :O "no ma il vector è una classe primitiva che non sta ne nel driver ne nella logica!"
io: :mbe: "ah allora non si possono creare classi se non stanno ne nella classe ne nella logica? è semplicemente una classe che definisce un tipo di dato, perchè mai non dovrebbe avere senso?"
lui: :O "perchè tanto vale fare una struttura allora!"
io a sto punto non ce la facevo più, gli ho dato ragione e faccio come vuole, anche se vederlo soddisfatto e sicuro di avermi convinto è stato molto duro!
ma veramente io non riesco a capire come il direttore tecnico (e pure ingegnere) di una filiale di un'azienda abbastanza importante nel panorama IT italiano possana fare discorsi del genere...e magari fosse la prima volta!
comunque ora torniamo alla domanda del titolo: sono pazzo?
BountyKiller
09-10-2006, 13:49
(e pure ingeniere)
sto piangendo e rotolandomi sulla scrivania...
sto piangendo e rotolandomi sulla scrivania...
:stordita:
No, non siete pazzi.
L'affinità che deve esistere tra due esseri umani affinchè possano intendere uno stesso fenomeno nei medesimi termini è talmente eccezionale da farmi ritenere che discussioni come quella a cui hai preso parte siano la norma.
In senso figurato è come se tu e il tuo interlocutore, avendo un'idea non osservabile della stessa forma, aveste dichiarato uno "è una palla da tennis", l'altro "è una palla da baseball".
Entrambi avete ragione per il semplice fatto che discutete di una forma non condivisa.
Aggiungere un terzo – e un quarto e un quinto... – alla discussione la renderà più interessante ma certo non più determinata.
A me entrambe le soluzioni appaiono giustificabili se tento di immaginare ora una palla da tennis, ora una palla da baseball.
A dirla tutta, la presenza di cose "static" nella prima rappresentazione mi lascia perplesso. La passione viscerale per l'orientamento agli oggetti che mi anima mi fa ritenere che dietro ad ogni "static" ci sia qualcuno che dovrebbe chiarirsi le idee su cosa sia un oggetto. Non perchè non si possa usare questo particolare strumento del linguaggio ma perchè il significato di ciò che è static è assolutamente particolare.
Secondo una certa idea di programmazione orientata agli oggetti – l'unica accettabile, secondo me – tutto ciò che è static in Java è parte della definizione di ogni oggetto che possa accedere a quello "static". Dal che si deducono alcuni caratteri del fenomeno rappresentando verso i quali il sistema rappresentato ha un dovere di coerenza.
Per farla breve e non annoiarti più del necessario, non puoi dire se la rappresentazione proposta dal tuo interlocutore sia giusta o sbagliata, perchè non hai modo di partecipare alla percezione del fenomeno che egli ha avuto. Lo stesso vale, naturalmente, a parti inverse: che qualcuno creda realmente di averti convinto è il sintomo che quel qualcuno ha un'idea piuttosto bizzarra di ciò che comunemente si chiama "sistema di riferimento".
Quello che invece puoi e dovresti fare è giudicare la coerenza della rappresentazione proposta con sè stessa.
Come ogni modello di ciò che un uomo ha percepito il fenomeno rappresentato in un software ha un'arbitrarietà assoluta: che la sorgente dati debba essere "trasparente" – quasi fossimo vetrai – non è più corretto dell'averne una "opaca" – qualsiasi cosa possa significare. La scelta che è stata fatta è sperabilmente fondata sulla maggiore idoneità di questa caratteristica a rappresentare il fenomeno percepito: noi possiamo immaginare che il fenomeno percepito abbia una fonte di dati soggetta ad un qualche tipo di mutazione e che altri parti dello stesso sistema siano insensibili a queste mutazioni. Se altre parti del sistema devono comunicare con questa fonte dati occorre che sia introdotto un meccanismo che rappresenti quell'insensibilità.
Il meccanismo che ti è stato proposto (o imposto) è idoneo? E' coerente con il sistema, cioè la sua introduzione non comporta definizioni che contraddicono altre definizioni presenti nel sistema?
Se la difficile risposta è sì allora non puoi che dire "diamine, si vede che lui ha percepito questo fenomeno". Se la risposta è no allora c'è un'assurdità nel sistema – che dovrai realizzare lo stesso perchè l'ha detto il committente e poi te ne beccherai pure la responsabilità perchè questo è il pianeta terra :D.
Ci sono tante, comprensibili ragioni per cui un sistema ad un certo punto risulta incoerente. Una per tutte, il tempo dedicabile alla comprensione del fenomeno osservato è sempre una frazione di quello necessario.
L'introspezione, vale a dire l'acquisizione a livello cosciente della percezione inconscia di un fenomeno, richiede l'applicazione per un tempo eterno di una quantità infinita di neuroni d'acciaio.
Ciao raghi,
sto mettendo mano ad un'applicazione sviluppata (un po' da cani a mio parere) in java.
Allora in questa applicazione ci sono delle classi statiche che operano con una sorgente dati (che mi è stato ribadito più volte, dovrebbero essere il più trasparenti possibile ed essere in grado di restituire sempre lo stesso formato di dati anche al cambio della sorgente) (chiamiamole classi driver) e delle classi che usano questi driver (chiamiamole classi logiche).
Ora la struttura di queste classi è la seguente:
Driver:
Variabili;
Metodi (non statici) che leggono i dati di un solo specifico oggetto e che popolano le variabili dell'istanza della classe;
Metodi (statici) che leggono i dati di più oggetti e che ritornano un vector semplice con tutte le informazioni degli oggetti inserite in serie;
Logiche:
Metodi che istanziano un oggetto di tipo driver, che richiamano i metodi di tipo B (dell'oggetto istanziato) che passano i dati dall'oggetto istanziato ad un vector e che infine restituiscono il vector;
Metodi che chiamano i metodi B (statici) degli oggetti di tipo driver e che restituiscono a loro volta il vector restituito da questi metodi;
Allora:
sta trasparenza dei driver dov'è? Addirittura senza neanche tener conto del cambio della sorgente di dati restituiscono 2 cose diverse che devono poi essere adattate dalle logiche!
le logiche a che servono?! non fanno niente! ...ah no, è vero, devono adattare i dati restituiti dai driver!
Allora io ho proposto di creare una struttura del genere (perlomeno per i driver e le logiche nuovi che dovranno essere create):
classe elemento che non fa altro che contenere i dati (e i metodi per leggerli e modificarli);
classe driver che legge i dati dalla fonte e popola un'array di elemento;
classe logica che usa le classi driver e gestisce l'array di elemento;
questa è la discussione che abbiamo avuto in seguito alla mia proposta:
lui: :O "ma...la classe elemento non ha senso, possiamo inserirla all'interno della rispettiva classe driver!"
io: :mbe: "perchè non ha senso? definisce una struttura dati! ...altrimenti inseriamo pure il vector dentro al driver no?!"
lui: :O "no ma il vector è una classe primitiva che non sta ne nel driver ne nella logica!"
io: :mbe: "ah allora non si possono creare classi se non stanno ne nella classe ne nella logica? è semplicemente una classe che definisce un tipo di dato, perchè mai non dovrebbe avere senso?"
lui: :O "perchè tanto vale fare una struttura allora!"
io a sto punto non ce la facevo più, gli ho dato ragione e faccio come vuole, anche se vederlo soddisfatto e sicuro di avermi convinto è stato molto duro!
ma veramente io non riesco a capire come il direttore tecnico (e pure ingegnere) di una filiale di un'azienda abbastanza importante nel panorama IT italiano possana fare discorsi del genere...e magari fosse la prima volta!
comunque ora torniamo alla domanda del titolo: sono pazzo?
A mio parere non è opportuno modellare una nuova classe elemento, almeno fino a quando i dati da trattare rimangono in un semplice vettore (o array che dir si voglia): al massimo, incapsuli, come suggerito dal tuo interlocutore, il concetto di "elemento" nella classe driver, se vuoi una trattazione dei dati già "ordinata". Aggiungere una nuova classe quando non ce n'è bisogno rischia di complicare la struttura del progetto: meglio una classe robusta che tante piccole classi.
EDIT: parlando di "trasparenza", è appunto il driver che deve occuparsi di questo, invece di popolare un'altra classe: questo lo fa offrendo opportuni metodi di "formattazione output".
Innanzitutto grazie ad entrambi delle risposte!
Continuo dicendo che durante la stesura di quel post ho omesso qualche particolare (soprattutto qualche porzione di codice che potesse risultare più esplicativa delle mie parole) che aggiungo ora:
in questo pezzo di codice l'istanza candidato della classe Dati_Profilo (che ha solo metodi statici tranne quello di cui ho riportato il codice) chiama il metodo getDatiContratti).
Come potete vedere il risultato viene memorizzato in un'array a 3 dimensioni con conseguente caos!
...
Object[][][] datiContratto=new Object[12][50][2];boolean esisteContratto=false; String dDataDimissioni = "";
datiContratto=(Object[][][])candidato.getDatiContratti(ca.getnCodAnagrafica());
int lunghezzaContr=0;cd=null;
if((datiContratto[10][0][0]!=null)&&(datiContratto[10][0][0] instanceof String)&&(!(String.valueOf(datiContratto[10][0][0]).equals(""))))
lunghezzaContr = Integer.parseInt((String)datiContratto[10][0][0]);
esisteContratto=ContrattoDimissioni.getDimissioni(ca.nCodAnagrafica());
if(lunghezzaContr > 0 && !esisteContratto){
esisteContratto=true
...
Questo invece è il codice del metodo...come potete vedere all'interno di quell'array c'è un'accozzaglia di tipi di dati diversi.
public object[][][]getDatiContratti(int nCodCandidato)throws SQLException{
Contratto_Dati cd=new Contratto_Dati();
Contratto_Allocazione ca=new Contratto_Allocazione();
int i=0;
ResultSet rs;
ResultSet rs1;
Object o[][][]=new Object[12][20][5];
try{
rs=DBAccess.conn("SELECT * FROM pippe WHERE ...");
while(rs.next()){
cd=new Contratto_Dati(rs);
o[10][1]=(Contratto_Dati)cd;
ca=Contratto_Allocazione.getCommessa_Attiva(cd.getnCodContratto(),nCodCandidato);
if(ca!=null)
{
o[10][i][2]=(Contratto_Allocazione)ca;
ca=null;
}
i++;
}finally{
try{
return o;
}catch(Exception e){}
}return null;
}
A mio parere non è opportuno modellare una nuova classe elemento, almeno fino a quando i dati da trattare rimangono in un semplice vettore (o array che dir si voglia):
ho evidenziato [I]semplice vettore per il fatto che molto probabilmente ti avevano tratto in inganno queste mie parole:
vector semplice con tutte le informazioni degli oggetti inserite in seriecomunque, in questo caso che faresti?
al massimo, incapsuli, come suggerito dal tuo interlocutore, il concetto di "elemento" nella classe driver, se vuoi una trattazione dei dati già "ordinata".
ok, ma andiamo con calma:
se il driver fosse composto dall'elemento e anche dai metodi che servono a leggerne i dati dalla fonte, nel caso dovessi leggere i dati inerenti ad un'unico elemento mi starebbe bene, creerei un'istanza e la farei autopopolare con il metodo adatto, ma nel caso dovessi leggere i dati di più elementi come potrei fare? creare n-istanze e farle autopopolare? per ogni istanza ci sarebbe una query da eseguire e cosa più importante nel caso avessi una query generale che mi legge tutti gli elementi in un colpo dovrei crearmi n-istanze delle classe all'interno di se stessa per poi popolarle una ad una!
-incasinato lo so- spero solo che qualcuno riesca a capire il senso di quello che la mia mente contorta ha partorito!
Aggiungere una nuova classe quando non ce n'è bisogno rischia di complicare la struttura del progetto: meglio una classe robusta che tante piccole classi.
ma qui non c'è ne una classe robusta ne tante piccole classi, (inoltre io non voglio nessuno dei due scenari!) c'è solo un caos allucinante!
perchè non si può intendere una classe come tipo di dato?
ormai tutti i tipi di dati sono classi (vabbè a parte i primitivi)!
io avrei semplicemente un tipo di dato adatto per ogni occasione che verrebbe popolato dal driver adatto!
EDIT: parlando di "trasparenza", è appunto il driver che deve occuparsi di questo, invece di popolare un'altra classe: questo lo fa offrendo opportuni metodi di "formattazione output".
il driver restituirebbe semplicemente un'istanza di un tipo di dato oppure un array con i puntatori a più istanze del tipo di dato!
...solo che piuttosto di essere istanze di String o di vattelappesca sarebbero istanze del mioTipoDiDato!
...che c'è che non va in questo?
'iao
Il codice postato dice più di mille parole.
Quel metodo è un casino, per non parlare del costutto try-catch implementato in quel modo: è un colpo al cuore...
Il vettore è tutt'altro che semplice, e dal tuo post precedente (come tu stesso hai fatto notare), non si capiva di che tipo era: oltre al fatto che è in 3 dimensioni ( :rolleyes: ), non si riesce a sapere a priori che cavolo ci va dentro, dal momento che è un Object, ed ogni volta devi verificare il tipo con "instanceof"...
Molto meglio allora creare una classe ad hoc, che viene istanziata dal driver per inserirne i dati, e poi restituita all'esterno con la "return".
Io pensavo che fosse un semplice array...
Onestamente, da quello che hai postato, il tuo collega non è che dia una buona immagine della categoria lavorativa a cui io stesso appartengo... :stordita:
EDIT: per non parlare della doppia istanza:
Contratto_Dati cd=new Contratto_Dati(); // All'inizio del metodo.
cd=new Contratto_Dati(rs); // Nel blocco try.
EDIT 2: Una curiosità personale: il tuo collega è un ingegnere con laurea di primo livello (3 anni), specialistica (+2) o vecchio ordinamento?
EDIT 3: Ma le Collection non le potete usare, invece di andare con i vettori multidimensionali statici? Java da quel punto di vista è iperflessibile!
Onestamente, da quello che hai postato, il tuo collega non è che dia una buona immagine della categoria lavorativa a cui io stesso appartengo... :stordita:
c'è da dire che sto codice non l'ha scritto lui, eppure si ostina a difenderlo!
sarà che è stato scritto seguendo sue indicazioni!
...boh!
mi piacerebbe comunque riportare tutte le cazzate che l'ho sentito dire da quando lavoro qua dentro (e che sono la causa del tono polemicissimo del post di apertura...era l'ennesima della mattinata, mi ero svegliato male e non ce la facevo più!) purtroppo però ne ricordo mezze...vabbè se mi verrà voglia comincerò a segnarmele!
...non sarebbe male l'idea di un 3d in cui inserire le sparate...mi immagino alquanti lol e rotfl :D
grazie ancora!
'iao
EDIT 2: Una curiosità personale: il tuo collega è un ingegnere con laurea di primo livello (3 anni), specialistica (+2) o vecchio ordinamento?
vecchio ordinamento!
...ed elasticità mentale 0 della serie: "Ho sempre fatto così...e siccome va bene non c'è motivo di cambiare! ...e neppure di vedere se c'è qualcosa di nuovo e più funzionale!"
EDIT 3: Ma le Collection non le potete usare, invece di andare con i vettori multidimensionali statici? Java da quel punto di vista è iperflessibile!
non provo neanche a proporglielo... :fagiano:
jappilas
11-10-2006, 18:13
vecchio ordinamento!
...ed elasticità mentale 0 della serie: "Ho sempre fatto così...e siccome va bene non c'è motivo di cambiare! ...e neppure di vedere se c'è qualcosa di nuovo e più funzionale!"
anch'io sono vecchio ordinamento , ma da quando è stato aperto questo thread sto pensando che al posto del tizio avrei buttato a mare il codice e lo avrei riscritto con delle sane interfacce... :p
a te è capitato un ingegnere che si è affezionato al codice , non suo peraltro ... uno dei primi errori da evitare :D
Quello non è codice sorgente: è una richiesta d'aiuto. In 12 anni che uso Java non ho mai visto un metodo restituire un array di array di array di Object e vi assicuro che ho dovuto mettere mano a certe cacche che non avete idea.
anch'io sono vecchio ordinamento , ma da quando è stato aperto questo thread sto pensando che al posto del tizio avrei buttato a mare il codice e lo avrei riscritto con delle sane interfacce... :p
a te è capitato un ingegnere che si è affezionato al codice , non suo peraltro ... uno dei primi errori da evitare :D
Altro che interfacce... Quel codice sembra un programma C fatto male e riportato in Java...
Quello non è codice sorgente: è una richiesta d'aiuto.
:rotfl:
c'è da dire che sto codice non l'ha scritto lui, eppure si ostina a difenderlo!
sarà che è stato scritto seguendo sue indicazioni!
Sarà che hanno seguito le sue indicazioni, ma se il tizio che ha scritto il codice lo ha scritto male, dovrebbe essere compito suo (in quanto direttore tecnico) porre rimedio, di fronte ad un codice che una persona un minimo pratica di Java reputa palesemente inaccettabile. Sennò togliamo di mezzo i direttori tecnici (e affini) e facciamo fare tutto ai programmatori dell'ultima ora...
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.