Newsgroup: it.comp.lang.delphi
Titolo: Alcune domandine

Mi pongo spesso delle domande che non mi impediscono di andare avanti con il 
lavoro, ma che mi lasciano sempre dei dubbi sul fatto di stare agendo nel 
migliori dei modi. Sono tante perchè ho imparato (poco) Delphi per conto 
mio, quindi comincio con queste:
1 - Classi:  se scrivo una classe, è meglio metterla in una unit separata ? 
O meglio raggruppare le classi secondo qualche criterio ? Quale criterio ?
2 - Supponiamo di creare una Lista di stringhe (una TStringList). Mi pongo 
il problema di ricordarmi di distruggere questa lista, visto che non posso 
farlo con un costrutto try finally, dato che dopo che è stata creata, poi è 
utilizzata in più punti del programma allo scattare di certi eventi. E 
quindi la dichiarativa deve essere a livello di Interface (o di 
Implementation) dovendo essere conosciuta da più procedure della unit (se 
non addirittura da più unit). Il free (anzi freeAndNil), lo faccio poi al 
close del Form. E' un modo giusto di fare ?
 
Ringrazio anticipatamente chi mi vorrà dare dei consigli. Se mi direte che 
sono all'abc, lo so già.. 
 

 close del Form. E' un modo giusto di fare ?
 
Dipende dal punto in cui viene creato l'oggetto.
Dovrebbe essere distrutta allo stesso livello in cui viene istanziata.
 
-- 
MARCO BREVEGLIERI
#Home: 
http://www.marco.breveglieri.name
 
#Blog: 
http://www.compilaquindiva.net
 

 close del Form. E' un modo giusto di fare ?
 
Dipende dal punto in cui viene creato l'oggetto.
Dovrebbe essere distrutta allo stesso livello in cui viene istanziata.
 
Grazie intanto di avere risposto. Riguardo alla seconda risposta, supponi, 
come è in almeno un caso, che io crei la TString al Create del Form e poi 
debba utilizzarla quando l'utente esegue un'azione e anche quando esegue una 
diversa azione. Per avere la visibilità della TString in più procedure, pur 
della stessa unit, mi trovo costretto a dichiarare la TString come una var 
globale (a livello di interface o implementation), cioè non posso 
distruggerla allo stesso livello in cui viene istanziata. A meno che non la 
instanzi e distrugga ogni volta che la uso; il che mi parrebbe uno spreco di 
risorse e di tempo, xchè per costruire la lista accedo ad un dataset con una 
query... O a meno che non ci sia un diverso approccio da usare, xchè non è 
solo la lista che dichiaro come globale, ma anche l'informazione che la 
Lista è stata usata almeno una volta (mi serve discernere questo caso..).
Visto che tutti dicono che non si debbono usare var globali, mi preoccupo, 
ma non trovo il modo di fare diferentemente.
 
 

 come è in almeno un caso, che io crei la TString al Create del Form [...] 
 
Ho capito vagamente la tua architettura, ma non è facile darti indicazioni che siano valide in assoluto perché questo dipende da troppi fattori: da quale tipo di informazioni contiene la lista di stringhe di cui parli, da come viene utilizzata, da come è organizzato il resto del progetto, ecc. :|
 
Senza sapere questo, si rischia di darti una soluzione a un problema specifico che non si integra poi bene con il resto dell'architettura.


 2 - Supponiamo di creare una Lista di stringhe (una TStringList).[...]
 > Il free (anzi freeAndNil), lo faccio poi al close del Form. E' un 
modo giusto di fare ?
 
Si. Una buona regola č quella di allocare le risorse che la classe usa 
nel suo costruttore, e deallocarle nel distruttore.
 
-- 
morde
QT 4.7
Delphi (5,6,7.. expired)
Firebird Database
 

 utilizzata in più punti del programma allo scattare di certi eventi.
 
