Newsgroup: it.comp.lang.delphi
Titolo: Ex componenti db-aware

Intervengo da non competente in questioni DBase, ma sull'esigenza formulata
da Bob vorrei trarre  l'occasione per generalizzare la richiesta: dopo anni
di programmazione ad oggetti se qualcuno mi chiedesse cosa desidereresti che
la programmazione ad oggetti avesse e che ora non ha risponderei che mi
servirebbero degli oggetti in cui si possano facilmente sincronizzare delle
variabili (proprieta'). Voglio dire che nella pratica mi trovo spesso a
dover copiare valori di variabili da una proprieta' di un oggetto a quella,
spesso equivalente, di un altro.
Forse sbaglio ma anche nella richiesta di Bob mi e' sembrato di cogliere la
stessa esigenza.
Puo' essere che chi produce codice "dbase" senta di meno quest'esigenza
appunto per la caratteristica stessa degli oggetti dbase-aware di essere
gia' sincronizzati.
Giorgio

 ha scritto nel messaggio 
news:439da696$0$339$5fc...@news.tiscali.it...

Eh no io non intendevo questo ;)
Ma parli di oggetti di tipo identico o diverso?cioč stai parlando di 
clonazione o semplice copia di alcune proprieta?
E quale sarebbe la difficolta'?puoi fare qualche esempio magari... 

Modo1
type
  TClass2 = class;
  TClass1 = class
  published
    property MyIntValue: integer read GetMyIntValue write
SetMyIntValue;
    property LinkedObj: TClass2 read FLinkedObj;
  end;
  TClass2 = class
  published
    property SomeIntValue: integer read GetSomeIntValue write
SetSomeIntValue;
  end;
...
function TClass1.SetMyIntValue(AValue: integer);
begin
  if FMyIntValue <> AValue then
  begin
     FMyIntValue := AValue;
     if Assigned(FLinkedObj) then
        FLinedObj.SomeIntValue := AValue
  end;
end;

 ha scritto nel messaggio 
news:1134406246....@g49g2000cwa.googlegroups.com...


 TrasmAttiva:=Classe1.TrasmAttiva;
Nel tuo esempio rischi di dover sempre "accoppiare" due istanze di classi, 
quindi tanto vale mettere tutto nella stessa classe...
Inoltre, a mio avviso, dal momento che dovesse nascere un'esigenza del genere, 
comincerei a mettere in dubbio la progettazione dell'applicazione.
Ciao,
Gianluca.

 genere, comincerei a mettere in dubbio la progettazione dell'applicazione.
Non mi sembra che fare pulizia nel codice mediante un sistema o l'altro crei 
motivi di dubbi sulla progettazione.
Ciao Giorgio 

 l'altro crei motivi di dubbi sulla progettazione.
Se hai necessità di un legame così stretto (addirittura con l'uso di un oggetto 
globale referenziato in N istanze di classi) tra la stessa proprietà di più 
classi, a mio avviso significa che questa proprietà rappresenta un unico 
concetto: quindi non v'è motivo per duplicarla.
Oltretutto, se hai una istanza di Classe1 globale visibile da qualunque punto 
dell'applicazione, che senso ha copiarne il valore di una proprietà in altre 
classi?
Ciao,
Gianluca.

in altre classi?
Beh questo era proprio cio' che essenzialmente volevo evitare, come scrivevo 
nel mio primo intervento:
troppi richiami di variabili da un oggetto all'altro ossia volevo ottenere 
degli oggetti piu' indipendenti e
autoconsistenti e meno legati ad altri, evitando cosi' anche di doversi 
ricordare in quale oggetto e' contenuta l'una
o l'altra variabile in fase di stesura. Mi sembra che questa caratteristica 
di indipendenza rientri in fondo nella filosofia OOP.
Naturalmente la cosa la applicherei ad un certo numero di variabili, non si 
pensi a numeri elevati.
Ciao, Giorgio 


Io solitamente scrivo dei metodi CopyTo e CopyFrom (da mettere dentro una 
classe di gestione degli oggetti), e al momento delle copiatura uso quelli.
E' vero che in caso di riferimenti ad altri oggetti non si puo' ottenere una 
copia completa(anche perche' variano le pre e post condizioni tra metodo e 
metodo), quindi lascio il resto del lavoro al chiamante.
Il fatto positivo e' che queste chiamate solitamente avvengono in strati ben 
precisi dell'applicazione, cosi' si evita una certa confusione. 

 oggetti non sono solo 2
Tendenzialmente basta estendere un pò l'esempio di Alberto.
Nella più semplice delle ipotesi hai due classi, entrambe con una property 
Active che devi mantenere allineata.
TC1 = class
end;
TC2 = class
end;
innanzitutto devi creare un legame tra le due classi, quindi entrambe dovranno 
esporre una proprietà del tipo dell'altra classe
TC1 = class
private
  fC2: TC2;
