C# Collectie capaciteit

[cablepokerface]

Hoi tweakers, ik probeer een object in c# te laten inheriten van een generic collection, zoiets dus:

public class MyObject : List<ISomeInterface> { }

niets raars op zich. Het probleem is dat ik een maximaal aantal items wil toestaan, bijv 50. en daarna een exception wil gooien. Nu heeft het generic list object wel een capacity property, maar die doet niets dan aangeven dat bij een aantal items de collectie geresized moet worden door de run-time. Dat lost dus niets op.

Een andere oplossing is de Add te overriden en als die boven een aantal items komt een exception gooien, maar ja, dan moet je ook de AddRange, Insert en InsertRange overriden en dat is geen code waarvan ik intens kan genieten.

Iemand ideeen?

[_Thanatos_]

Wat je zelf al aangeeft. Wat is daar mis mee?

Anders maak je toch een descendant van List<T>, en dan weer een descendant van je LimitedList<T>

[DrDelete]

cablepokerface schreef op maandag 10 september 2007 @ 01:27:
Een andere oplossing is de Add te overriden en als die boven een aantal items komt een exception gooien, maar ja, dan moet je ook de AddRange, Insert en InsertRange overriden en dat is geen code waarvan ik intens kan genieten.

Iemand ideeen?

Wat is daarmee mis mee? Je kunt toch 1 method maken die de check doet? Je doet dan de call naar deze method bij binnenkomst van de 3 genoemde overriden methods.

[MTWZZ]

Als je nou eens een class maakt LimitedList en die de IList<T> en ICollection<T> interfaces laat implementeren dan kom je volgens mij een heel eind.
Je kunt dan intern een gewone List<T> bijhouden en met de implementaties van Add, Remove etc controleren of er nog items in je interne List<T> bijkunnen.

[ Voor 34% gewijzigd door MTWZZ op 10-09-2007 08:33 ]

[gorgi_19]

MTWZZ schreef op maandag 10 september 2007 @ 08:32:
Als je nou eens een class maakt LimitedList en die de IList<T> en ICollection<T> interfaces laat implementeren dan kom je volgens mij een heel eind.
Je kunt dan intern een gewone List<T> bijhouden en met de implementaties van Add, Remove etc controleren of er nog items in je interne List<T> bijkunnen.

Maak je dan niet een moeilijkere variant van een overriden List(of T)?

[MTWZZ]

^^ Ja klopt wel maar ik weet niet wat de TS verder nog aan functionaliteit wil toevoegen

[Janoz]

JE kunt toch gewoon die class extenden en dan de afmeting veranderende functies wrappen? Gewoon een check erbij die de maxGrootte vergelijkt en mocht dat in orde zijn gewoon super.addRange doen.

[Niemand_Anders]

C#:

new public int Add(T item)
{
    ValidateCapacity();
    base.Add(item);
}
private void ValidateCapacity()
{
    if (base.Count + 1 > this.capacity) //capacity dient te worden gezet in constructor
        throw new CapacityOutOfRangeException();
}

Als je dat te veel werk vind, is misschien programmeren niet jouw 'ding'.

[prototype]

Met alle respect, waarom zou je niet eerst vooraf aan een add controlleren wat de capaciteit is van een lijst? Dit is gewoon een preconditie dunkt me, en ik zie eigenlijk niet echt een goede reden waarom je het anders zou willen afhandelen. Een exception in dit geval is daarbij ook nog eens veel duurder dan even een preconditie checken...

[RobIII]

prototype schreef op maandag 10 september 2007 @ 10:45:
Met alle respect, waarom zou je niet eerst vooraf aan een add controlleren wat de capaciteit is van een lijst? Dit is gewoon een preconditie dunkt me, en ik zie eigenlijk niet echt een goede reden waarom je het anders zou willen afhandelen. Een exception in dit geval is daarbij ook nog eens veel duurder dan even een preconditie checken...

Omdat je dan misschien op 1001 plaatsen je code moet aanpassen omdat overal die .add gebruikt wordt?

[prototype]

RobIII schreef op maandag 10 september 2007 @ 11:03:
[...]

Omdat je dan misschien op 1001 plaatsen je code moet aanpassen omdat overal die .add gebruikt wordt?

Oh en dat moet je met die exception niet? Of handel jij ze maar lekker niet af?

[whoami]

