Newsgroup: it.comp.lang.delphi
Titolo: Programmazione modulare

Come funziona la programmazione modulare in Delphi?
Grazie per l'attenzione.
--
Chrys-bj
http://digilander.iol.it/chrysbj

 ha scritto nel messaggio
news:XuOK6.2518$cU2....@news1.tin.it...

Bellissima la domanda, difficilissima la risposta. Il post sarà lungo,
naturalmente.
La programmazione modulare in Delphi eh?
Uhm... dunque... dipende da cosa intendi.
Tu già la usi normalmente, perché ogni unit è un "modulo".
Però esiste un modo consapevole ed uno inconsapevole per usare i moduli.
Nel senso che ogni modulo deve essere dipendente il meno possibile dagli
altri e deve essere "coeso", vale a dire che tutto ciò che si trova in un
modulo deve seguire un "tema" dominante.
Per esempio, diciamo che stai sviluppando un'applicazione di crittografia,
ok?
Avrai un modulo che contiene la form principale, un modulo per crittografare
dati, uno per decrittografarli, più moduli aggiuntivi - ad esempio - per
l'impostazione delle opzioni. Poi potresti avere un modulo per
l'integrazione di plug-in ecc. E questa è una prima possibile definizione.
Poi un modulo può essere anche una DLL o un package che implementano un
plug-in, o un'estensione di sistema( solo DLL ).
Ancora può essere un controllo ActiveX, insomma un modulo può essere tante
cose... :=)
Credo di averti dato una panoramica generale abbastanza completa, magari ho
dimenticato qualcosa però.
Opinioni?
Andrea

Forse mi sono espresso male:
Facciamo finta che io debba fare un classico gestionale: Ordini e Articoli.
Io ho bisogno di avere una persona che mi implementa la gestione degli
articoli ed un'altre che mi implementa gli ordini, io magari nel frattempo
faccio un programma che gestisce i clienti, come possono coesistere i
programmi in un'unica applicazione? Tenendo ovviamente presente che tutti
programmano contemporaneamente.
Purtroppo io sono fondamentalmente un programmatore Cobol e sono abituato a
lavorare con oggetti divisi che vengono chiamati da dei menu. E non so se
qui funziona allo stesso modo oppure no e se si come si fa a chiamare un
programma e se questo può fare parte di un form MDI.
Ciao e grazie a tutti.
--
Chrys-bj
http://digilander.iol.it/chrysbj

programma e se questo può fare parte di un form MDI.
MDI scordatelo, credo proprio che stia andando a morire...
--
Walkie...@Libero.It (ICQ# 8143647)


Non sono tanto d'accordo (non ti arrabbiare pero' :-)  )
1) moltiplichi le connessioni al database
2) non garantisci un'eventuale transazione unica se vuoi lavorare
contemporaneamente su piu' form e vuoi fare un unico commit.
Ciao, Rocco.
Rocco Barbaresco:
Herrare Humanum Est,
Perseverare Ovest ....
(By Fichi D'India)

Grazie per i primi aiuti, ma vorrei sapere la soluzione di chi dice che non
č una buona soluzione quella di Talkie.
Cosa suggerisce Rocco?
--
Chrys-bj
http://digilander.iol.it/chrysbj

 ha scritto nel messaggio
news:BuRK6.3936$Rc5....@news2.tin.it...



Tutto qui il problema? :=)
Scusami, ma non potete scrivere ognuno i propri form su un diverso computer
e poi integrare tutto insieme? :=)
Andrea

 ha scritto nel messaggio
news:JyRK6.3952$Rc5....@news2.tin.it...


 Si, si riesce? Ma è una soluzione adottata da molti?
E' una soluzione normalissima... :=) E' adottata quotidiananmente da
migliaia di programmatori... :=)
Bisogna dire che generalmente si fa uso di tool di coordinamento, ma se
ognuno lavora su un modulo ben preciso e nessun'altro tocca quel modulo, non
ci vuole nemmeno quello... :=)
Andrea

>Si, si riesce? Ma è una soluzione adottata da molti?
Sicuramente è una soluzione FACILE ed adottata da tutti quelli che
lavorano in gruppo con Delphi.
Ti suggerisco di usare un programma per il Version Controlling di nome
FREEVCS (
www.freevcs.de
).
Questo è totalemente free ed è incredibile, utilissimo e molto
stabile.
Francamente non capisco perchè la borland non sia in grado di fare
qualche cosa di simile......
Ciao.


Dunque io andrei con fiducia verso questa soluzione.
Si, sono d'accordo, anche se separerei la logica di accesso ai dati
dalle vere e proprie form. Comunque il concetto è:
un insieme minimo di unit, form e datamodule comuni dove si
centralizzano gli accessi, ed una serie di altre unit, form e dm che
ognuno sviluppa per proprio conto e poi condivide con gli altri.


