Newsgroup: it.comp.lang.delphi
Titolo: costruttore statico e reintroduce.

Salve a tutto il ng!
ho creato una nuova form e ho fatto un override del costruttore cosě:
TMiaForm = class( TForm )
  private
    { Private declarations }
  public
    { Public declarations }
    constructor Create(AOwner:TComponent); override;
  end;
 
fin qui ok! ora se metto un altro parametro al costruttore mi da errore
perchč l'override deve mantenere la stessa dichiarazione del suo 
ascendente.
Su google groups ho trovato questo articolo:
http://groups.google.it/group/it.comp.lang.delphi/browse_thread/thread/7aa
41a60c0c6bf6d/35faba3bab0c1bd0?
lnk=st&q=costruttore+override+Delphi&rnum=4&hl=it#35faba3bab0c1bd0
in cui si parla del caso ma chiedo a voi un chiarimento su un altra cosa.
Per inserire un altro parametro al mio costruttore NON potrei scrivere:
constructor Create(AOwner:TComponent, parametro2: TTipo ); overload;
// Viene fatto l'overload ma mi da il warning segnalando il metodo 
// virtuale della classe base che viene nascosto.
Ma potrei scrivere:
constructor Create(AOwner:TComponent, parametro2: TTipo );
// Questo č un metodo statico, il costruttore viene ridefinito.
// Nell'implementazione posso chiamare  "inherited Create(AOwner);"
constructor Create(AOwner:TComponent, parametro2: TTipo ); reintroduce;
// usata la direttiva "reintroduce" per nascondere il metodo di base.
// Nell'implementazione posso chiamare  "inherited Create(AOwner);"
La domanda č:
Quale č la differenza tra le ultime due dichiarazioni, visto che in 
entrambi i casi ho introdotto un secondo parametro e nell'implementazione 
posso chiamare il metodo di base?
grazie in anticipo.
--- posted by geoForum on 
http://www.delphiedintorni.it

di solito, preferisco dichiarare un costruttore diverso:
constructor MYCreate(AOwner:TComponent, parametro2: TTipo );
begin
  inherited Create(AOwner);
  ...
end;
al fare l'override di quello predefinito,
AS


E' un idea! ma mi è capitato, in un software che avevo già sviluppato, di 
ridefinire alcuni costruttori e mi è risultato molto comodo il fatto di 
non cambiare ogni singola riga dove veniva chiamata la form del 
costruttore modificato.
Diego


 nell'implementazione posso chiamare il metodo di base?
la differenza dovrebbe essere solo quella di evitare un warning dal 
compilatore.
-- 
Mauro Falzari 
 
 "Se guardi nell'abisso, anche l'abisso guarda in te." 
   (Friedrich Nietzsche)

compilatore.
ragazzi! mi scuso con tutti! ho controllato meglio!
Nel primo caso viene si ridefinito il metodo ma da il warning segnalando
la presenza del metodo nascosto. Il metodo corretto è il secondo, cioè 
quello che fa uso della direttiva "reintroduce".
Diego


 constructor MYCreate(AOwner:TComponent, parametro2: TTipo );
L'override di un costruttore virtuale ha un senso, serve a rendere la tua
classe compatibile con un'eventuale factory che crei dinamicamente
istanze, in base a un class reference.  Inserire un altro costruttore
significa sfuggire  a questo meccanismo.  In ogni caso, benché Delphi
consenta di farlo, usare un nome diverso da "Create" per il costruttore di
una classe è fuori standard.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Scusate se mi intrometto..
perchè fuori standard? non so in delphi ma
in java (e credo anche in altri linguaggi) si usa spesso il factory 
method statico che per convenzione chiamiamo .getInstance(...). 
sostituisco appunto i costruttori. Uno dei vantaggi principali e che 
costruttori con la stessa signature possono coesistere x' hanno nomi 
diversi. Oltre al fatto che hanno la facoltà di ritornare istanze di 
sottoclassi o addirittura nessuna istanza ;)
ciao.
++fasco*;
Andrea Laforgia ha scritto:


> perchè fuori standard? 
Andrea Laforgia probabilmente intendeva lo standard con cui è scritta la 
VCL.
Nel caso in cui si decide di scrivere un componente in delphi, chiamare 
un costruttore con un nome diverso dallo standard potrebbe generare 
confusione e rendere il componente "non immediato" per lo sviluppo, a 
meno che quel componente non lo uso esclusivamente chi lo ha scritto. ;)
correggetemi se ho sbagliato.
Diego


 sottoclassi o addirittura nessuna istanza ;)
Il problema non è l'overlading del costruttore, ma istruire il resto 
della vcl a utilizzare il nuovo costruttore in luogo di quello standard.
La creazione di un componente visuale (derivato da TComponent) in genere 
è demandata al suo Owner, che sicuramente continuerà ad istanziarlo 
utilizzando il costruttore standard.
Lo stesso vale, penso, anche in Java.
Ciao,
Gianluca.

in java [...]
Fuori dallo standard con cui sono costruiti i costruttori delle classi
Delphi.  Qui si parla di Delphi ;-)

allora avevo capito bene. nessun riferimento alle VCL.
certo che si parla di delphi, java lo usavo solo come riferimento ma 
piu' in genere l'argomento di cui parlo è di tutti i linguaggi OOP. e 
Delphi lo è ;)
per istanziare un oggetto non è necessario o obbligatorio utilizzare il 
suo costruttore, ci sono alternative come come quelle che indicavo 
precedentemente che in alcuni casi sono piu' convenienti (e quello 
proposto dal thread parent era uno di questi secondo me)
ciao.
Andrea Laforgia ha scritto:


suo costruttore, [...]
In Delphi non č cosě.