Qua dipende dall'architettura. Generalizzando:
 
 
1) ogni classe sulla sua destroy distrugge  in modo *esplicito* quanto
e' stato creato che altrimenti non sarebbe distrutto.
Ad esempio:
a) se nel mio form uso una  TStringLisst, nella destroy del form ci va
una freeandnil di tale stringlist
b) se nella mia classe creo un qualcosa,  nella destroy del form ci va
una freeandnil del qualcosa
 
2) se ci sono istanze di classi che sonon utilizzate da altre classi,
la strategia in genere e' utilizzare una classe "sessione".
In questa classe, tramite il pattern singleton, vengono istanzaite le
classe che saranno poi utilizzate da tutti.
Ovviamente, ma non per tutti, la destroy di questa classe DEVE essere
l'ultima e nel distruttore va chiamato il distruttore di ogni istanza
di classe da essa creata
 
Aggiungo una cosa che , ERRONEAMENTE,spesso viene data per scontata:
 
1) lavorare OOP e' un "puoi ma non e' detto che devi"
Come gia detto in altre occasioni, trovo lavorare uin strutturato
avendo disponbile il paradigima OOP come cambiare una ruota sollevando
l'auto a mano avendo un crick a disposizione
 
2) si puo scrivere bene sia in OOP che in strutturato
 
3) si puo' scrivere male sia in OOP che in strutturato
 
3) Puoi lavorare OOP o strutturato, ma mescolare le due cose potrebbe
non essere una buona idea
 
4) Se lavori OOP, a monte la domanda e' se una classe e' interfaccia
utente o logica
Se a questa domanda non riesci a rispondere, la classe va BUTTATA VIA
E RISCRITTA.
 
 
Sorvolo sulle madelizioni che ogni 2 secondi lancio ai progettisti di
delphi che hanno implementato anche il kaz di oaradigma
strutturato.....
 
Commercialmente, ovviamente (ma non per tutti..) non potevano non
farlo.
Ma tecnicamente parlando, questo ha permesso che il mondo fosse invaso
da app delphi scritte usando delphi come fosse quella latrina di
vb5/6....
 
Pax vobiscum
 
 
A.

 nel suo costruttore, e deallocarle nel distruttore.
 
Solo una precisazione....
Al solito ci vuole il buon senso.
Se sono certo che quella cosa serve, la creo nel costruttore,
altrimenti la creo al primo tentativo dui utilizzo nel relativo
getter... :-D
Il motivo non richiede spiegazioni.
 
A.

..ovviamente il mio post e' stato scritto on la $define Dislessic Mode
ON...  rotfl! :-D
 
A

 strutturato.....
 
Perche`? Tra l'altro, il paradigma strutturato e` una eredita` del Pascal, 
ovvero Object Pascal (e, di conseguenza, Delphi) e` una estensione del 
Pascal. Eliminarlo a priori avrebbe significato riscrivere l'intero 
linguaggio da zero, cosi` invece si sono ritrovati un linguaggio gia` pronto 
con (all'epoca) una marea di librerie a supporto (senza contare il know how 
preesistente)
 
Enrico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQEcBAEBAgAGBQJPFGACAAoJED3SMOGZLYdYdWYH/A0ix7me23zTeOervGCFMTxg
UxtysSF82w91Ay/tJIzMU/msHBqbq0nH54qAg2id0k3O9T+iUKCymQDPV9fR4FG4
Fne0xTylic5tx7al6J/ls9kVxh1kha2B61S7MCfmWK7+oyil0oOqBXEMCbgKku9k
F9N48XRTenqzgmgiq48sEUCio+DVKV0w6Ya2W1S/ZQLi2K8pa5P19PlTnDMnvY7o
SaVGHA8spGivyv5LF1gBO8O1dlru0Ca+gob4IEl8kMhU+VdT6wBzR8uxtFgL53qM
QZhgPPgc9OFQZDNV4PWpOl+NZTLvwuY0YWcMgQi7+NYCSa08QCX1DZqoMQ4RbqU=
=qoHr
-----END PGP SIGNATURE-----
 

 preesistente)
 
