Newsgroup: it.comp.lang.delphi
Titolo: Modularizzare applicazioni delphi con i package

Salve a tutti ho bisogno di qualche consiglio...vorrei appunto, come
nel titolo del post, modularizzare la mia applicazione utilizzando i
package solo che purtroppo sono incappato in un problema...il mio
intento era quello di inserire ogni form della mia applicazione in un
package distinto x poi caricarli tutti con l'opzione "build with
runtime packages". Il fatto è che ogni unit si riferisce all'altra
tramite la clausola "uses" quindi quando carico la unit nel package
importa implicitamente (banalmente) tutte le altre e il programma non
parte xke ho unit "duplicate"! Non posso far a meno di riferirmi alle
altre unit (credo...) anche xke altrimenti avrei i miei form
completamente isolati gli uni dagli altri! Spero proprio che mi sfugga
qualcosa in tutto questo e che qualcuno mi possa consigliare e darmi
una mano...Spero di essermi spiegato bene...detto questo in che modo
posso modularizzare la mia applicazione?
Grazie a chi vorrà rispondermi
Simone

 runtime packages". Il fatto è che ogni unit si riferisce all'altra
xche prp un form x package?
A.


piu che altro era un esempio x spiegarmi meglio...possono anche
andarcene di piu di una non è una condizione fissa. in poche parole
quello che volevo fare io era suddividere il mio programma in parti
attraverso i package...esempio: la parte della registrazione dell app.
in un pkg, la parte di accesso al programma con password in un altro e
cosi via...anche perche suddividendolo in moduli potrei fare gli
aggiornamenti su parti del programma e distribuire solo il nuovo
package senza distribuire sempre l'eseguibile...anche se qualche tipo
di modifica comporta anche la ricompilazione dell'eseguibile, xo credo
che in linea di massima sia come ti ho descritto...hai qualche
suggerimento da darmi?
Simone

 package senza distribuire sempre l'eseguibile...
..e cosa cambia nel mandare uno o piu' package invece di un exe? Dove
sta il vantaggio?
A.

 sta il vantaggio?
Se mandi il singolo package, tendenzialmente il pacchetto di 
aggiornamento � pi� piccolo rispetto all'eseguibile monolitico.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

 sta il vantaggio?
Lavoro e sviluppo in Team ?  Meno memoria massima richiesta ?


certo è quello il vantaggio, le dimensioni l'eseguibile si riducono
notevolmente e in ogni caso avere un applicazione divisa in package mi
sembra una soluzione molto piu pulita, una concezione di
programmazione piu pulita secondo me. no no nessun team. mi piacerebbe
passare a creare programmi suddivisi in package xke mi sembra un modo
piu "ordinato" di programmare (almeno secondo me) ma come ogni cosa
nuova sono incappato nel problema descritto sopra...come trovo il modo
di procedere x questa strada?
Simone

ho visto anche l'uso delle dll x questi problemi, ma caricare dei form
nelle dll crea problemi di sincronizzazione xke si vengono a creare 2
oggetti Application...in generale è molto consigliato l'uso dei
package x trattare i form o i componenti in genere, le dll possono
essere una soluzione se si parla di funzioni e procedure. pero poi si
vengono a creare questi problemi che invece di rendermi la vita piu
"facile" me la complicano...vi scrivo anche x avere una spiegazione
che mi aiuti a comprendere meglio il concetto di modularizzazione di
una applicazione, x avere un'idea piu chiara della strada da prendere.
i package sono fatti apposta x questo ma dai problemi riscontrati mi
sembra che è proprio questo che non si possa fare!
grazie
Simone

 aggiornamento è più piccolo rispetto all'eseguibile monolitico.
quindi uno si complica la vita per mandare un paio di megabytes in
meno, Marco?
E' tutto qui? :-|
A.

 programmazione piu pulita secondo me.
Quindi, spezzettare e' pulito a prescindere dalla sua effettiva
necessita'?
A.

 Meno memoria massima richiesta ?