prototype schreef op maandag 10 september 2007 @ 10:45:
Met alle respect, waarom zou je niet eerst vooraf aan een add controlleren wat de capaciteit is van een lijst? Dit is gewoon een preconditie dunkt me, en ik zie eigenlijk niet echt een goede reden waarom je het anders zou willen afhandelen. Een exception in dit geval is daarbij ook nog eens veel duurder dan even een preconditie checken...

Met RobIII, en, in dit geval is het gewoon goed om een exceptie te gebruiken. Als je zegt dat je eigen list slechts 'capacity' aantal element kan bevatten, en je overschrijdt die grens, dan gooi je gewoon een exceptie. So what dat het duur is, het is iets wat normaal gezien niet mag optreden (in dit geval).

[Woy]

prototype schreef op maandag 10 september 2007 @ 11:05:
[...]


Oh en dat moet je met die exception niet? Of handel jij ze maar lekker niet af?

Tuurlijk kan je het ook als pre-conditie gebruiken, maar als je deze collection bijvoorbeeld in een library implementeerd zou ik ook zeker de check nog in de collection doen en een exception gooien dat er niet aan de conditie voldaan is.

Ik ben wel met je eens dat je dit mechanisme niet moet gaan gebruiken om te detecteren dat je over de limiet heen bent gegaan als dat normaal voor kan komen in je code.

[cablepokerface]

Dank je voor jullie reacties. Er blijkt een concensus te zijn dat dit mooie code is:

C#:

public new void Add(IVehicle drivable)
{
  CheckCapacity();

  base.Add(drivable);
}
        
public new void AddRange(IEnumerable<IVehicle> drivables)
{
  CheckCapacity();

  base.AddRange(drivables);
}

public new void Insert(int index, IVehicle drivable)
{
  CheckCapacity();
            
  base.Insert(index, drivable);
}

public new void InsertRange(int index, IEnumerable<IVehicle> drivables)
{
  CheckCapacity();

  base.InsertRange(index, drivables);
}

private void CheckCapacity()
{
  if (this.Count == Capacity)
  {
    throw new Exception("The maximum amount of drivable object in this collection have been reached. Remove objects first before re-adding.");
  }
}

Daar ben ik het niet helemaal mee eens. Hoe meer je override van je base class des te meer je jezelf achter je oren moet krabben of je wel goed bezig bent heb ik altijd geleerd. Misschien is encapsulation van een collectie een optie ...

Anyways, jammer dat een collectie in het framework niet bestaat die dir heeft ingebouwd.

[cablepokerface]

Als je dat te veel werk vind, is misschien programmeren niet jouw 'ding'.

He 'Niemand_Anders', zullen we onze programmeurs ego's maar buiten de discussie laten? Dat praat lekkerder.

Thx.

[Janoz]

Mwah, ik vind een lijst die bij de maximum waarde een exception gooit een redelijk exotische functionaliteit en het lijkt me dan ook dat deze niet in een generiek framework thuis hoort.

Je code klopt trouwens van geen kanten. Een lijst met 49 elementen waar ik een range van 2 aan toevoeg gaat gewoon lukken in je voorbeeld (met een maxCapacity van 50)

Hoe meer je override van je base class des te meer je jezelf achter je oren moet krabben of je wel goed bezig bent heb ik altijd geleerd.

Zelf nadenken is niet verboden en zomaar wat napraten zonder daar wat argumentatie bij te hebben is niet handig.

In mijn opinie zou je juist zo veel mogelijk over moeten laten aan de base class. Je voegt enkel die functionaliteit toe die je mist. Je zou er (volgens de OO black box principes) gewoon van uit moeten kunnen gaan dat je baseclass goed werkt. Door die minimale functionaliteit is de kans een stuk kleiner dat je er fouten in maakt (is nog wel aanwezig zoals uit je code blijkt ).

[whoami]

Hoe meer je override van je base class des te meer je jezelf achter je oren moet krabben of je wel goed bezig bent heb ik altijd geleerd

Volgens mij heb je dat dan niet goed geleerd/een foute leermeester gehad.
Waarom zou dat an sich verkeerd zijn ? Als je die functionaliteit nu wil hebben, waarom zou je het overriden van meerdere (3 in dit geval) methods een teken zijn van 'niet goed bezig zijn'.
Zowiezo hebben Add en AddRange een gelijkaardige betekenis , en is het dus niet abnormaal om beide methods te overriden.

