[C#] Meerdere extends | Parent-child

[Verwijderd]

Eigenlijk twee vraagjes, maar ook al zijn ze verschillend, ze zijn niet zó verschillend dat het me nodig leek 2 verschillende topics te starten.

1. Waarom is het niet mogelijk om een dubbele extend te realiseren in C#? Ik snap dat het normaal gesproken niet geheel wenselijk ontwerp technisch, maar soms lijkt het me toch handig?

Ik heb bijvoorbeeld een aantal classes die allemaal een dezelfde functie hebben, zoals bijvoorbeeld pagina-objecten die op een staan: rectangle, image en textbox. Deze wil ik uitbreiden met eigen functionaliteit, en is het dus makkelijk om de standaard .net objecten te extenden, zodat ik ze kan uitbreiden en toch kan overriden en protected opties kan benaderen.
Maar ik wil ook dat ze allemaal dezelfde eigen functionaliteit delen waarbij ik ze dus ook van mijn eigen abstract class krijgen, en ik virtuals, overridess etc van mijn eigen class kan gebruiken.

Nu kun je een heel eind komen met interfaces e.d. maar dat is toch niet helemaal zo krachtig? of maak ik toch een denkfout?

2. Een parent child relatie opzetten is in principe geen probleem, echter kwam ik toch iets tegen (zoals sommige objecten in standaard .net framework) wat ik niet helemaal zelf geimplementeerd krijg en dat is de volgende pseudo code:

C#:

class ParentObject
{     private Collection _childCollection;
      public Collection ChildCollection
      {    get { return _childCollection; }  }
}

class ChildObject
{   private object _parent;
    public object Parent
    {   get { return _parent; }  }
}

void Main()
{    ParentObject parentObj = new ParentObject();
     ChildObject childObj = new ChildObject();
    
     parentObj.ChildCollection.Add(childObj);
     /* Nu is childObj.Parent == parentObj ! */
}

Wat ik dus niet snap is hoe parent object het voor elkaar heeft gekregen om van het child object de parent heeft kunnen zetten, aangezien de Parent property van het childObject readonly is! Op zich wil ik hetzelfde ongeveer kunnen bereiken maar ik kan dit niet zo 'schoon' voor elkaar krijgen, waarbij niet zomaar alles de parent kan zetten en veranderen wat er zou gebeuren als je Parent ook een 'set' mee zou geven, of de parent b.v. mee zou geven bij de constructor van het childobject

[whoami]

Verwijderd schreef op woensdag 28 februari 2007 @ 21:46:
Eigenlijk twee vraagjes, maar ook al zijn ze verschillend, ze zijn niet zó verschillend dat het me nodig leek 2 verschillende topics te starten.

1. Waarom is het niet mogelijk om een dubbele extend te realiseren in C#? Ik snap dat het normaal gesproken niet geheel wenselijk ontwerp technisch, maar soms lijkt het me toch handig?

Omdat men er voor gekozen heeft om het niet te doen ? Je kan wel van een class en één of meerdere interfaces inheriten.
Voor een antwoord op je vraag: klik

Ik heb bijvoorbeeld een aantal classes die allemaal een dezelfde functie hebben, zoals bijvoorbeeld pagina-objecten die op een staan: rectangle, image en textbox. Deze wil ik uitbreiden met eigen functionaliteit, en is het dus makkelijk om de standaard .net objecten te extenden, zodat ik ze kan uitbreiden en toch kan overriden en protected opties kan benaderen.
Maar ik wil ook dat ze allemaal dezelfde eigen functionaliteit delen waarbij ik ze dus ook van mijn eigen abstract class krijgen, en ik virtuals, overridess etc van mijn eigen class kan gebruiken.

Je kan ook kiezen voor encapsulation . Een eigen class, en daarbinnen een instance van een rectangle, textbox , ...

Nu kun je een heel eind komen met interfaces e.d. maar dat is toch niet helemaal zo krachtig? of maak ik toch een denkfout?

Tja, MI kan handig zijn en het is misschien wel in bepaalde gevallen wat krachtiger.
Echter, soms wordt inheritance ook wel misbruikt. In sommige gevallen ben je zowiezo beter af als je encapsulation gebruikt ipv inheritance.

2. Een parent child relatie opzetten is in principe geen probleem, echter kwam ik toch iets tegen (zoals sommige objecten in standaard .net framework) wat ik niet helemaal zelf geimplementeerd krijg en dat is de volgende pseudo code:

C#:

class ParentObject
{     private Collection _childCollection;
      public Collection ChildCollection
      {    get { return _childCollection; }  }
}

class ChildObject
{   private object _parent;
    public object Parent
    {   get { return _parent; }  }
}

void Main()
{    ParentObject parentObj = new ParentObject();
     ChildObject childObj = new ChildObject();
    
     parentObj.ChildCollection.Add(childObj);
     /* Nu is childObj.Parent == parentObj ! */
}

Wat ik dus niet snap is hoe parent object het voor elkaar heeft gekregen om van het child object de parent heeft kunnen zetten, aangezien de Parent property van het childObject readonly is! Op zich wil ik hetzelfde ongeveer kunnen bereiken maar ik kan dit niet zo 'schoon' voor elkaar krijgen, waarbij niet zomaar alles de parent kan zetten en veranderen wat er zou gebeuren als je Parent ook een 'set' mee zou geven, of de parent b.v. mee zou geven bij de constructor van het childobject

In een dergelijke situatie ga je toch bv gewoon dit doen:

code:

Parent p = new Parent();

Waarbij je Parent & ChildCollection r bv zo uit zien:

code:

class Parent
{
    private _childCollection;
    public Parent()
    {
         _childCollection = new ChildCollection (this);
    }
}

code:

class ChildCollection
{
    private Parent _parent;
    internal ChildCollection( Parent p )
    {
          _parent = p;
    }
}

Erm... ok; je wilt het toch nog ff anders. Tipje: Collections hebben methods die uitgevoerd worden als je iets insert / set / removed uit de collectie.
In .NET 2.0 is heeft de Collection<T> class bv de methods InsertItem, RemoveItem, ClearItems die je kan overriden, en daar kan je dan je parent gaan zetten.

[ Voor 3% gewijzigd door whoami op 28-02-2007 22:04 ]

[Verwijderd]

whoami schreef op woensdag 28 februari 2007 @ 21:55:
[...]
Tja, MI kan handig zijn en het is misschien wel in bepaalde gevallen wat krachtiger.
Echter, soms wordt inheritance ook wel misbruikt. In sommige gevallen ben je zowiezo beter af als je encapsulation gebruikt ipv inheritance.

Ja, ik gebruikte al encapsulation, en daarmee kwam ik een heel eind, echter had ik op een gegeven moment van beide protected (/private) functionaliteit nodig, en daarmee liep ik vast. Ik heb het momenteel zo dat ik mijn eigen abstract class maar als een interface implementeer, en alles deels opnieuw implementeer/aanroep van de class die ik óók wilde extenden... Werkt wel, maar voelt als een workaround... p.s. ben het artikel nog aan het lezen

[...]
Erm... ok; je wilt het toch nog ff anders. Tipje: Collections hebben methods die uitgevoerd worden als je iets insert / set / removed uit de collectie.
In .NET 2.0 is heeft de Collection<T> class bv de methods InsertItem, RemoveItem, ClearItems die je kan overriden, en daar kan je dan je parent gaan zetten.

Ja klopt, dat had ik zelf ook bedacht maar het is de readonly Parent die het lastig maakt misschien dat ik een functie er voor moet implementeren SetParent(object parent) ofzo, daarmee is de property iig readonly, maar kan de parent nog wel verandered worden. Echter... betwijfel of het uberhaupt nut heeft, afgezien van b.v. kleinigheidjes zoals code-insight die readonly-ness toont...

[whoami]

Je kan ook een internal setter maken... Dan scherm je het geheel toch al iets meer af.

[Verwijderd]

whoami schreef op woensdag 28 februari 2007 @ 22:20:
Je kan ook een internal setter maken... Dan scherm je het geheel toch al iets meer af.

Hmmm, ja, dat is wel netjes, maar je zou nog steeds niet in je ParentObject de readonly property kunnen aanpassen...

Tenminste, normaal gesproken niet... Ik kwam deze thread tegen dmv van jou hint, en post 6 lijkt interessant, ga daar morgen eens wat uitgebreider naar kijken, en of ik deze kan gebruiken

[Woy]

In de framework libraries ( bijvoorbeeld in de Parent/Child relatie van Control ) maken ze inderdaad gebruik van een internal functie AssignParent(Control);

wat je ook kan doen is gewoon zo ( zoals whoami voorstelt )

C#:

public object Parent
{
    get{ return parent; }
    internal set { parent = value; }
}

Dan is je property voor de buitenwereld gewoon read only maar kan je in je library gewoon de property setten.