tutt'altro che economico.
Quale sincronizzazione ???
--
Walkie...@Libero.It (ICQ# 8143647)

contemporaneamente su piu' form e vuoi fare un unico commit.
Non credo sia il tipo di applicazione che lo richiede.
--
Walkie...@Libero.It (ICQ# 8143647)

 Walkie...@Libero.It (ICQ# 8143647)


Andrea

Non credo sia il tipo di applicazione che lo richiede.
tutte le applicazioni serie richiedono delle transazioni, scusa ma
sono completamente d'accordo con R. Barbaresco, unico DM (unica
connesione e unica transazione) e eventualmente sviluppare le *form*
separatamente in team... ogni form ha la sua unit ("modulo")
Ciao,
Alan Solo

 applicativi da qualche centinaio di K l'uno.
Scusate ma l'argomento interessa anche me...
come fate con un unico programma a gestire le personalizzazioni
dei clienti e contestualmente l'aggiornamento del pacchetto base?
Io utilizzo il metodo dei tanti eseguibili (centinaia ormai) e una
gestione simile a quella degli AS400 cioč con una lista delle
librerie con una libreria standard e una di personalizzazioni.
Se lancio un punto a menů prima cerco la versione personalizzata
e poi , se non c'č, quella standard.
La cartella "standard" viene sempre aggiornata mentre le
personalizzazioni restano alla versione originaria.
In piů dell'AS400 ho preso anche la gestione ad "Azioni"
per la riservatezza e l'impostazione di paramentri (molto utile).
Se Delphi avesse una cosa simile al make del C (per quel poco
che ne so) avrei potuto condizionare non l'esecuzione ma la
compilazione.
Mirko

Un approccio un po' diverso potrebbe essere quello di realizzare
l'applicazione con una serie di componenti COM, ognuno specializzato in un
compito preciso e realizzabile come dll autonoma.
Il sistema comporta un notevole lavoro di concettualizzazione da fare prima
di iniziare a programmare altrimenti rischi di trovarti in una selva di
componenti con funzioni poco chiare e spesso sovrapposte.
In particolare è molto delicata la separazione del livello di accesso ai
dati dalle funzioni di presentazione e dalla logica di business, se si
riesce a costruire un buon modello ad oggetti si ha il vantaggio di non
dover mai riscrivere lo stesso codice due volte e di dividere facilmente il
lavoro. Per la gestione delle transazioni non hai difficoltà se tutte le
funzioni di accesso ai dati sono gestite da un unico componente, se però il
programma è complesso e devi utilizzare più componenti di accesso ai dati
sei costretto a gestire tutto con MTS.... e forse non è il caso di andare
così avanti.
Pensaci in realtà non è così complicato come sembra.

Come quale sincronizzazione?
Non vedo proprio che problema sia, se il programma e' strutturato in
moduli eseguibili separati.
--
Walkie...@Libero.It (ICQ# 8143647)

dei clienti e contestualmente l'aggiornamento del pacchetto base?
Difatti io ritengo che la costituzione di un programma in moduli
eseguibili separati sia la forma + corretta con cui vada sviluppato.
E', credo, il grado massimo di modularita'.  Rimango convinto di
questa idea, visto che mi ci sono trovato bene anch'io.
--
Walkie...@Libero.It (ICQ# 8143647)

separatamente in team... ogni form ha la sua unit ("modulo")
Non vedo dove sia il problema, onestamente.
Generare un'applicazione che ha tanti form MDI equivale a scrivere
un'applicazione per ogni modulo che sia attiva ad esclusione delle
altre.  In questo caso la connessione al DB sara' sempre e solo una.
*Nessun* carico inutile e sbagliato del server.
--
Walkie...@Libero.It (ICQ# 8143647)


No, scusa ma non credo di aver capito:
stai forse dicendo che l'attivazione di una applicazione sconnette
qualsiasi altra dal database (in modo da avere una sola connessione
attiva alla volta?)


 ha scritto nel messaggio
news:3b00f496...@news.inet.it...



Io personalmente userei altri metodi (ovviamente per scendere nello
specifico bisognerebbe conoscere bene l'applicazione), ma in linea
generale userei:
possibilità 1:	delle DLL;
possibilità 2:	creazione dinamica di classi (magari leggendo le
configurazioni dal DB) che svolgono il lavoro specifico (l'approccio
che preferisco)
possibilità 3:	oggetti com (in pratica un misto dei due metodi
precedenti)
Ciao, Rocco


Certamente crea un grande eseguibile (anche se bisogna capire cosa
vuole dire il grande), ma non vedo dove sia il problema. 

 ha scritto nel messaggio
news:3b00fb09...@news.inet.it...


cercando di imparare i trucchi di questo stile di programmazione.
Questo è un argomento certamente interessante ma anche complesso.
Vediamo un po' se riesco a non dire troppe stupidaggini (almeno ci
provo :-;  )
Uno degli approcci (fortemente OO) a questo tipo di problematica
(grossa applicazione che fa un uso massiccio di dati salvati su un db)
è quello che prevede la divisione del programma a "livelli". Si
distinguono quindi il livello di accesso ai dati, quello di
manipolazione dei dati (bussines rules) e quello di manipolazione
dell'interfaccia grafica. Una divisione in questi tre livelli permette
di identificare chiaramente il sottoproblema che sto affrontando e di
risolverlo senza stare a preoccuparmi di cosa succede negli altri
livelli. Esiste tutta una schiera di programmatori (tra cui me) che
crede che un approccio del genere risulti alla lunga più facilmente
mantenibile, più chiaro ecc. rispetto ad un'approccio piu' RAD del
problema. Ovviamente il punto focale diventa il livello intermedio,
ovvero quello delle bussines rules. In questo livello vengono definite
delle classi (generalmente ereditate da classi base che  contengono la
logica comune) che gestiscono tutti i dati del problema. Purtroppo non
mi è facile spiegare in modo piu' chiaro (credo di essere stato
abbastanza criptico...). Ti consiglio pero' di osservare i numerosi
messaggi presenti su questo argomento presso il newsgroup della
Borland: borland.public.delphi.oodesign.
Con questo non voglio certo che tu scappi da questo newsgroup, anzi.
Voglio solo darti la possibilità di leggere info molto interessanti
per poi, magari, parlarne qui con gli altri.
Ciao, Rocco

attiva alla volta?)
Generalmente un utente utilizza un modulo alla volta, non tutti
insieme ed ha quindi attiva sempre una sola connessione al db.
--
Walkie...@Libero.It (ICQ# 8143647)

cosa intendete per sviluppare delle classi.
COM sta per Component Object Model.
E' un modello a compartimenti stagni, oggetti che hanno, cioe' una
compatibilita' binaria tra essi.  Questo vuol dire che scrivere un
oggetto in un linguaggio assicura che esso sia utilizzabile anche da
altri linguaggi.  Attualmente se scrivi una classe in C++, non puoi
istanziare oggetti di quella classe in Delphi (e viceversa).
Lo stesso vale se si combinano tra loro diversi linguaggi.
COM, invece, rappresenta un modello e una specificazione binaria su
come due oggetti scritti in linguaggi diversi possono colloquiare tra
loro.  Ti consiglio, se vuoi approfondire l'argomento, "Essential COM"
di Don Box (e' un po' vecchiotto ma qualcuno ha giudicato "Nobody
explains COM better than Don Box" e la stessa frase e' riportata in
copertina ;)).
--
Walkie...@Libero.It (ICQ# 8143647)

 grande?
OT...
La ditta dove lavoravo è diventata distributore di una multinazionale di un
ERP
che costa da 30 a 100 mila dollari e ho potuto dare un'occhiata ai sorgenti
(poco, non era il mio settore).
L'interfaccia era quasi costruita al volo sui dati, perfino le etichette di
descrizione
non erano altro che i nomi dei campi fisici sul DB (vedeste che nomi di
campo...);
le ricerche sui campi erano automatiche leggendo le foreign key del campo
stesso.
In più uso di controlli e automatismi a livello di DB (trigger e vincoli
vari sui dati) e
stored procedure.
Il programma base stava in un eseguibile di 2 o 3 MB più delle DLL per i
moduli gestionali aggiuntivi;alla fine non più di 10 MB.
Ovviamente da tutto questo non poteva che uscirne un'interfaccia scarna,
la prima nota sembrava un foglio Excel ma neache fatto tanto bene.
Tutto basato sulla tecnica con 0 cura per l'utente: 120.000 installazioni!
Io perdo ancora metà del tempo a disegnare l'interfaccia :-(
Mirko

*Nessun* carico inutile e sbagliato del server.
allora avevo capito bene, tu veramente fai una nuova connesione al
server ad ogni form aperta??? e come soluzione tu diresti "tanto
l'utente non ne apre piu' di una?
ripeto, secondo me è un modo sbagliato, per molteplici motivi:
- non puoi dire all'utente, puoi aprire una sola finestra (o meglio
puoi ma il programma fa un po' pena ;))
- la connesione al db puo' richiedere anche alcuni secondi, quindi ad
ogni apertura di form devi attendere la connesione
- visto che io all'utente voglio dare piu' libertà (aprire piu' form)
se facessi una connesione per ogni form a) moltiplico le connesioni
con problemi di prestazioni server/client b) se il server SQL ha delle
licenze contate, tu trasformi il "massimo numero di utenti" in
"massimo numero di form aperte"....
secondo me il modo migliore è un unica connesione al DB (per DBE
TDatabase) e poi tutte le query fanno riferimento a quell'oggetto...
eventualmente usare piu' transazioni...
Ciao,
Alan Solo

Io perdo ancora metà del tempo a disegnare l'interfaccia :-(
Se devo essere sincero anch'io. Indubbiamente piu' uno vuole affinare
l'interfaccia grafica piu' deve perderci tempo (tanto tempo
purtroppo.....)



Beato te che hai degli utenti cosě ordinati.
Io ne ho alcuni di derivazione unix che aprono mezzo mondo.
Scusate ma sono stato attirato dall'affermazione.
Purtroppo non posso partecipare tecnicamente alla discussione
perchč non ne so abbastanza. Per lavoro non programmo in delphi.

programmano contemporaneamente.
In questo caso vi conviene mettere l'applicativo sotto controllo di
versione. In pratica usate un tool che permette ad un programmatore
(assegnato al progetto) di bloccare un sorgente (check in), lavorarci
e sbloccarlo quando ha finito (check out). Inoltre il tool mantiene
tutte le modifiche in un database, e cosi' puoi eventualmente
annullare modifiche recenti che non ti soddisfano.
Attenzione: In questo modo il prg non diventa modulare! E' solo +
semplice da gestire in gruppo, ma se poi ogni programmatore ha bisogno
di mettere le mani anche su unit che non gli competono, allora c'e' un
problema di design.
Una volta che ci prendi la mano non ne potrai fare a meno :-)
Ti consiglio di provare FreeVCS: 
www.freevcs.de
 : gratuito,
multiutente e integrato nell'ambiente Delphi.
Ciao
--
Piero Bonanno
bop...@libero.it
pie...@tiscalinet.it
bpie...@hotmail.com
______________________________________________
"Madame, lei ha tra le gambe uno strumento
che puo' offrire piacere a migliaia di persone,
e tutto quello che sa fare e' grattarlo"
- Sir Thomas Beechan a una violoncellista

perchè non ne so abbastanza. Per lavoro non programmo in delphi.
vuoi dire che "non programmi", o che "non programmi in delphi"?
se la risposta è la seconda, allora poco cambia dal tipo di linguaggio
usato... ;)
Ciao,
Alan Solo

 ha scritto nel messaggio
news:=j0EO1iPD19TPm...@4ax.com...


Insomma ogni linguaggio ha le sue caratteristiche.
sì hai ragione, io mi riferivo al fatto di aprire una connesione per
ogni form (schermata.... se vuoi)
infatti la reply era rivolta su quell'argomento,
anche se il subject originario era diverso...
Ciao,
Alan Solo

Alan Solo

volta è un po' ottimistico.
già, cmq è una evoluzione normale dal dos, 8) in windows la comodità è
proprio quella di aprirsi piu' finestre contemporanemente...
Ciao,
Alan Solo

 si riuscirebbe a fare.