Note:
Ik zie nu net dat je die methods niet overrided, maar gewoon een 'nieuwe' betekenis aan Add, AddRange, etc... hangt. Maw, je implementeerd zelf nog nieuwe Insert / InsertRange / Add, ... methods.
Wat je moet doen is gewoon je eigen collection inheriten van Collection<T> en de nodige methods overriden:

code:

public class MyCollection<T> : Collection<T>
{
     protected override InsertItem( int index , T item )
     {
         CheckCapacity ();
         base.InsertItem (index, item);
     }
}

Moet je wel nog even de xxxRange methods zelf gaan implementeren, want voor zover ik zie, heeft Collection<T> deze functionaliteit niet.

[ Voor 6% gewijzigd door whoami op 10-09-2007 11:47 ]

[prototype]

whoami schreef op maandag 10 september 2007 @ 11:06:
[...]

Met RobIII, en, in dit geval is het gewoon goed om een exceptie te gebruiken. Als je zegt dat je eigen list slechts 'capacity' aantal element kan bevatten, en je overschrijdt die grens, dan gooi je gewoon een exceptie. So what dat het duur is, het is iets wat normaal gezien niet mag optreden (in dit geval).

Met seperation of concerns in het achterhoofd, zou ik dit dan toch echt liever oplossen middels AOP of via zoiets als observer pattern als pre- en postcondities echt bezwaarlijk zijn (waarom zou ik nog steeds niet weten, maar goed). In het geval van observer pattern zou je dan de list observable kunnen maken, en een capacityobserver kunnen schrijven die bij notification dus checked of de list aan z'n limiet zit. Het probleem met zo'n oplossing is dat het mosterd na de maaltijd is, i.e. het element is al toegevoegd aan de lijst en de lijst al in een invalid state terecht gekomen is om het in formele methoden uit te drukken. Daarmee is het niet bepaald een robuuste operatie te noemen...

Met Janosz voor de rest

[ Voor 3% gewijzigd door prototype op 10-09-2007 11:33 ]

[DrDelete]

cablepokerface schreef op maandag 10 september 2007 @ 11:08:
Dank je voor jullie reacties. Er blijkt een concensus te zijn dat dit mooie code is:

C#:

public new void Add(IVehicle drivable)
{
  CheckCapacity();

  base.Add(drivable);
}
        
public new void AddRange(IEnumerable<IVehicle> drivables)
{
  CheckCapacity();

  base.AddRange(drivables);
}

public new void Insert(int index, IVehicle drivable)
{
  CheckCapacity();
            
  base.Insert(index, drivable);
}

public new void InsertRange(int index, IEnumerable<IVehicle> drivables)
{
  CheckCapacity();

  base.InsertRange(index, drivables);
}

private void CheckCapacity()
{
  if (this.Count == Capacity)
  {
    throw new Exception("The maximum amount of drivable object in this collection have been reached. Remove objects first before re-adding.");
  }
}

Daar ben ik het niet helemaal mee eens. Hoe meer je override van je base class des te meer je jezelf achter je oren moet krabben of je wel goed bezig bent heb ik altijd geleerd. Misschien is encapsulation van een collectie een optie ...

Anyways, jammer dat een collectie in het framework niet bestaat die dir heeft ingebouwd.

Oeps... bijna zoals ik het in gedachten had maar let nog op het volgende:

• Zoals Janoz al aangaf: check op >= 50 ipv == 50
• Throw geen generieke Exception maar in dit geval een InvalidOperationException omdat de state van jouw object op dat moment niet voldoet aan de verwachtingen

[cablepokerface]

Je code klopt trouwens van geen kanten. Een lijst met 49 elementen waar ik een range van 2 aan toevoeg gaat gewoon lukken in je voorbeeld (met een maxCapacity van 50)

Daar heb je helemaal gelijk in. Ik heb het ff uitgetypt om te benadrukken wat ik bedoelde maar het klopt idd niet.


WhoAmI: wat betreft de argumenten. Ik heb het een van de beste geleerd (echt waar).
Inheritance (en het juist gebruiken daarvan) is meestal een vrij precies werkje. Bij grote projecten kun je niet in iedere subclass het gedrag van de parent op veel plaatsen aanpassen. Dit is nu 1 object maar schaal dat eens op naar 1000 objecten (niet ongewoon). Op het moment dat je dan het gedrag van de base class wijzigt heb je niets minder dan een onderhouds ramp.

