[C#] Multiple inheritance / interfaces

[Stray]

Ik wil een eigen set van Form controls maken die zijn afgeleid van de controls van het .NET framework. Maar deze controls hebben allemaal een set van nieuwe functies met dezelfde implementatie. Multiple inheritance kan niet, interfaces hebben geen implementie, dus kan ik enkel de code kopiëren in iedere klasse (en onderhouden).
Is er een manier om hier iets aan te doen?

[Brainstorm]

Tsja, simpelste manier is denk ik om de implementatie van functies die hergebruikt worden over de verschillende controls af te splitsen naar een aparte class. Zoiets als dit dus:

[H!GHGuY]

Kun je geen (abstracte?) base class maken met de gemeenschappelijke functionaliteit in?

code:

                                /-- ControlX
UserControl <---- BaseControl <---- ControlY
                                \-- ControlZ

[whoami]

De oplossing die H!GHGuY aandraagt, lijkt me ook de meest plausibele.
Alleen, een abstracte UserControl kan je niet echt maken, want VS.NET kan daar niet zo goed mee overweg. (Controls die inheriten van een abstracte control, kunnen niet in de designer getoond worden; althans dat was toch in vorige versies van VS.NET zo, weet niet of het nu ook nog zo is).

[Verwijderd]

Je kunt het ook in de buurt van mutliple inherentence komen door gebruik te maken van compositie.

[whoami]

Verwijderd schreef op zondag 25 mei 2008 @ 10:33:
Je kunt het ook in de buurt van mutliple inherentence komen door gebruik te maken van compositie.

Da's niet echt 'in de buurt van', vind ik.
inheritance blijft 'is a' en compositie is 'has a'.

In de meeste gevallen is composition idd misschien wel 'te weinig gebruikt' tvv inheritance, terwijl composition in veel van de gevallen gewoon de beste keuze is; echter, ik denk niet dat composition hier een afdoende oplossing is voor het probleem.

[Brainstorm]

Wat ik eigenlijk dacht dat de bedoeling is, is dat de bestaande .NET controls (zoals TextBox) uitgebreid worden met eigen functionaliteit. Oftewel, overerven van usercontrol is niet mogelijk.

code:

Label <----- MyLabel
TextBox <--- MyTextBox

Ik zie dat dit scenario niet expliciet genoemd wordt, maar gezien het feit dat de TS het heeft over multiple inheritance...

[Verwijderd]

whoami schreef op zondag 25 mei 2008 @ 10:36:
Da's niet echt 'in de buurt van', vind ik.
inheritance blijft 'is a' en compositie is 'has a'.

om het verhaal even wat completer te maken:
Je implementeert simpelweg de interfaces om de 'is-a' relatie te verwezenlijken en de daadwerkelijke implementaties doe je doormiddel van compositie. Daarmee heb je hetvolgende probleem opgelost:

Stray678 schreef op zondag 25 mei 2008 @ 03:26:
[..] ik enkel de code kopiëren in iedere klasse (en onderhouden).
Is er een manier om hier iets aan te doen?

Het is natuurlijk wel het betere plumbing code werk maar je hebt in ieder geval geen duplicate code.

[H!GHGuY]

whoami schreef op zondag 25 mei 2008 @ 10:28:
De oplossing die H!GHGuY aandraagt, lijkt me ook de meest plausibele.
Alleen, een abstracte UserControl kan je niet echt maken, want VS.NET kan daar niet zo goed mee overweg. (Controls die inheriten van een abstracte control, kunnen niet in de designer getoond worden; althans dat was toch in vorige versies van VS.NET zo, weet niet of het nu ook nog zo is).

Idd, met die abstract usercontrols moet je oppassen. In VS 2005 heb ik er last mee gehad.
Ik heb het echter nog niet geprobeerd in de 2008 versie.

Je kan dit wel "oplossen" natuurlijk met

C#:

public class BaseClass : UserControl
{
  public BaseClass()
  {
    // eventueel zelfs in de constructor:
    // hoewel dit door de afgeleide klasse wel moet ondersteund worden zonder
    // er meteen een rommeltje van te maken
#if DEBUG
    DoeIets();
#endif
  }
  public virtual void DoeIets()
  {
     throw new NotImplementedException();
  }
}

[ Voor 25% gewijzigd door H!GHGuY op 25-05-2008 11:55 ]

[Verwijderd]

Welke versie van .NET hebben we 't over? Als we 't hebben over 3.5 is het een en ander misschien op te lossen met extension methods.

[whoami]

Een virtuele methode oproepen in een constructor in .NET is meestal niet zo'n goed idee ....
Als in, niet echt triviaal om na te gaan welke implementatie er nu exact wordt aangeroepen op het moment van object construction ...

[DrDelete]

Dit zou ik doen:

maak een class die erft van .NET control class, bijvoorbeeld MyControl.

Zet in MyControl de shared code.

Erf elke specifieke class van MyControl en voila.


(edit)...


ai. ik zie dat je elk component van een specifieke toolbox control wilt afleiden, dan gaat mijn verhaal niet echt op...

Wat je dan alleen nog kunt doen, is de shared code verplaatsen naar een aparte class en deze vanuit elke control aanroepen.

[ Voor 42% gewijzigd door DrDelete op 26-05-2008 07:51 ]

[riezebosch]

Extension method op de base class van de controls?
Edit: Sorry, bericht van Tedkees over het hoofd gezien.

[ Voor 45% gewijzigd door riezebosch op 26-05-2008 09:50 ]

[Niemand_Anders]

Met extensions kun je niet bij de private (en protected) variabelen en met overerving kun je dat wel. Wat natuurlijk wel kan is dat je je user control als een Cascade naar andere classes bouwt.

Ofwel jouw class erft van een standaard (web)form control en intern maak je gebruik van een aantal helper classes welke voor de extra functionaliteit zorgen. Via interfaces kun je de implementatie afdwingen. Door de Render methode te overriden kun je de gewenste wijzigingen doorvoeren.

Dit is de methode welke wij aanhouden. Multiple Inheritance kan zeer ingewikkeld worden namelijk. Stel class A en class B hebben allebei een public methode DoIets(). Welke van de twee wordt dan uiteindelijk aangeroepen?

Onder andere vanwege die reden hebben ze besloten geen multiple inheritance (MI) op te nemen in C#. Als je echt MI wilt hebben zit er niets anders op dan C++.net te gebruiken om de (abstract) controls op basis van je meerdere basis classes te maken.

[whoami]

Met overerving kan je ook niet bij de private variabelen, enkel bij protected.

[Stray]

Het gaat hier over .NET 2.0, meer bepaald, het moet lopen op een Win CE 5.0 met compact framework 2.0. (Misschien wordt het nog CE 6.0, maar dat is nog niet zeker).

Ik wil dus inderdaad afleiden van de standaard controls, dus een eigen base class zit er niet in. Het zal dus mbv extra classes worden waarbij mijn eigen controls een field van dit type hebben.

Ik ken het gevaar van multiple inheritance (werk in het dagelijkse leven met C++), maar soms is het wel handig.

Dat hier nog geen slimme kop een design pattern voor ontwikkeld heeft

[riezebosch]

Stray678 schreef op maandag 26 mei 2008 @ 11:01:
Het gaat hier over .NET 2.0, meer bepaald, het moet lopen op een Win CE 5.0 met compact framework 2.0. (Misschien wordt het nog CE 6.0, maar dat is nog niet zeker).

Ik wil dus inderdaad afleiden van de standaard controls, dus een eigen base class zit er niet in. Het zal dus mbv extra classes worden waarbij mijn eigen controls een field van dit type hebben.

Ik ken het gevaar van multiple inheritance (werk in het dagelijkse leven met C++), maar soms is het wel handig.

Dat hier nog geen slimme kop een design pattern voor ontwikkeld heeft

Ik weet niet wat die extra set aan functies is, maar als het om externe bewerkingen gaat kan je deze toch onderbrengen in een static helper class die als input een object van het type System.Windows.Forms.Control krijgen? Of overloaded methods voor specifieke implementaties.

[.oisyn]

Niemand_Anders schreef op maandag 26 mei 2008 @ 10:04:
Als je echt MI wilt hebben zit er niets anders op dan C++.net te gebruiken om de (abstract) controls op basis van je meerdere basis classes te maken.

No can do. C++/CLI ondersteunt helemaal geen multiple inheritance voor managed classes (logisch ook - het is de VM die het niet support, niet slechts de taal). En je kunt een unmanaged class (waarbij MI wel mogelijk is) niet van een managed class laten overerven.

Onder andere vanwege die reden hebben ze besloten geen multiple inheritance (MI) op te nemen in C#.

Het is een inconvenience, maar niet een onoverkomelijk probleem (in C++ kun je de method aanroepen door 'm de prefixen met z'n baseclass: instance->Base1::method()). Niet echt iets om MI voor te laten. Er kleven veel grotere problemen aan MI, zoals: wie gaat A constructen in de welbekende class A; class B:A; class C:A; class D:B,C overerving structuur. En hoe ga je serialization implementeren in een dergelijke structuur als geen enkele instance de zekerheid heeft of zijn base instance niet geshared wordt door een andere derived class in dezelfde instance.

[ Voor 38% gewijzigd door .oisyn op 26-05-2008 11:36 ]

[roy-t]

whoami schreef op zondag 25 mei 2008 @ 10:28:
De oplossing die H!GHGuY aandraagt, lijkt me ook de meest plausibele.
Alleen, een abstracte UserControl kan je niet echt maken, want VS.NET kan daar niet zo goed mee overweg. (Controls die inheriten van een abstracte control, kunnen niet in de designer getoond worden; althans dat was toch in vorige versies van VS.NET zo, weet niet of het nu ook nog zo is).

In ieder geval in 2005 kan dit wel (weer)

[whoami]

roy-t schreef op maandag 26 mei 2008 @ 20:24:
[...]


In ieder geval in 2005 kan dit wel (weer)

Ik denk dat je dan iets niet goed getest hebt, want dit lukt nog altijd niet in VS.NET 2005:

[RobIII]

^^ En dat werkt in VS2008 ook (nog steeds) niet.


En dit is wat MS erover zegt:

We have no plans to add support support for abstract base classes in this version due to the complexity of changing this. The windows forms designer does create an instance of your class (user control) when you double click the user control in the solution explorer. In fact all of the design time experience is based upon the ability to create the form, control, user control to design it. In the future we might re-visit this and see if there is a change that can be made.

En wat leesvoeier:
http://www.urbanpotato.net/default.aspx/document/1772
http://www.urbanpotato.net/Default.aspx/document/2001

[ Voor 120% gewijzigd door RobIII op 26-05-2008 23:33 ]

[ATS]

Geen idee of dit zou kunnen in C#, ik gebruik dat nooit, maar misschien kan het je op een idee brengen:
Zou je geen gebruik kunnen maken van een template class? Met behulp van een template kan je, in elk geval in C++, overerven van een klasse die je op het moment van het schijven van je class nog niet weet, omdat je kan overerven van je type in je template.

[Woy]

ATS schreef op dinsdag 27 mei 2008 @ 08:02:
Geen idee of dit zou kunnen in C#, ik gebruik dat nooit, maar misschien kan het je op een idee brengen:
Zou je geen gebruik kunnen maken van een template class? Met behulp van een template kan je, in elk geval in C++, overerven van een klasse die je op het moment van het schijven van je class nog niet weet, omdat je kan overerven van je type in je template.

In C# kan je ieder geval niet inheritten van een Generic Type dus iets als het volgende kan niet

C#:

public class MyType<T> : T
{
}

Het lijkt me eigenlijk ook nogal een vreemde constructie.

[.oisyn]

Waarom is dat vreemd? Goed, voor generics waarbij MyType gecompileerd moet worden zonder te weten wat T is (en de compiler dus niet weet welke methods hij moet overriden, of hoe de base ctor aangeroepen moet worden) is het niet te implementeren, maar het is juist bij problemen zoals die van de TS uitermate geschikt - je kunt standaard functionaliteit toevoegen aan verschillende classes.

[Woy]

.oisyn schreef op dinsdag 27 mei 2008 @ 10:46:
Waarom is dat vreemd? Goed, voor generics waarbij MyType gecompileerd moet worden zonder te weten wat T is (en de compiler dus niet weet welke methods hij moet overriden, of hoe de base ctor aangeroepen moet worden) is het niet te implementeren, maar het is juist bij problemen zoals die van de TS uitermate geschikt - je kunt standaard functionaliteit toevoegen aan verschillende classes.

Ja oke als je idd zoals bij C++ compile time templates hebt is er wel wat voor te zeggen.

In C# zou je ook wel zoiets kunnen bereiken door wat constraints op te leggen voor de constructor en base-type. Op het moment kun je volgens mij alleen een constraint op een publieke parameterless constructor leggen.

[.oisyn]

Maar hoe ga je afdwingen dat methods wel goed overridden worden e.d.?

[Woy]

.oisyn schreef op dinsdag 27 mei 2008 @ 11:18:
Maar hoe ga je afdwingen dat methods wel goed overridden worden e.d.?

In de praktijk zal dat lastig zijn. Maal zolang een base-type maar geen methods sealed zou het geen probleem op moeten leveren als een tussenliggend type ook een methode overide.

Ook met abstracte classes heb je natuurlijk een probleem omdat je niet weet of er ergens in de keten al een implementatie is.

C#:

public MyBaseControl<T> : T where T : UserControl, new()
{
    public MyBaseControl()
    {
    }
    
    public override void OnLoad(..) { }

    public void SomeFunc()
    {
        Children.Add( new Button() );
    }
}

met zoiets zie ik in theorie niet zoveel problemen. Eventueel zouden ze de new constrained uit kunnen breiden om ook constructors met parameters toe te laten.

[ Voor 29% gewijzigd door Woy op 27-05-2008 11:44 ]

[Stray]

Ik ga vanavond nog wat verder proberen, want het project heeft een paar dagen stil gelegen omwille van een herinstallatie van de PC. Normaal moet straks alles terug up-and-running zijn.

Ik zal het resultaat dan posten.

[ATS]

@TS:
Wat eigenlijk nog niet duidelijk is in je verhaal is of je alleen dingen wil toevoegen aan de bestaande controls, of dat je ook functionaliteit moet veranderen daarvoor. Heb je toegang nodig tot de protected members van de controls?

Dat maakt m.i. nogal uit in de mogelijke oplossingen.

[Stray]

Ik wil (tot nu toe) enkele functionaliteit toevoegen. Alle controls implementeren dezelfde Init() method die subscribed op een IO driver, ze hebben allemaal een AutoUpdate property die kan subscriben op een event van de IO driver, enz .....

Maar ik denk dat ik weet waar je naar toe wil.

[code=c#, 0, 4]
public abstract class MyControl
{
public void Init()
{
// default implementation
}

public AutoUpdate { set { /* subscribe */ } }

public System.Windows.Forms.Control Ctrl { get { return ctrl; } }
private System.Windows.Forms.Control ctrl = null;
}

public class MyButton : MyControl
{
public MyButton()
{
ctrl = new System.Windows.Forms.Button();
}
}
[/code]


Edit: Ik moet toch enkele methods overriden, zoals de On_Click .

[ Voor 5% gewijzigd door Stray op 27-05-2008 23:24 ]

[Woy]

Kan je dan niet iets als het volgende doen?

C#:

public class MyUserControl<T> : UserControl where T : Control, new()
{
    public virtual void Init()
    {
        Control myControl = new T();
        Controls.Add(myControl);
        //Doe iets
    }

    protected override void OnClick(EventArgs e)
    {
        base.OnClick(e);
        //Do iets
    }

    public bool AutoUpdate { set { /* subscribe */ } }
}

Je heb dan een generiek UserControl die aan de hand van zijn Generic Type een child control toevoegt. Je kunt alle algemene methods gewoon overerven. Je hebt er zo wel weer een extra laag tussen zitten. Als je echt een Button Control wilt hebben zul je denk toch iets met compositie of extension methods moeten doen.

edit:
of je kan het via een abstracte class doen. Dan kan je in je subclass ook nog dingen met het event van Button doen

C#:

public abstract class MyUserControl : UserControl
{
    public virtual void Init()
    {
        Controls.Add(ChildControl);
        //Doe iets
    }

    public abstract Control ChildControl { get; }

    protected override void OnClick(EventArgs e)
    {
        base.OnClick(e);
        //Do iets
    }

    public bool AutoUpdate { set { /* subscribe */ } }
}

public class MyButtonControl : MyUserControl
{
    private readonly Control childControl;

    public MyButtonControl()
    {
        childControl = new Button();
    }

    public override Control ChildControl
    {
        get { return childControl; }
    }
}

[ Voor 47% gewijzigd door Woy op 28-05-2008 09:26 ]

[riezebosch]

Op die manier wrap je wel altijd het control in een UserControl?

[Woy]

ja dat bedoel ik met

Je hebt er zo wel weer een extra laag tussen zitten.

[Stray]

Het zal met een abstracte class moeten, aangezien de te overidden methods afhankelijk zijn van het type control. Bv. MyButton moet de OnPaint() overriden, maar MyLabel niet. Dus kan ik niet met een generic werken.

[Stray]

Update:
Wanneer ik de control laat overerven van een base control (die op zijn beurt overerft van Forms.Control) worden de events zoals OnPaint() niet meer getriggered.

C#:

public abstract class BaseControl : Control {

    public void Init(string var, Device dev) {

        Controls.Add(Ctrl);
       
        // some more intializations
    }

    public abstract void OnNotification(object sender, EventArgs e);

    public Control Ctrl { 
        get { return _ctrl; }
        protected set { _ctrl = value; } 
    }

    private Control           _ctrl;
}

public class LightButton : BaseControl {

    public LightButton() {

        Ctrl = new System.Windows.Forms.Control();
    }


    public override void OnNotification(object sender, EventArgs e) {
       // handle update
    }

    protected override void OnPaint(PaintEventArgs e) {
       // draw custom image
    
        base.OnPaint(e);
    }

    protected override void OnPaintBackground(PaintEventArgs e) {
        //Do nothing
    }

    protected override void OnMouseDown(System.Windows.Forms.MouseEventArgs e) {
        _pushed = true;
        this.Invalidate();
    }

    protected override void OnMouseUp(System.Windows.Forms.MouseEventArgs e) {
        _pushed = false;
        this.Invalidate();
    }

    protected override void OnClick(EventArgs e) {
        // TODO Toggle light output
        base.OnClick(e);
    }
}

Ik ga wel even niet kunnen reageren want ik vertrek morgen op vakantie