Newsgroup: it.comp.lang.delphi
Titolo: dubbio sulla visibilita delle variabili

Ciao a tutti,
proveniendo dal c++ accedere alle variabili private di un'altra classe 
era una cosa piuttosto anomala. Vi era la parpla chiave friend ce 
serviva a legare due classi indipendentemente dalla modulo in cui erano 
dichiarate.
In delphi ho scoperto che le variabili sono pubbliche/private/protette 
solo se si ragiona in unit differenti, poiche all'interno della stessa 
unit sono sempre pubbilche (anche se recentemente sono stati aggiunti i 
modificatori strict protected e strict private)
A questo punto mi chiedo e chiedo agli utenti piu' esperi del NG quando 
l'accesso ad un campo di un'altra classe dichiareto private e' buona 
cosa (all'interno della stessa unit) e quando questo e' da evitare
Di solito lo faccio con degli oggetti collgati (conatiner - part ) la 
parte puo accedere al cuo container e viceversa... ma magari i sono 
altri ambiti.....
dopo tutto anche Java a le variabili private i Package che non ho mai 
capito fino in fondo.....
ringrazio chiunque mi puo' dare qualche suggerimento
Giuseppe

 cosa (all'interno della stessa unit) e quando questo e' da evitare
Dato che io tendo, per buona regola, a creare un rapporto uno a uno tra
classe e file che la contiene, il problema non si pone. Da questo punto di
vista, Java offre un valido insegnamento (questo è un punto nero della
VCL). In ogni caso, è una regola da evitare, ma che può tornare utile per
sopperire temporaneamente a sbagli d'architettura. Ci sono linguaggi in
cui è stata fatta la scelta, intelligente, di non avere nulla di privato.
In Python tutto è pubblico, per esempio, mentre, per convenzione, i membri
e i metodi che iniziano per underscore (_) si considerano privati.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

cui è stata fatta la scelta, intelligente, di non avere nulla di 
Non la chiamerei "intelligente", ma "pigra". Rende solo più difficile 
una corretta incapsulazione e invoglia metodi di programmazione pigri. 
Basarsi solo su convenzioni ortografiche per decidere cosa è visibile e 
cosa no ad un determinato livello di scope è facilmente soggetto ad 
errori, senza check del compilatore (e ricorda orrendamente il basic e i 
suoi prefissi per il tipo della variabile).
--- posted by geoForum on 
http://www.delphiedintorni.it

 errori senza check del compilatore 
..ma quando mai! Vorrei sapere quante volte il compilatore blocca il
programmatore perché sta accedendo a variabili o metodi privati.
Praticamente mai. I programmatori si limitano a gestire e invocare ciò che
è public nell'interfaccia della classe. Ovvero seguono la convenzione.
Sorprendentemente, lo stesso si fa se il sistema non gestisce dei vincoli
rigidi, ma consente di invocare anche un metodo privato che, per errore, è
stato progettato a quel modo. E io ho sperimentato in un progetto reale
quanto linguaggi come C++ e Delphi fossero inefficaci da questo punto di
vista. Se tu conoscessi il mondo di Python, ugualmente sorprendentemente
ti accorgeresti di come i tanti programmatori in quel linguaggio scrivono
codice sicuramente meno error-prone di altri e molto più corretto dal
punto di vista progettuale.


punto di vista progettuale.
Lo sento dire di ogni nuovo linguaggio... almeno dal Pascal in poi.


 Lo sento dire di ogni nuovo linguaggio... almeno dal Pascal in poi.
Ma a quanto pare non ti sforzi di appurare se quello che gli altri dicono
è vero o meno, studiando il nuovo linguaggio all'occorrenza.
Parlare di ciò che non si conosce è veramente biasimevole.


Parlare di ciò che non si conosce è veramente biasimevole.
Appunto. Non mi conosci. Cercare di dare dell'ignorante a qualcun altro 
per imporre le proprie idee è veramente biasimevole. Ho i miei buoni 
motivi per criticare sia Java che Python, se fossero la soluzione 
definitiva ai problemi di sviluppo staremmo tutti usando solo quelli...


 definitiva ai problemi di sviluppo staremmo tutti usando solo quelli...
Python non lo conosci di sicuro e si vede. Poi, io non ho mai detto che
Java e Python siano la soluzione definitiva ai problemi, è una tua libera
ed errata interpretazione di cui non mi meraviglio. Aggiungo, comunque,
che se Java e Python non sono la soluzione definitiva, non lo sono neanche
Delphi o C++ o C# o qualunque altro linguaggio. Quello che conviene fare è
cogliere i migliori aspetti dell'uno e dell'altro e crearsi le proprie
regole.
Se a te piace programmare in un certo modo, sei libero di farlo, ma quando
ti opponi ostinatamente a qualcosa come stai facendo in questa
circostanza, assicurati almeno di conoscere bene gli argomenti.
Io rinnovo all'OP i consigli iniziali e siccome la discussione ha perso
qualsiasi interesse per me, chiudo qui.


qualsiasi interesse per me, chiudo qui.
Vediamo se ci riesci...


 classe e file che la contiene, il problema non si pone.
Vanno saggiamente separati capri e cavoli
Se devo fare il classico esempio di classe Persona, Studente, Padre... 
allora mi è comodo fare tutto in un unico file
Se devo fare la classe Studente e quella MacchieMovimentoTerra allora faccio 
due file distinti
Se devo fare 3 classi che servono solo per un progetto e sono fessacchiotte 
metto tutto in un file
Se devo fare una classe enorme che gestisce un lettore di SmartCard a basso 
livello magari cerco di suddividerla in sottoclassi più semplici
Discorso diverso il FriendShip automatico delle classi che stanno tutte 
nello stesso file ma su questo sembriamo tutti daccordo 

 metto tutto in un file
Il concetto di "classe fessacchiotta" mi č del tutto estraneo.


 Il concetto di "classe fessacchiotta" mi è del tutto estraneo.
Una classe con un paio di metodi semplici semplici
Ad esempio in un progetto che abbiamo al lavoro abbiamo bisogno di varie 
liste di oggetti
Per evitare di fare la lista con TList in cui puoi buttarci di tuto e 
castare e ricastare quello che metti e prelevi dalla lista col rischo di 
metterci qualcosa che non ci azzecca abbiamo derivato da TList un paio di 
liste particolareggiate una pr i Canali, una per i Carrier e via dicendo
Chiaramente sono oggetti fessacchiotti perché hanno giusto i metodi Add, Pop 
e un altro paio che sono poco più che semplici override dei metodi che già 
ha TList
Le classi stanno tutte in uno stesso file
Il bello comunque è che ognuno alla fine fa come gli pare 

 Una classe con un paio di metodi semplici semplici [...]
Quando ho avuto a che fare con classi di questo tipo, non è trascorso 
molto tempo prima che la classe "fessacchiotta", con un paio di metodi, 
finisse per averne parecchi di più. :-)
In merito alla "questione centrale", credo che in fondo ognuno possa 
adottare l'approccio che preferisce; per me è fondamentale "separare le 
cose", certo, e limitare le dipendenze tra le classi al minimo, che non 
vuol necessariamente dire "usare un file differente per ciascun tipo di 
dato", ma nemmeno ammassare più delle classi che servono nello stesso 
file (tant'è che nel caso di "iteratori", li definisco all'interno della 
classe stessa).
Ciao,
   Marco.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)