[ Voor 4% gewijzigd door cablepokerface op 10-09-2007 11:33 ]

[gorgi_19]

En met die AddRange ga je de mist in; je kan zo meer dan 1 object toevoegen aan de collection.

WhoAmI: wat betreft de argumenten. Ik heb het een van de beste geleerd (echt waar).
Inheritance (en het juist gebruiken daarvan) is meestal een vrij precies werkje. Bij grote projecten kun je niet in iedere subclass het gedrag van de parent op veel plaatsen aanpassen. Dit is nu 1 object maar schaal dat eens op naar 1000 objecten (niet ongewoon). Op het moment dat je dan het gedrag van de base class wijzigt heb je niets minder dan een onderhouds ramp.

Als het niet mag, dan maak je de method / class wel sealed Je wel een ramp als je methods gaat shadowen, die zijn erg lastig te vinden

[ Voor 76% gewijzigd door gorgi_19 op 10-09-2007 11:37 ]

[whoami]

prototype schreef op maandag 10 september 2007 @ 11:30:
[...]


Met seperation of concerns in het achterhoofd, zou ik dit dan toch echt liever oplossen middels AOP of via zoiets als observer pattern als pre- en postcondities echt bezwaarlijk zijn (waarom zou ik nog steeds niet weten, maar goed). Je zou dit idd met AOP kunnen oplossen, maar ik vraag me gewoon af waarom je het 'niet goed' vind om in het geval dat de capacity overschreven wordt, een exceptie te gooien.

Je zou kunnen een aspect maken die dit doet, maar je kan in dit geval evengoed die check doen door die ene method te overriden en een andere method op te roepen.
De AOP weaver zal gewoon net hetzelfde doen.
Maw: zoveel voordeel zie ik er niet in om hier AOP te gaan gebruiken, maar het kan wel.

In het geval van observer pattern zou je dan de list observable kunnen maken, en een capacityobserver kunnen schrijven die bij notification dus checked of de list aan z'n limiet zit. Het probleem met zo'n oplossing is dat het mosterd na de maaltijd is, i.e. het element is al toegevoegd aan de lijst en de lijst al in een invalid state terecht gekomen is om het in formele methoden uit te drukken. Daarmee is het niet bepaald een robuuste operatie te noemen...

Dit is niet alleen mosterd na de maaltijd, maar ook nog eens een hele complexe manier om een simpel probleem op te lossen.

[whoami]

WhoAmI: wat betreft de argumenten. Ik heb het een van de beste geleerd (echt waar).
Inheritance (en het juist gebruiken daarvan) is meestal een vrij precies werkje. Bij grote projecten kun je niet in iedere subclass het gedrag van de parent op veel plaatsen aanpassen. Dit is nu 1 object maar schaal dat eens op naar 1000 objecten (niet ongewoon). Op het moment dat je dan het gedrag van de base class wijzigt heb je niets minder dan een onderhouds ramp.

Het 'van de beste geleerd hebben', is een non-argument. En zeker als die persoon zichzelf als 'één van de beste' uitroept. Nu wil ik niets negatiefs ofzo over die persoon zeggen.
Echter, dat jij het geleerd hebt van één van de beste leermeesters, is geen garantie dat jij het ook daadwerkelijk goed opgepikt hebt.

Zoals ik al in m'n post zei, gebruik je in dit geval inheritance niet goed.
Je override nergens een method. Je schrijft gewoon 'nieuwe' Insert / Add, etc... methodes die de originele hiden. Hier zal je dus mee in de problemen komen als je wilt gebruik maken van polymorphisme:

code:

BaseCollection c = new MyCollection();
c.Add (1);

Hier zal niet de Add method van MyCollection aangeroepen worden, maar de Add method van BaseCollection.

Dit is nu 1 object maar schaal dat eens op naar 1000 objecten (niet ongewoon). Op het moment dat je dan het gedrag van de base class wijzigt heb je niets minder dan een onderhouds ramp.

Je bedoelt 1 class / 1000 classes.
Nou, als jij het niet ongewoon vind om 1000 verschillende inheritors te hebben, dan denk ik dat er toch iets mis is met dat project hoor...

[ Voor 28% gewijzigd door whoami op 10-09-2007 11:44 ]