public
 property C2: TC1 read fC2 write fC2;
end;
TC2 = class
private
  fC1: TC1;
public
 property C1: TC1 read fC1 write fC1;
end;
supponi di avere due variabili:
c1: TC1;
c2: TC2;
scriverai:
c1 := TC1.Create;
c2 := TC2.Create;
c1.C2 := c2;
c2.C1 := c1;
e qui hai creato un "legame" tra le due classi.
Ora, venendo alla property Active, sarà dichiarata *per entrambe le classi* 
in questo modo
...
private
  fActive: boolean;
  procedure SetActive(const value: boolean);
...
public
  property Active: read fActive write SetActive;
...
end;
e SetActive sarà implementata in questo modo:
procedure TC1.SetActive(const value: boolean);
begin
  if self.fActive <> value then begin      (1)
    self.fActive := value;
    if assigned(self.fC2) then
      self.fC2.Active := value;
  end;
end;
Lo stesso codice, invertendo i nomi delle classi, andrebbe scritto in TC2.
Attenzione al controlli in (1), che impedisce che i due eventi vengano chiamati 
ricorsivamente. Infatti se imposti
c1.Active := true;
avrai, nell'ordine:
c1.SetActive(true);
  c2.SetActive(true);
    fC1.SetActive(true);
che però non prosegue oltre perchè fActive è già stato impostato a true trattandosi 
sostanzialmente della stessa istanza di classe.
Altrimenti, puoi scrivere:
procedure TC1.SetActive(const value: boolean);
begin
  if self.fActive <> value then begin 
    self.fActive := value;
    if assigned(self.fC2) and (self.fC2.Active <> value) then  (2)
      self.fC2.Active := value;
  end;
end;
Dove (2) funziona se hai attiva la direttiva di compilazione per la short 
evaluation.
Questa, come dicevo, è l'ipotesi più semplice dove due classi sono legate 
1-1. Con un attimo di malizia in più si potrebbe pensare di mettere tutto 
il codice necessario al link in una TC0 e derivare da questa TC1 e TC2.
Nel caso in cui le classi siano legate 1-n, direi che una necessariamente 
deve fungere da Owner. Potremmo chiamarla TController.
Definirei poi una classe (astratta o meno, a seconda dell'esigenza) che esponga 
come property Parent di tipo TController, chiamiamola TBase.
TController a mio avviso dovrebbe esporre una TBaseList, in modo che possa 
avere traccia di tutte le istanze di classi di cui è "proprietaria".
Il metodo per impostare il parent in TBase dovrebbe, tra le altre cose, chiamare 
fParent.BaseList.Add(self) in modo da "registrarsi" all'interno del proprio 
controller.
A questo punto la gestione di Active in TBase è pressochè identica salvo 
il fatto di chiamare:
fController.Active := value
La gestione del metodo Active in TController dovrebbe essere estesa in modo 
da ciclare sulla TBaseList ed impostare le singole proprietà Active di tutti 
gli oggetti. Per migliorare le prestazioni adotterei sempre la seconda soluzione 
con il test preventivo del valore della proprietà.
Ciao,
Gianluca

end;
Questo è un pessimo modo di progettare classi.  Un accoppiamento così
stretto produrrà prima o poi sicuramente casini (e oltretutto non
riesco a immaginare un caso pratico in cui possa rivelarsi utile).
Per gestire i casi di classi che abbiano bisogno di reagire ad eventi
che si verificano da qualche parte del sistema esiste comunque un
pattern specifico, che è l'Observer.  Le classi "subscriber" vengono
informate su ciò che accade dalla classe che si occupa di "osservare"
il sistema.

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


Ma come ti viene in mente questa? 

Credo che Gianluca volesse fare solo dell'ironia..
E uno si dà tanto da fare per fare dell'ironia? ;-)
p.s.: "quota" correttamente, please...

 sistema.
I pattern sono un'ottima cosa. Sarebbe anche ottima cosa riuscire a capire 
quando possono essere applicati, quando l'utilizzo di uno specifico "prima 
o poi" potrebbe portare a dei "casini" e quando è necessario provare a crearne 
di propri.
Ciao,
Gianluca.

 Credo che Gianluca volesse fare solo dell'ironia..
Dedotto da cosa?

quando possono essere applicati[...]
I libri sui DP te lo dicono.  Basta leggerli ;-)

 Basta leggerli ;-)
Non posso ch'essere d'accordo.

Preferisco pensare che me lo "consiglino".
Leggi bene.  Tu scrivi: "quando possono essere applicati".
Ripeto: i libri sui DP te lo dicono.
Ovvio che il loro vale come consiglio, qualsiasi manuale di stile ti
dà dei consigli.  Poi ognuno è libero di programmare male.