[C#] Ereditarieta' & Costruttori

[mcaisco]

Mi sorge un dubbio.
Ho una classe astratta da cui derivano diverse classi concrete e avrei bisogno di imporre che ognuna di queste classi derivate, nel proprio costruttore, accetti gli stessi parametri.

Ad esempio se avessi la classe astratta AbstractLavoratore con un membro protected "stipendio" e le classi derivate Impiegato e Tirocinante, vorrei che i costruttori di Impiegato e Tirocinante accettino in input un valore da assegnare al membro (ereditato) "stipendio".

In pratica vorrei che le classi derivate avessero una sorta di override di un costruttore unico definito solo nella classe padre astratta.

E' possibile?

[SerMagnus]

puoi farlo con le interfacce, le classi che le implementano saranno tenute a rispettare l'implementazione dei prototipi di quei metodi

[mcaisco]

Sembra proprio che non sia possibile, stando a quanto dice qui

Pero' la cosa non mi sembra cosi' fuori dal mondo.
Anzi, direi che spesso capita di avere delle gerarchie di classi che derivano da una comune classe padre (astratta o meno) e che in questa classe siano definiti diversi membri comuni a tutte le classi derivate, per i quali si vorebbe fornire un valore di inizializzazione gia' nel costruttore.

Mah

[Kralizek]

non puoi costringere i costruttori delle classi figlie ad avere esattamente gli stessi parametri, ma puoi costringerli ad avere ALMENO un determinato set di parametri.

Ecco il codice di esempio:

    public abstract class BaseClass
    {
        public BaseClass(int p1, string p2, double p3)
        { 
            // Do something
        }
    }

    public class DerivedClass : BaseClass
    {
        public DerivedClass(int p1, string p2, double p3) : base(p1, p2, p3) { }

        public DerivedClass(int p1, string p2, double p3, bool p4)
            : base(p1, p2, p3)
        { 
            // Do something
        }
    }

Originariamente inviato da SerMagnus

puoi farlo con le interfacce, le classi che le implementano saranno tenute a rispettare l'implementazione dei prototipi di quei metodi

Occhio che le interfacce non hanno nulla a che fare con i costruttori

[gugoXX]

No.

Tieni pero' conto di quanto segue:

public abstract class Lavoratore
{
    protected double _stipendio;
    
    protected Lavoratore(double stipendio)
    {
        _stipendio = stipendio;
    }
}

public class Impiegato:Lavoratore
{
    public Impiegato()
    {            
    }
}

Questo codice NON puo' compilare.
Perche' Lavoratore non possiede un costruttore senza parametri implicitamente chiamato da tutti i costruttori di tutte le classi derivate.

Si' dovra' per forza di cose passare attraverso il costruttore protected Lavoratore(double stipendio).
Si dovra' quindi passare uno stipendio da parte di tutti i costruttori derivati, che necessariamente dovranno conoscere (Molto probabilmente perche' passato come parametro del costruttore stesso)

L'implmenetazione piu' frequente potra' essere

public class Impiegato:Lavoratore
{
    public Impiegato(double stipendio):base(stipendio)
    {            
    }
}

[SerMagnus]

Originariamente inviato da Kralizek

non puoi costringere i costruttori delle classi figlie ad avere esattamente gli stessi parametri, ma puoi costringerli ad avere ALMENO un determinato set di parametri.

Ecco il codice di esempio:

    public abstract class BaseClass
    {
        public BaseClass(int p1, string p2, double p3)
        { 
            // Do something
        }
    }

    public class DerivedClass : BaseClass
    {
        public DerivedClass(int p1, string p2, double p3) : base(p1, p2, p3) { }

        public DerivedClass(int p1, string p2, double p3, bool p4)
            : base(p1, p2, p3)
        { 
            // Do something
        }
    }

Occhio che le interfacce non hanno nulla a che fare con i costruttori

vero svista mia, infatti parlavo di metodi

[mcaisco]

Originariamente inviato da SerMagnus

puoi farlo con le interfacce, le classi che le implementano saranno tenute a rispettare l'implementazione dei prototipi di quei metodi