[Janoz]

cablepokerface schreef op maandag 10 september 2007 @ 11:32:
WhoAmI: wat betreft de argumenten. Ik heb het een van de beste geleerd (echt waar).

Ik vroeg om de argumenten, en 'het komt van de beste' is geen argument.

Inheritance (en het juist gebruiken daarvan) is meestal een vrij precies werkje. Bij grote projecten kun je niet in iedere subclass het gedrag van de parent op veel plaatsen aanpassen. Dit is nu 1 object maar schaal dat eens op naar 1000 objecten (niet ongewoon). Op het moment dat je dan het gedrag van de base class wijzigt heb je niets minder dan een onderhouds ramp.

Bekijk het eens de andere kant op. Wat nu als je in 1000 objecten collectie functionaliteit aan het bouwen terwijl dat ook gewoon in 1 base class kan? Dat lijkt me pas een onderhoudsramp.

@DrDelete: Dat is bij lange na niet het enige. Een dergelijke generieke validator gaat de mist in bij meerdere toe te voegen objecten, zoals Gorgi al aangeeft.

[ Voor 8% gewijzigd door Janoz op 10-09-2007 11:43 ]

[__fred__]

whoami schreef op maandag 10 september 2007 @ 11:37:
[...]

Je zou kunnen een aspect maken die dit doet, maar je kan in dit geval evengoed die check doen door die ene method te overriden en een andere method op te roepen.
De AOP weaver zal gewoon net hetzelfde doen.
Maw: zoveel voordeel zie ik er niet in om hier AOP te gaan gebruiken, maar het kan wel.

[...]
Dit is niet alleen mosterd na de maaltijd, maar ook nog eens een hele complexe manier om een simpel probleem op te lossen.

En niet te vergeten baggertraag. Bekijk je performance maar eens als je de eerste keer je AOP collection instantieert.

[prototype]

whoami schreef op maandag 10 september 2007 @ 11:37:
[...]
Je zou dit idd met AOP kunnen oplossen, maar ik vraag me gewoon af waarom je het 'niet goed' vind om in het geval dat de capacity overschreven wordt, een exceptie te gooien.

Omdat het in dit geval niet meer voordeel biedt dan het controlleren op een preconditie, wat het toch echt is. In het bijzonder is het een preconditie op de add operatie van een lijst, wat eigenlijk een klassiek schoolvoorbeeld is. De exception zul je hoe dan ook af moeten handelen (tenminste, dat lijkt me wel handig), en het argument van meer/minder lijntjes code zoals dit door robIII is aangekaart gaat dan ook niet op imho. Het is daarbij ook de vraag of het wel zo verstandig is om 'net zo lang door te gaan tot het fout gaat (i.e. dat de exception gegooid wordt)', als je al aan kan zien komen DAT het fout gaat als de operatie doorgaat. Zeker met formele methoden in 't achterhoofd houdend. Exceptions dienen dan eigenlijk gezien te worden als de 'last resort' om valideheid (is dat een woord? ) af te dwingen.

Mijn bezwaar daarbij is ook dat je een implementatie restrictie oplegt. Je maakt in feite een implementatie van een lijst die een restrictie heeft op het bepaald aantal elementen dat het kan bevatten. De superklasse daarentegen specificeert dit niet, en als je dan polymorfie toepast, dan is dat eventueel een probleem in dat het gedrag wel plaatsvindt maar niet voor die supertype gespecificeerd is.

Je zou kunnen een aspect maken die dit doet, maar je kan in dit geval evengoed die check doen door die ene method te overriden en een andere method op te roepen.
De AOP weaver zal gewoon net hetzelfde doen.
Maw: zoveel voordeel zie ik er niet in om hier AOP te gaan gebruiken, maar het kan wel.

Uiteraard zal de weaver hetzelfde doen, maar dat is het hele punt dan ook. Echter zal deze crosscutting concern niet in de business logics zitten, en dat is imho wel wat flexibeler.

[...]
Dit is niet alleen mosterd na de maaltijd, maar ook nog eens een hele complexe manier om een simpel probleem op te lossen.

Vindt je? Een lijst subclassen zoals je voorstelt met exception afhandeling is misschien even 'complex' (maar wel veel sterker gecoupled en daardoor ook minder flexibel.)

__fred__ schreef op maandag 10 september 2007 @ 11:50:
[...]