il xche credevo di avrlo spiegato.
Il fatto che PUOI non vuol dire che DEVI.
Se avessi avuto cose sviluppate in pascal, avrei certamente apprezzato
questa cosa.
Ovviamente, se quello che ho funziona, mica sto li a perdere tempo a
convertire il tutto in strutturato.
 
Ma se parto EX-NOVO, usare il paradigma strutturato per me e' un
errore, salvo eventuali eccezioni dove in base al buon senso, si
stabilisce che un approccio OOP sarebbe deleterio. Ma ammetto che da
che uso delphi (1997) non ho mai tozzato su qualcosa di NUOVO che
richiedesse un approccio strutturato.
 
A parte cio', magari tu 6 uno dei fortunati ai quali non e' mai
capitato di mettere mano a codice delphi NUOVO, sviluppato non in OOP,
sul quale dover fare re factoring...Nel caso, beato te! :-D
 
A.

 sul quale dover fare re factoring...
 
A volte capita anche di dover mettere mano a codice Delphi che non usa procedure e funzioni, ma che segue il paradigma "Object Disoriented Programming"... ;)
 
Io penso si possa essere chiari ed efficaci con entrambi i paradigmi, o con una loro mescolanza, purché si riesca ad essere chiari, uniformi e descrittivi.


 A volte capita anche di dover mettere mano a codice Delphi che non usa procedure e funzioni, ma che segue il paradigma "Object Disoriented Programming"... ;)
 
 
rotfl! :-D
 
 
 
A.

 Ovviamente, se sono tutte in una sola unit, le cose sono equivalenti.
 
Sì, è quello che volevo dire io. :)
 
Tant'è che nelle implementazioni "Prism" e "Delphi.NET" le procedure e le funzioni delle "Unit" diventavano automaticamente membri statici di una classe (anche se non voglio ovviamente dire che sono la stessa cosa, soprattutto in ambiente "nativo").


 Alberto Salvati wrote:
 
Alberto continuo a non leggere i tuoi post: ho disiscritto e re-iscritto 
il ng, scaricato di nuovo tutti i messaggi e niente da fare, non ci sei.
Non è che stai usando degli headers particolari?
Vorrei capire se è un problema del server news che sto usando o cos'altro...


 Vorrei capire se è un problema del server news che sto usando o cos'altro...
 
Hanno messo un check:
 
if (op = 'alberto salvati') then
begin
  exit
end
else
begin
  AddPostToNg()
end;
 
 
:-D
 
A.

 ad avere metodi statici di una classe.
 
Il discorso di performance varia da linguaggi a linguaggio (e.g. java 
inizializza ogni chiamata statica al momento della inizializzazione della 
classe). A livello di strutturazione del codice, pero`, direi che e` bene 
separare le parti puramente operative da quelle a stati. Ed in questo 
contesto il supportare piu` paradigmi e` da considerare come punto di forza 
e non come sinonimo di confusione
 
Enrico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQEcBAEBAgAGBQJPF0n9AAoJED3SMOGZLYdYw6YIAIFTaDnRiUFT2CgwltSNi/dr
+oKtCaJ6QX508esrj7/+q9c3cY1n65PbHsB6aeiqzCXiSM8U56z9QSgoPYbYEBqs
FiSYbAYo9Trelzc+xGNNF/tCYHOKgN8Kc70KeHtC2e4xmT86yKMHfO2rH8bcZiDF
xqYc5Noigr3WVzg91Fx3loilrRtYsVQ2DNVsGv74QM7pXnG4tdWsHBzFGfiJ+Vdi
cm7WDEas3EDYssyipt34Ual+17B+ys1hE9lYu6Mnny26CHzd4C94uf7cdgIG47t+
FUl485uXgWsrjORS/gHaZvuP4PICzOidmGM706CB0o0d5xXnyPy7z6S47TcZ98g=
=QMwO
-----END PGP SIGNATURE-----