Beh si e' vero che un metodo astratto di un interfaccia impone alle classi derivate di fornirne un'override (e comunque la stessa cosa vale per un generico metodo abstract di un classe no?).
In ogni caso il problema sta nel nome del metodo. In questo caso infatti io avrei bisogno di fare un override di un costruttore, ma come e' ovvio, ogni classe ha un costruttore che si chiama come la classe stessa.

Insomma nell'esempio sopra, io vorrei avere un costruttore-padre in AbstractLavoratore (o ILavoratore se vogliamo usare interfacce) e quindi avrei un costruttore AbstractLavoratore(int stipendio). Nelle due classi derivate mi piacerebbe poter avere automaticamente due costruttori del tipo Impiegato(int stipendio) e Tirocinante(int stipendio). E pare che questo non sia possibile.

[mcaisco]

Originariamente inviato da gugoXX

No.

Tieni pero' conto di quanto segue:

public abstract class Lavoratore
{
    protected double _stipendio;
    
    protected Lavoratore(double stipendio)
    {
        _stipendio = stipendio;
    }
}

public class Impiegato:Lavoratore
{
    public Impiegato()
    {            
    }
}

Questo codice NON puo' compilare.
Perche' Lavoratore non possiede un costruttore senza parametri implicitamente chiamato da tutti i costruttori di tutte le classi derivate.

Si' dovra' per forza di cose passare attraverso il costruttore protected Lavoratore(double stipendio).
Si dovra' quindi passare uno stipendio da parte di tutti i costruttori derivati, che necessariamente dovranno conoscere (Molto probabilmente perche' passato come parametro del costruttore stesso)

L'implmenetazione piu' frequente potra' essere

public class Impiegato:Lavoratore
{
    public Impiegato(double stipendio):base(stipendio)
    {            
    }
}

Si questa sembra la soluzione adottabile, anche se non e' chiarissima. O almeno non e' chiaro dove andare a parare in base agli errori del compilatore. Infatti il compilatore si lamenta del fatto che non esiste in Lavoratore un costruttore con 0 parametri e la cosa che mi e' venuta subito da fare e' mettercene uno e tanti saluti.
Insomma, non e' proprio chiara la faccenda.

[gugoXX]

Il fatto e' che e' formalmente errato richiedere che una classe derivata abbia "Almeno un" costruttore con determinati parametri.
Nella catena di derivazione e' sempre la classe padre che richiama in override la classe figlia.
Nel caso dei costruttori invece capita l'opposto. E' il costruttore figlio che chiama il costruttore del padre.
Non si vede quindi perche' si debba quindi forzare il figlio ad avere un costruttore che abbia proprio determinati parametri. Magari tale costruttore NON deve esistere per come la logica del figlio deve essere costruita.

Esempio:

public abstract class Lavoratore
{
    protected double _stipendio;
    
    protected Lavoratore(double stipendio)
    {
        _stipendio = stipendio;
    }
}

public class Impiegato:Lavoratore
{
    private readonly string _nome;
    public Impiegato(string nome, double stipendio)
        :base(stipendio)
    {
        _nome = nome;        
    }
}

Intendo, sarebbe formalmente scorretto richiedere che ogni classe derivata abbia proprio un costruttore con solo stipendio.
Questa classe derivata Impiegato NON deve averlo seppure derivando da Lavoratore, pena la non inizializzazione del campo _nome, che deve essere settato proprio e solo durante il costruttore (readonly)

E questo caso?

public class Berlusca:Lavoratore
{   
    public Impiegato()
        :base(double.PositiveInfinity)
    { 
    }
}

Anche questo caso e' il caso di un lavoratore. Che guadagna piu' di tutti, senza dover passare l'informazione dall'esterno essendo che il suo stipendio si sa ed e' sempre uguale (esagerato )
E' infatti probabile che di istanze di Berlusca ne esista una sola, e sarebbe quindi opportuno modellare con un Singleton

public class Berlusca:Lavoratore
{   
    public static Berlusca Instance = new Berlusca();

    protected Berlusca()
        :base(double.PositiveInfinity)
    { 
    }
}