En niet te vergeten baggertraag. Bekijk je performance maar eens als je de eerste keer je AOP collection instantieert.

Dat is apart, want in wezen wordt slechts een aspect gesuperimposed op de before joinpoint van de add code. En in dit geval is dat niet bepaald dure code te noemen. Ik zal dit wel even testen wanneer ik thuis ben

[ Voor 20% gewijzigd door prototype op 10-09-2007 11:58 ]

[whoami]

Uiteraard zal de weaver hetzelfde doen, maar dat is het hele punt dan ook. Echter zal deze crosscutting concern niet in de business logics zitten, en dat is imho wel wat flexibeler.

Is het 'checken of de capacity niet overschreden is' in dit geval geen 'business' logic ? Eigenlijk moet ik eerder zeggen 'core' logic, want het gaat hier helemaal niet over echte 'business' logica.
Het checken of de capacity al of niet overschreden is , is hier geen 'cross cutting' concern. Het is de enige logica en de enige bestaansreden van die class. De topicstart wil nl. een collection-class hebben die een max. aantal items (whatever het type) kan bevatten.
Het is gewoon een class die deel zou kunnen uitmaken van een framework

[prototype]

whoami schreef op maandag 10 september 2007 @ 11:57:
[...]
Is het 'checken of de capacity niet overschreden is' in dit geval geen 'business' logic ? Eigenlijk moet ik eerder zeggen 'core' logic, want het gaat hier helemaal niet over echte 'business' logica.
Het checken of de capacity al of niet overschreden is , is hier geen 'cross cutting' concern. Het is de enige logica en de enige bestaansreden van die class. De topicstart wil nl. een collection-class hebben die een max. aantal items (whatever het type) kan bevatten.
Het is gewoon een class die deel zou kunnen uitmaken van een framework

Niet als het een lijst is, i.e. als het een subklasse is van list. Want die specificeert dit niet, en dan mag het ook niet. Je zou een lijst in dit geval dan beter kunnen encapsuleren in een andere klasse die dit gedrag modeleert.

[whoami]

Waarom zou je het een subclass maken van List, en niet van Collection<T> (die gewoon bedoelt is om als basis - class voor collections te dienen)

[Janoz]

Waarom niet? Waarom zou een MaxCapacityList niet gewoon een subclass van List kunnen zijn?

[prototype]

whoami schreef op maandag 10 september 2007 @ 12:02:
Waarom zou je het een subclass maken van List, en niet van Collection<T> (die gewoon bedoelt is om als basis - class voor collections te dienen)

Ah, excuses, ik zie nu pas je stukje code.

Janoz schreef op maandag 10 september 2007 @ 12:03:
Waarom niet? Waarom zou een MaxCapacityList niet gewoon een subclass van List kunnen zijn?

Het is niet zozeer dat het niet mag, alles mag Maar het is alleen even de vraag of het handig is. Stel je programmeert tegen de interface List aan. Deze gaat bij de add standaard er niet van uit dat er een exception gegooid wordt (is ook niet onderdeel van de signatuur en/of specificatie), en toevoegen zou dan ook prima moeten gaan zelfs met een maxcapacity list, tenminste volgens de specificatie. De implementatie doet echter anders. Dit is het eventuele probleem dus. Natuurlijk op te lossen door niet tegen List aan te programmeren maar wat specifieker te zijn dan.

[ Voor 9% gewijzigd door prototype op 10-09-2007 12:10 ]

[Janoz]

Ah, ok. Daar kan ik inkomen, maar in principe is het blijkbaar een eis in de applicatie. Een exception wordt net zo hoog opgegooit tot hij ergens afgehandeld wordt. Hij zal dus uiteindelijk wel uitkomen in code waarin wel bekend is dat er maximaal een bepaald aantal items in terecht mogen komen.

Verder zie ik niet hoe je dat probleem oplost door AOP te gebruiken eigenlijk.

[Orphix]

prototype schreef op maandag 10 september 2007 @ 12:06:
Het is niet zozeer dat het niet mag, alles mag Maar het is alleen even de vraag of het handig is. Stel je programmeert tegen de interface List aan. Deze gaat bij de add standaard er niet van uit dat er een exception gegooid wordt (is ook niet onderdeel van de signatuur en/of specificatie), en toevoegen zou dan ook prima moeten gaan zelfs met een maxcapacity list, tenminste volgens de specificatie. De implementatie doet echter anders. Dit is het eventuele probleem dus. Natuurlijk op te lossen door niet tegen List aan te programmeren maar wat specifieker te zijn dan.