Quanto costa mettere insieme una app divisa in packages?
Se costa MENO di qualche modulo di memoria, se ne potrebbe parlare.
In caso contrario, non so.
Ovviamente questa tecnica non deve essere un modo pert mettere le
pezze a codice che alloca le risorse di un cray all'avvio e le
rilascia 2 anni dopo che la app e' stata chiusa....
A.


ma la mia intenzione non è complicarmi la vita, è anche imparare un
modo per impostare un applicazione in modo diverso, poi starà a me
vedere i vantaggi dall'uso dell'uno o dell'altro...e poi il vantaggio
non sta tutto nei 2 mega in meno ma nel riutilizzo di codice che non è
poco. il package strutturato come intendo io e portando il codice ad
un certo livello di generalità posso utilizzarlo come un vero e
proprio componente decidendo di "montare" un pezzo in piu alla mia
applicazione o di "smontarlo" con molta semplicita, semplicemente
rimuovendo il package dalla lista dei pkg usati a runtime...non mi
sembra un vantaggio da poco. ma tutto sta a riuscire ad usare ed
integrare tra loro sti package in modo corretto.
Simone

 E' tutto qui? :-|
Dipende dalla complessit� del tuo software o dalla "modularit�" che 
desideri ottenere.
La possibilit� di aggiornare un solo pezzo dell'applicazione, oltre alla 
questione delle dimensioni, si porta dietro anche tutti i vantaggi 
correlati a questo tipo di organizzazione (es. aggiornamento di parti 
condivise da pi� programmi Delphi, minore dimensione dei file, 
possibilit� di caricarli dinamicamente per sostituire parti 
dell'applicazione in base al cliente e/o alla licenza e/o ad altro, 
condivisione di codice tra pi� package differenti che vi fanno 
riferimento, ecc.).
Sono gli stessi vantaggi, per fare un esempio, che hai nella creazione 
di assembly in ambiente .NET (con cui mi sembra che tu abbia lavorato e 
quindi sai sicuramente di cosa si parla).
Non saprei descrivere la cosa meglio di cos� (troppo lavoro, poca 
concentrazione e periodo di scarsa fantasia e "mente locale"). :)
Ciao,
   Marco.


 Quanto costa mettere insieme una app divisa in packages?
In assenza di elementi di ulteriore complicazione, in genere basta 
mettere il segno sulla spunta "Build with runtime packages" :)(oltre a 
distribuire poi i package da cui dipende l'eseguibile, che diventano a 
quel punto indispensabili al funzionamento del programma e devono essere 
reperibili al momento del lancio, a meno che non vengano caricati 
dinamicamente dalla logica del programma stesso).


 dinamicamente dalla logica del programma stesso).
si si l'eseguibile dipende dai file .bpl che devono essere sempre
reperibili x poter lanciare l'applicazione. ma infatti ho fatto delle
prove banali con un paio di form e la cosa funziona...ma fino a che
punto...unit1 e unit2, quest'ultima caricata nel pkg, check dei
package runtime spuntato e aggiunta del package1...
 1)unit1: uses unit2;
 2)unit2: uses unit1;
...ci siamo funziona. adesso nuova, unit3 che relaziona con la unit2.
aggiungo la unit3 al package1, compilo...
 1)unit1: uses unit2;
 2)unit2: uses unit1, unit3;
 3)unit3: uses unit2;
...benissimo funziona. nuova, unit4 che relaziona questa volta con la
unit1, questa volta creo un nuovo package, package2 compilo e
aggiungo...
 1)unit1: uses unit2, unit4;
 2)unit2: uses unit1, unit3;
 3)unit3: uses unit2;
 4)unit4: uses unit1;
