Newsgroup: it.comp.lang.visual-basic
Titolo: Piccolo primer sulla progettazione OO

Salve,
Visto che la cosa si è fatta pressante, ho deciso di scrivere questo piccolo
post che _spero_ possa servire a dare indicazioni di massima sul mio
modo di vedere la progettazione del software.
Io credo nei "3 livelli", applicazioni cioè scritte a "strati".
In genere questo concetto si applica alle applicazioni database,
ma non c'è molta differenza con gli altri tipi di applicazioni.
Nelle applicazioni db i 3 livelli sono il backend( db ), le business rules,
la GUI.
Quindi fondamentalmente abbiamo 3 "momenti" della progettazione: il momento
della
definizione e delle operazioni di base( db ), il momento della
elaborazione( business )
ed il momento della presentazione( GUI ).
Nella letteratura in materia è frequente trovare opinioni( anche
autorevoli ) che
tendono a trattare il livello delle strutture dati e le operazioni di base
nello stesso
strato delle elaborazioni specifiche del motore. Questo secondo me non è
esatto.
Non è esatto semplicemente perché la lettura di un file di configurazione
non c'entra nulla con la vettorializzazione di una immagine bitmap.
E la lettura stessa di un file non c'entra niente con la presentazione
all'utente
delle opzioni di configurazione. Le cose si devono slegare ( to loosen up )
per poter essere gestibili e manutenibili.
Veniamo ad un semplice esempio, che include tutti i livelli:
Voglio fare un programma che mi fa lo slide-show con effetti
modificabili ed add-ins di tutte le immagini di un disco fisso.
ok?
Qui vediamo vari livelli: il primo è quello della presentazione all'utente
del risultato finale delle elaborazioni. Un altro livello è l'elaborazione
degli effetti speciali. Poi c'è il livello della gestione dei plug-in,
concettualmente intesi come tali. Ancora, c'è il livello dei plug-in
specifici
per l'applicazione.
Infine, c'è il livello di elaborazione del disco e di identificazione delle
immagini.
Tutte queste cose possono essere considerate "staccate" le une dalle altre.
E quindi necessitano di "isolamento" tra loro.
Ci saranno, è ovvio, dei punti di contatto, ma solo come "scatole nere" le
une rispetto alle altre.
Spero di aver un pò chiarito il mio pensiero in merito alla cosa, e di aver
dato spunto per una discussione interessante.
Ciao
Andrea

 E quindi necessitano di "isolamento" tra loro.
Insomma, quello che volevo dire è che il tuo punto di vista (più che
condivisibile) si appoggia solo su di un punto della programmazione:
l'information hiding. Ogni "pezzo" dell'applicazione, infatti, si
"occupa" della sua parte, senza per questo "interferire" con altri. Sono
d'accordo. I punti di contatto, dove esistenti, devono essere chiari e
ben documentati (API).
Però, credo che OOP sia un _metodo_ (appunto) di lavorare ben diverso
dallo stile "procedurale" standard. Per questo motivo alcuni parlano di
"pensare ad oggetti", quando si lavora in ambienti OOP.. per questo
dicono di cambiare mentalità prima di passare alla programmazione OOP.
E lo dico io che di OOP ne so proprio poco ... :)
Ciao,
Marco
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Marco
Ciao
Andrea

 Io credo nei "3 livelli", applicazioni cioè scritte a "strati".
[cut]
Non entro nel merito di cosa sia due o tre strati (Sql-Server copre uno
strato, o, come penso io, ne può coprire anche due?), quanto piuttosto sul
fatto che il subject fosse piuttosto fuorviante.
Parli di modularizzazione del progetto software, non di programmazione
Object Oriented (OO).
Comunque è un post interessante, anche se devi stare attento a non
inchiodarti nella mentalità dei tre strati.
Bella finchè vuoi, ma esiste una versione leggermente modificata, che io
chiamo "due strati e mezzo", e che personalmente preferisco:
Strato 1: DB 'intelligente'
Strato 0,5: Deployment web
Strato 2: Logica e Presentazione
Ooppps, dirai, il deployment non è uno strato!
Beh, vedila così: perchè si stacca la logica dalla presentazione?
Per un motivo molto semplice: Client più leggeri e logica aggiornabile in
maniera centralizzata.
Ma allora, perchè non semplificare di molto le cose, prevedendo uno strato
DB 'intelligente' (ad esempio un Sql-Server, dove oltre al DB abbiamo anche
la logica di business di fondo cablata nelle SP), uno strato di deployment
'real-time' (tipicamente utilizzando VBD o OCX su HTML, e un bel IIS che su
W2k è anche gratuito), ed uno strato di logica terminale e presentazione
(tipicamente sessioni di IE 'vive')?
Vantaggi del 2 strati e 1/2:
Il server è assolutamente scarico. Fa solo deployment, DB Server e logica in
S.P.
Aggiornamento real-time dei client senza intervento CED o utente
Possibilità di esecuzione in locale di accesso a periferiche
Svantaggi del 2 strati e 1/2 (rispetto ad un 3 strati puro):
I client lavorano. Con client molto lofi, le performance ne risentono.
Gli aggiornamenti a metà giornata possono far crashare le sessioni client
Poi, in ogni caso va valutato un approccio o l'altro.
Ciao
Alberto

 Non posso giudicare in merito :)
:D
Marco.


 Marco.
Andrea