Ook wel bekend als Liskov substitution principle. En ik ben het wel met je eens. Hoewel ik goed de redering van de TS begrijp vraag ik me ook af of dit de beste oplossing is als je het probleem breder trekt.

Het probleem bij deze oplossing is dat je een classe hebt die gedrag vertoond dat niet verwacht wordt door gebruikers van de ICollection interface. Dit is niet enkel in je eigen code, maar ook in het .NET framework zelf. Zo zou ik me goed kunnen voorstellen dat een methode bijvoorbeeld tijdelijk een collectie tijdelijk met >50 opvult, om later elementen te verwijderen. Functioneel gezien zou dit geen exception mogen gooien. Technisch gezien zal dit bij deze oplossing dus wel gebeuren.

Het is ook zeer moeilijk te voorspellen waar een eventuele exception op zou kunnen treden, en dus ook om deze excepties af te handelen.

Voor de TS is het wellicht handiger om een soort van gateway te implementeren die het toevoegen van elementen op een gecontroleerde en gedefinieerde manier op een enkel punt in je code uitvoert. Maar nogmaals, dit ligt aan de aard van het probleem, waar ik jammer genoeg nog niet echt een goed zicht op heb.

[Not Pingu]

prototype schreef op maandag 10 september 2007 @ 11:50:
[...]

Omdat het in dit geval niet meer voordeel biedt dan het controlleren op een preconditie, wat het toch echt is. In het bijzonder is het een preconditie op de add operatie van een lijst, wat eigenlijk een klassiek schoolvoorbeeld is. De exception zul je hoe dan ook af moeten handelen (tenminste, dat lijkt me wel handig), en het argument van meer/minder lijntjes code zoals dit door robIII is aangekaart gaat dan ook niet op imho.

Dat hangt imho van de case af. Waarom mogen er maar max. n items in die lijst, wordt daar in de rest van de applicatie rekening mee gehouden en wat moet er gebeuren als een item wordt toegevoegd nadat de capaciteit is overschreden? Wordt dat item gedropt met of zonder melding aan de add'er, of wordt het gebufferd voor latere toevoeging?
Past de beperking van de capaciteit binnen het concept (bijv. een lijst van dagen in deze week mag maar max. 7 items bevatten) en kun je ervan uitgaan dat het toevoegen van >n items een onbedoelde fout is?

Het maken van een subclass is imho alleen genoeg als je items boven capaciteit stilzwijgend laat vallen. Anders zal toch op alle plaatsen waar een item aan de lijst toegevoegd wordt, ofwel de preconditie gechecked moeten worden, of moet een mogelijke exception worden afgevangen.

[prototype]

Janoz schreef op maandag 10 september 2007 @ 12:20:
Ah, ok. Daar kan ik inkomen, maar in principe is het blijkbaar een eis in de applicatie. Een exception wordt net zo hoog opgegooit tot hij ergens afgehandeld wordt. Hij zal dus uiteindelijk wel uitkomen in code waarin wel bekend is dat er maximaal een bepaald aantal items in terecht mogen komen.

Verder zie ik niet hoe je dat probleem oplost door AOP te gebruiken eigenlijk.

Dat is ook niet op te lossen met AOP, je zult hetzelfde probleem hebben en anders wel andere problemen. Ik noemde het meer om wat alternatieven te noemen op implementaties die evengoed slecht zijn Design by contract is gewoon imho de way to go in dit geval, en dat is ook te onderbouwen met formele methoden, e.g. schema's/specificaties m.b.t. robuuste operaties (liefhebbers hiervan verwijs ik dan ook even naar een taal zoals Z). Voor de rest, zie Orphix' post

[ Voor 5% gewijzigd door prototype op 10-09-2007 20:05 ]

[MSalters]

Het lijkt wel erg op het standaard OO probleem wat bekend staat als collection-of-apples. Voor wie dat niet kent: Zelfs als apple IS-A fruit, dan nog geldt niet dat collection-of-apples IS-A collection-of-fruit. Wat dan wel kan is: collection-of-apples IS-IMPLEMENTED-AS collection-of-fruit.