eseguo ed ecco la sorpresa...l'eseguibile neanche si lancia. cosa
succede...il package1 contiene la unit3 e 2 che carica implicitamente
la unit1 che a sua volta si trascina la unit4. il package2 contiene la
unit 4 che carica implicitamente la unit1, che carica la 2, che carica
la 3...come è evidente le referenze sono "chiuse" e si finisce per
avere entrabi i package con unit duplicate e chiaramente il programma
non parte. i package quindi non ammettono referenze "chiuse"...ma
adesso mi domando...in un grosso programma è inevitabile avere questo
tipo di referenze, alla luce di quanto detto com'è possibile che i
package siano adatti a modulare grandi programmi? in che modo vanno
usati x ottenere la modularizzazione di un applicazione? è questo che
proprio non riesco a capire...spero che qualcuno di voi mi possa dare
dei chiarimenti.
Grazie a tutti
Simone

 dei chiarimenti.
Non � vero che l'incrocio delle referenze � inevitabile, anzi andrebbe 
proprio evitato, oltrech� impedire la compilazione quando riguarda le 
interfacce pubbliche delle stesse unit.
Quando hai due elementi che si referenziano a vicenda, probabilmente la 
soluzione migliore � spostare la parte in comune in una terza unit, e 
aggiungere un riferimento a questa nelle unit che la utilizzano, 
costruendo classi base e interfacce per evitare di creare legami troppo 
stretti tra le classi, a maggior ragione se ci sono riferimenti 
circolari. :)


 integrare tra loro sti package in modo corretto.
Qua si deve aprire una piccola parentesi.
Prima di "pacchettizzare" si deve progettare e implementare come si
deve ogni singolo componente.
Per prima cosa, va separata in modo netto, drastico e senza alcuna
pieta, la logica business dalla gui.
DOPO, si pensa a come creare pezzi piu' complessi (packages o altro)
riutilizzabili.
A.

 A.
quindi la soluzione è questa...eliminare tutte le referenze circolari
e attraverso classi ed interfacce far in modo di ridurre i legami al
minimo e progettare la mia applicazione gia a monte separata in ogni
sua parte x poi svilupparle successivamente...gia. adattare un
applicazione che funzioni in moduli quando questa è nata x essere un
"unico blocco" è un operazione abbastanza macchinosa a quanto
pare...anche perche non ho creato classi mie, semplicemente uso i
componenti delphi x creare la mia applicazione.
Simone

 componenti delphi x creare la mia applicazione.
Se l'applicazione � stata sviluppata senza avere in mente 
un'architettura che renda il pi� indipendente possibile le classi l'una 
dall'altra, � senz'altro difficile modificarla in questo senso e, 
probabilmente, sarebbe pi� rapido riscriverla.
Questo non ha comunque a che fare con l'usare componenti Delphi o 
sostituire questi con proprie implementazioni, ma pi� con il modo in cui 
vengono usati.
Approfondisci ad esempio il pattern MVP (fai qualche ricerca) per vedere 
come � possibile sviluppare applicazioni tenendo separata la logica di 
"business" da quella di presentazione (interfaccia utente) e dal modello 
per l'accesso e la memorizzazione dei dati.
Il tuo ostacolo non � il fatto di aver usato componenti Delphi, ma pi� 
probabilmente di aver legato in modo eccessivo questi componenti al 
modello di accesso ai dati e all'interfaccia, rendendo insostituibile 
ciascuna parte con un'implementazione differente e creando cos� legami 
molto stretti tra le classi.
Ciao,
   Marco.


 molto stretti tra le classi.
E' proprio cosi, non ho concepito le mie applicazioni in modo da
poterle divedere in moduli ed è per questo che ho le mie difficolta
adesso, anche xke non pensavo che sarei ricorso a questa soluzione,
quindi mi sono concentrato sullo sviluppo dell'applicazione piuttosto
che della sua struttura. cmq i tuoi anzi i vostri consigli mi hanno
chiarito abbastanza le idee e farò le ricerche che mi hai suggerito e
seguirò le vostre indicazioni xke davvero mi attira molto l'idea di
creare programmi che possano essere montati e smontati come "puzzle"!
chiaramente questo metodo cercherò di adottarlo sulle applicazioni
future, come dire...quello che fatto è fatto, andiamo avanti! :-)
grazie 1000 del vostro tempo e dei vostri consigli!
Simone