OT
Hei, programmi proprio come la mia ragazza; sto Visual FoxPro
è più usato di quanto pensassi...
Dovrò smetterla di prenderla in giro, tanto più che guadagna più di me :-))
Mirko



Continuo OT
Guarda che la tua ragazza utilizza una un linguaggio in cui:
1)  lo scope delle variabili è, come minimo, discutibile.
2)  la ricorsivita limitata a 32 cicli 
3)  le variabili non possono essere piu di 64000 (magari non sarebbero
nemmeno poche, ma un array di 1000 elementi non conta per 1
ma conta per 1000)
4) un puntatore è un concetto inesistente (quindi anche liste od
alberi)
5 ha una spiccata tendenza a dire expression too complex
6 .... qui ci do un taglio, ma delle cose discutibili ne fa molte
altre
Sarà già abbastanza depressa e smaronata dovresti consolarla
invece di prenderla in giro. 

 invece di prenderla in giro.
Sempre OT
Effettivamente programmare le pesa molto, sarà anche per questo...
A dire il vero lei non è molto tecnica (come tanti altri) e alcuni di
questi problemi non credo si accorga neanche di averli (vedi
scope e puntatori); anzi, arrivando dall'RPG400 usare un altro
ambiente indirizzato ai gestionali penso l'abbia aiutata.
D'altronde ha ottime conoscenze contabili.
Comunque il fine settimana la porto in Toscana è le faccio
dimenticare tutto a suon di buon vino e allegria...
Mirko