Insomma, sono tutti casi di possibili classi derivate da Lavoratore, che non devono necessariamente avere proprio un costruttore con esattamente lo stesso prototipo. Non sarebbe quindi formalmente corretto richiedere mediante una qualche clausola che TUTTE le classi derivate debbano averlo (non e' nemmeno detto che debbano avere per forza un costruttore pubblico, vedi ultimo caso)

[gugoXX]

Se ho intuito cosa vuoi fare, ho idea che nel tuo caso si possa implementare il pattern "Factory"
Se ci dici qualcosa in piu' possiamo vedere di costruirlo insieme...

[mcaisco]

Si si il pattern factory lo sto usando... tra l'altro scrivero' un altro thread in cui mi sorge un dubbio proprio su questo pattern.

In questo caso, piu' che altro era un dubbio generale. Ultimamente mi trovo spesso a dover creare gerarchie di classi in cui c'e' ovviamente una classe padre principale che specifica tutta una serie di membri protected comuni a tutte le classi derivate.
E in effetti salta sempre fuori questo problema, cioe' mi sarebbe utile imporre che tutte le classi derivate abbiano ALMENO un costruttore con una serie di parametri standard, che inizializzino i membri comuni a qualunque classe derivata.
E' ovvio che poi, ogni classe derivata puo' definire tutta una serie di costruttori personalizzati.

[gugoXX]

Originariamente inviato da mcaisco

Si si il pattern factory lo sto usando... tra l'altro scrivero' un altro thread in cui mi sorge un dubbio proprio su questo pattern.

In questo caso, piu' che altro era un dubbio generale. Ultimamente mi trovo spesso a dover creare gerarchie di classi in cui c'e' ovviamente una classe padre principale che specifica tutta una serie di membri protected comuni a tutte le classi derivate.
E in effetti salta sempre fuori questo problema, cioe' mi sarebbe utile imporre che tutte le classi derivate abbiano ALMENO un costruttore con una serie di parametri standard, che inizializzino i membri comuni a qualunque classe derivata.
E' ovvio che poi, ogni classe derivata puo' definire tutta una serie di costruttori personalizzati.

Ma capisci dagli esempi di prima che NON e' possibile imporre l'esistenza di tali costruttori, essendo che per alcune classi l'esistenza ed uso di tali costruttori sarebbe proprio errato.

[mcaisco]

Originariamente inviato da gugoXX

Ma capisci dagli esempi di prima che NON e' possibile imporre l'esistenza di tali costruttori, essendo che per alcune classi l'esistenza ed uso di tali costruttori sarebbe proprio errato.

Beh capisco che possa creare dei problemi ma credo che questo dipenda molto dal modello di programmazione utilizzato.
Io tendo a pensare ad un costruttore in maniera molto "TDD" (Test Driven Development), dove i costruttori devono accettare in input valori da assegnare a tutti i membri della classe.
Dunque in quest'ottica, se ho una classe base con 3 membri comuni a tutte le classi derivate, farebbe molto comodo avere un costruttore ereditato dalla classe base che imponga di passare in input valori per quei 3 membri. Poi ovviamente, se necessario, ogni classe derivata potra' anche definire altri costruttori che aggiungano altri parametri oltre ai 3 da valorizzare di default.

[gugoXX]

Originariamente inviato da mcaisco

Beh capisco che possa creare dei problemi ma credo che questo dipenda molto dal modello di programmazione utilizzato.
Io tendo a pensare ad un costruttore in maniera molto "TDD" (Test Driven Development), dove i costruttori devono accettare in input valori da assegnare a tutti i membri della classe.
Dunque in quest'ottica, se ho una classe base con 3 membri comuni a tutte le classi derivate, farebbe molto comodo avere un costruttore ereditato dalla classe base che imponga di passare in input valori per quei 3 membri. Poi ovviamente, se necessario, ogni classe derivata potra' anche definire altri costruttori che aggiungano altri parametri oltre ai 3 da valorizzare di default.

Si', ma usando questo costruttore ereditato potresti causare grossi problemi, ad esempio la non inizializzazione di altri membri privati della classe derivata.
Ereditare i costruttori sarebbe sbagliato in ottica OO, e proprio per i motivi di cui sopra.
Non capisco la menzione al TDD.

EDIT: Anzi, forse ho capito, e penso che stai utilizzando il vecchio metodo di passaggio diretto delle interfaccie nei costruttori per beneficiare degli stub e dei mock in fase di test, o dei veri oggetti durente il normale utilizzo.
Per questo sono almeno 2 anni che in TDD (C#) viene usato il paradigma Unity, ora integrato nel MEF del C#4.0

Posso farti vedere un pezzo di codice mio

Questa un'abstract class

public abstract class ModuleInitWrapperBase : IModuleInitApplication
    {
        private static readonly ILog Logger = LogManager.GetLogger(typeof(ModuleInitWrapperBase));

        protected AppDomain _theAppDomain;
        protected ILogonService LogonService;
        protected ICommandManager CommandManager;
        protected IShellView ShellView;
        protected IApplicationWrapper ApplicationWrapper;
        protected IOptionsPageManager OptionsPageManager;
        protected IConfigurationService ConfigurationService;

        protected ModuleInitWrapperBase(ILogonService logonService, 
                                        ICommandManager commandManager, IShellView shellView,
                                        IApplicationWrapper applicationWrapper, IOptionsPageManager optionsPageManager,
                                        IConfigurationService configurationService)
        {            
            LogonService = logonService;
            CommandManager = commandManager;
            ShellView = shellView;
            ApplicationWrapper = applicationWrapper;
            OptionsPageManager = optionsPageManager;
            ConfigurationService = configurationService;            
        }

Questa una classe derivata

    public class XXXXModuleWrapper : ModuleInitWrapperBase
    {
        public XXXXModuleWrapper(ILogonService logonService, ICommandManager commandManager,
            IShellView shellView, IApplicationWrapper applicationWrapper,
            IOptionsPageManager optionsPageManager, IConfigurationService configurationService)
            : base(logonService, commandManager, shellView, applicationWrapper, optionsPageManager, configurationService)
        {
        }

Qui siamo vicino allo startup della applicazione, dove registriamo dentro Unity molte delle interfaccie
(altre possono essere registrate dopo, a seconda dei casi e degli utilizzi)

private readonly IUnityContainer _shared  = new UnityContainer();

....

     _shared.RegisterInstance(new LogonClientFactory(logonServiceWebSSOEnvironment));
     _shared.RegisterType<ILogonService, LogonService>(new ContainerControlledLifetimeManager());                        
     _generalSoapToXmlConfigStore = new FileXmlConfigStore(fullname);                
      _shared.RegisterInstance(_generalSoapToXmlConfigStore);         
....

E qui quando viene creata l'istanza della classe XXXXModuleWrapper

      XXXXModuleWrapper XXXXModuleWrapperInstance =  _shared.Resolve<XXXXModuleWrapper>();

Come vedi da questa ultima riga, il costruttore non si chiama mai direttamente.
E' Unity che lo chiama in vece nostra, e passera' i giusti parametri a seconda dei tipi registrati.

In fase di vero utilizzo si registrano dentro unity le istanze dei servizi e oggetti veri.
In fase di test si registrano invece le Mock e gli Stub, che verranno passati e poi usati dalle classi.

[mcaisco]

Si hai perfettamente ragione, infatti sto usando la dependency injection manuale, senza uso di framework a supporto.

[mcaisco]

Avevo intenzione di fare un nuovo thread, ma in parte si ricollega a questo quindi continuo qui.

Usando il factory method pattern per la costruzione di istanze di classi concrete derivate da una comune classe base (astratta), ho incontrato un problema spinoso.
Fino a che le classi derivate non necessitano parametrizzazioni particolari diverse da quelle della classe base, non ci sono problemi, ma se una o piu' classi derivate necessitano la valorizzazione di altri membri oltre a quelli comuni definiti nella classe base, come si puo' applicare il factory method?

In pratica sembrerebbe necessario fare in modo che il factory method accetti tutti i parametri possibili che necessitano le varie classi derivate... ovviamente una follia!

[gugoXX]

Ciao
Mi sa che stai parlando dell' Abstract Factory Pattern, e non solo del Factory Pattern.
Ebbene, uno dei requisiti dell'abstract factory e' che il metodo (I metodi) di creazione implementino la chimata dell'abstract factory class, e che quindi debbano avere tutti e soli gli stessi parametri.
Quanto chiedi non e' quindi possibile mediante il pattern da solo.

Ma e' ovviamente un problema tipico, ed e' stato fatto qualcosa.
Per riallacciarsi al discorso di prima, sappi che Unity provvede gia' ad esporre le funzionalita' di un Abstract Factory.
Avendo precedentemente opportunamente registrato dentro Unity i factory delle classi derivate, si puo' chiedere a Unity di costruire uno di tali oggetti.

Ma guarda caso puoi marcare un metodo specifico di una classe derivata con l'attributo
[InjectionMethod]

Il metodo (I metodi) marcato con [InjectionMethod] viene chiamato da Unity immediatamente dopo il costruttore dell'oggetto del tipo specifico, durante la Resolve<>.
Il prototipo di tale metodo vuole tipicamente interfaccie supplementari che non si erano potute passare tramite costruttore proprio per il motivo di cui sopra dell'abstract factory.
Le istanze di tali Interfaccie sono gia' registrate dentro Unity a quell'istante, e vengono passate al metodo marcato con l'attributo, a suo uso e consumo.

E' da vedersi come una Init immediatamente successiva al costruttore, inesorabilmente chiamato da Unity in fase di costruzione.

[mcaisco]

Originariamente inviato da gugoXX

Ciao
Mi sa che stai parlando dell' Abstract Factory Pattern, e non solo del Factory Pattern.
Ebbene, uno dei requisiti dell'abstract factory e' che il metodo (I metodi) di creazione implementino la chimata dell'abstract factory class, e che quindi debbano avere tutti e soli gli stessi parametri.
Quanto chiedi non e' quindi possibile mediante il pattern da solo.

Ma e' ovviamente un problema tipico, ed e' stato fatto qualcosa.
Per riallacciarsi al discorso di prima, sappi che Unity provvede gia' ad esporre le funzionalita' di un Abstract Factory.
Avendo precedentemente opportunamente registrato dentro Unity i factory delle classi derivate, si puo' chiedere a Unity di costruire uno di tali oggetti.

Ma guarda caso puoi marcare un metodo specifico di una classe derivata con l'attributo
[InjectionMethod]

Il metodo (I metodi) marcato con [InjectionMethod] viene chiamato da Unity immediatamente dopo il costruttore dell'oggetto del tipo specifico, durante la Resolve<>.
Il prototipo di tale metodo vuole tipicamente interfaccie supplementari che non si erano potute passare tramite costruttore proprio per il motivo di cui sopra dell'abstract factory.
Le istanze di tali Interfaccie sono gia' registrate dentro Unity a quell'istante, e vengono passate al metodo marcato con l'attributo, a suo uso e consumo.

E' da vedersi come una Init immediatamente successiva al costruttore, inesorabilmente chiamato da Unity in fase di costruzione.

Ciao. Non penso che la situazione che descrivevo debba "scomodare" l'Abstract Factory. Per come lo conosco io (usato pochissimo) e' un pattern per creare famiglie di classi concrete, in cui ogni ogni classe concreta istanziata fa parte di una gerarchia di classi a parte. Nel mio caso non vedo il concetto di "famiglia" ecco...

Semplicemente in base al tipo di classe derivata da costruire, occorre chiamare un costruttore che non accetta in input un set di parametri uguale in tutti i casi.

Certamente questo Unity risolve effettivamente la cosa forzando l'injection dei parametri tramite un metodo chiamato automaticamente.

[gugoXX]

Originariamente inviato da mcaisco

Ciao. Non penso che la situazione che descrivevo debba "scomodare" l'Abstract Factory. Per come lo conosco io (usato pochissimo) e' un pattern per creare famiglie di classi concrete, in cui ogni ogni classe concreta istanziata fa parte di una gerarchia di classi a parte. Nel mio caso non vedo il concetto di "famiglia" ecco...

Semplicemente in base al tipo di classe derivata da costruire, occorre chiamare un costruttore che non accetta in input un set di parametri uguale in tutti i casi.

Certamente questo Unity risolve effettivamente la cosa forzando l'injection dei parametri tramite un metodo chiamato automaticamente.

Pensavo all'Abstract Factory perche' entra in gioco quando tipicamente nel caso dei test.
Mi spiego. Immagina di avere un pezzo di codice (magari il corpo di un evento) che ad un certo punto vorrebbe costruire una Finestra particolare, settarne qualche proprieta' e poi visualizzarla.
Il codice normale sarebbe

...
   var MyForm = new QuestaForm();
   MyForm.Colore = Color.Blue;
   MyForm.Header = "Una Form";
   MyForm.Show();
...

Nel caso in cui si volesse iniettare il codice di test, supponendo che in questo come in altri tantissimi casi non si puo' richiamare direttamente la form, occorre passare attraverso un Mock o uno Stub.
Facciamo finta di avere uno Stub di questa finestra, in una classe chiamata
public class QuestaFormStub

Occorre passare attraverso un Factory.
Si avra' quindi un factory per la classe vera, e un factory per la classe Stub.

public class FactoryMyForm
e
public class FactoryMyFormStub

Ma non e' sufficiente. Occorre che venga usato il factory corretto, a seconda che si sia sotto esecuzione di codice normale oppure sotto esecuzione di codice di test.
Entra in gioco quindi Abstract Factory, usato qui senza dover per forza scomodare la necessita' di famiglie di classi. Una sola per il codice normale e una per il test
I 2 Factory erediteranno da uno stesso comune abstract factory, e dovranno restituire un oggetto dello stesso tipo, l'interfaccia di test, che esporra' tutte e sole le proprieta' e metodi comuni che verranno pilotate dal codice del nostro evento, indipdenentemente che sia sotto test oppure no.

Qui tutto insieme

public interface IMyForm
{
    Color Colore {get; set;}
    string Header {get; set;}
    void Show();
}

public abstract class FactoryIMyFormBase
{
    protected FactoryIMyForm(){}

    public abstract IMyForm Create();
}

public class FactoryMyForm : FactoryIMyFormBase
{
    public override IMyForm Create()
    {
         return new MyForm();
    }
}

public class FactoryMyFormStub : FactoryIMyFormBase
{
    public override IMyForm Create()
    {
         return new MyFormStub();
    }
}

//E poi le 2 classi
public class MyForm:IMyForm
{
   // etc.
}

public class MyFormStub:IMyForm
{
   // etc.
}

// E a questo punto il body dell'evento sara'

FactoryIMyFormBase _theFactory;
// qui viene impostato il corretto _theFactory, a seconda che si sia sotto test oppure no
_theFactory = new FactoryMyForm();
oppure _theFactory = new FactoryMyStub();

//e poi il body dell'evento.
{
    ...
    var myForm = _theFactory.Create();
    myForm.Colore = Color.Blue;
    myForm.Header = "Una Form";
    myForm.Show();
...
}

Questo l'esempio classico.
Sotto Unity invece abstract factory viene gia' a gratis.
Non e' necessario costruire i factory e nemmeno l'abstract factory, perche' viene gia' offerto.
Il codice sara'

public interface IMyForm
{
    Color Colore {get; set;}
    string Header {get; set;}
    void Show();
}

public class MyForm:IMyForm
{
   // etc.
}

public class MyFormStub:IMyForm
{
   // etc.
}

// qui viene registrato dentro Unity l'oggetto a seconda della sua interfaccia
_unityContainer.RegisterType<IMyForm,MyForm>();
// che si legge: Quanto ti chiedero' un oggetto che implementi IMyForm, restituiscimi per favore un nuovo oggetto di tipo MyForm

// oppure cosi' quando si e' sotto test
_unityContainer.RegisterType<IMyForm,MyFormStub>();

//E questo il codice relativo al corpo dell'evento:
{
...
    var myForm = _unityContainer.Resolve<IMyForm>();
    myForm.Colore = Color.Blue;
    myForm.Header = "Una Form";
    myForm.Show();
...

Come dicevo prima, i costruttori dei relativi oggetti possono avere tante interfaccie quante si vuole, e sara' Unity a passare i valori corretti in quel momento, eventualmente creando l'oggetto necessario se non era ancora stato creato ma solo registrato.
All'ocorrenza e' anche possibile dichiarare che qualcuno di questi oggetti devono essere Singleton, per non creare un'istanza ogni volta che viene chiamata la Resolve, ma solo la prima volta.
E ognuna delle classi puo' avere un metodo supplementare [InjectionMethod], con parametri supplementari che non era possibile aggiungere al costruttore per motivi specifici.

[mcaisco]

Mmm, I like it... devo un attimo pensarci bene.
Intanto grazie per le dritte.