[C#] Subclasse of niet?

[riezebosch]

Ik heb een class Check. Maar nu heb ik twee soorten Checks. Een check op Value en een check op State. In eerste instantie had ik gewoon gegevens voor beide soorten checks opgenomen in de class Check. Persoonlijk vond ik dit niet zo mooi, aangezien dan niet meer duidelijk is welke gegevens bij welke check horen.

Zelf vond ik het mooiste om deze twee te subclassen van Check (welke informatie bevat die voor beide (en eigenlijk alle mogelijke) checks bevat). Het is alleen vrij lastig om in de applicatie te herkennen dát het een check is en wát voor een check het is. Ik kan dan niet meer controleren met is of het een Check is, maar wel met as Check != null

          [Check]
             |
     -----------------
     |               |
     |               |
[CheckValue]    [CheckState]

Maar nu wil ik dat het mogelijk is dat dynamisch tussen deze twee subclasses geswitcht moet kunnen worden. De gebruiker moet dus kunnen zeggen: deze Check moet geen check op Value maar een check op State worden.

Zoals ik het nu ontworpen heb, houdt dat volgens mij in dat de huidige CheckValue verwijderd moet worden, en op die plaats een CheckState ingevoegd. Dat is dus duidelijk ook niet wat ik wil.

Een derde optie is het definiëren van een interface ICheckType (oid), en hierin specificeren welke functie classes moeten hebben. In de class Check neem ik dan een ICheckType op, en kan ik at runtime die verwijzing invullen met de gewenste afgeleide class.

[Check]
-------
ICheckType c;


        [ICheckType]
        ------------
        void DoCheck;
             |
     -----------------
     |               |
     |               |
[CheckValue]    [CheckState]
------------    ------------
void DoCheck;   void DoCheck;

Alleen dat laatste vind ik weer vrij lastig met opslaan en uitlezen in XML.
Is hier een algemene aanpak voor? Of welke is anders de beste?

[whoami]

Wat is er precies lastig met het opslaan en uitlezen in xml bij dat laatste ?

Trouwens, wat is het grootste verschil tussen jouw 2de en 3de voorstel ? Als je bij jouw 2de voorstel die CheckValue en CheckState laat afleiden van een (abstracte) class Check, en je laat die 2 classes de 'DoCheck' method overriden, dan heb je toch hetzelfde ?

[riezebosch]

Dan kan ik een class Check in het geheugen houden, en daar dynamisch een andere ICheckType aan koppelen. Bij de tweede oplossing zal ik (voor zover ik zie) de huidige subclass van Check uit de structuur moeten verwijderen om op die plaats een andere toe te voegen.

Het voordeel van de laatste is ook dat ik in mijn programma geen onderscheid hoef te maken tussen wat voor soort Check ik heb; ik heb gewoon een Check En wat die Check zelf verder heeft, is dan niet van belang. Toch?

[Alarmnummer]

Toverwoord:
state (pattern)

Hiermee kan je binnen een object switchen van implementatie zonder dat dit aan de buitenkant zichtbaar is. Je geeft iedereen een referentie naar een check mee, maar als je vind dat de check globaal een andere werking moet hebben, dan verander je de werking van die check. Het is alsof je een radartje een slag omdraait zodat een andere implementatie actief wordt. Hierdoor kan 1 object zich op verschillende tijdstippen als verschillende objecten gedragen.

In het GoF boek staat dit pattern uitstekend uitgelegd, maar op het internet is ook genoeg documentatie hierover te vinden. (Alhoewel er ook een enorme lading slechte informatie is.. heb het netff gechecked namelijk)

[ Voor 108% gewijzigd door Alarmnummer op 12-07-2005 10:16 ]

[riezebosch]

Heb gelukkig het GoF boek Maar dacht dat dofactory.com wel een goeie site was?

edit:

Hoewel ik vanaf de frontpage niet de patterns kan vinden Maar op www.dofactory.com/Patterns/Patterns.aspx staan ze wel gewoon allemaal

[ Voor 37% gewijzigd door riezebosch op 12-07-2005 10:21 ]

[Alarmnummer]

riezebosch schreef op dinsdag 12 juli 2005 @ 10:14:
Heb gelukkig het GoT bnek Maar dacht dat dofactory.com wel een goeie site was?

Dat zou best kunnen. Ik had het even op google ingeklopt en zag daar niet meteen iets helders naar voren komen.

[Korben]

riezebosch schreef op dinsdag 12 juli 2005 @ 09:52:
Het is alleen vrij lastig om in de applicatie te herkennen dát het een check is en wát voor een check het is. Ik kan dan niet meer controleren met is of het een Check is, maar wel met as Check != null

Dit is pure onzin, is geeft in dit geval precies dezelfde output als as type != null. Dit klopt ook, want volgens de MSDN:

quote: http://msdn.microsoft.com.../csref/html/vclrfispg.asp

An is expression evaluates to true if both of the following conditions are met:

• expression is not null.
• expression can be cast to type. That is, a cast expression of the form (type)(expression) will complete without throwing an exception. For more information, see 7.6.6 Cast expressions.

[riezebosch]

Alarmnummer schreef op dinsdag 12 juli 2005 @ 10:05:
Toverwoord:
state (pattern)

Hiermee kan je binnen een object switchen van implementatie zonder dat dit aan de buitenkant zichtbaar is. Je geeft iedereen een referentie naar een check mee, maar als je vind dat de check globaal een andere werking moet hebben, dan verander je de werking van die check. Het is alsof je een radartje een slag omdraait zodat een andere implementatie actief wordt. Hierdoor kan 1 object zich op verschillende tijdstippen als verschillende objecten gedragen.

In het GoF boek staat dit pattern uitstekend uitgelegd, maar op het internet is ook genoeg documentatie hierover te vinden. (Alhoewel er ook een enorme lading slechte informatie is.. heb het netff gechecked namelijk)

Het bleek inderdaad het toverwoord Uiteinlijk bleek zelfs dat ik met oplossing 3 zelf al bezig was het State Pattern te implementeren. En nu ik zag dat dit zelfs een standaardoplossing is, ging het helemaal als een trein.

Korben schreef op woensdag 13 juli 2005 @ 01:34:
[...]
Dit is pure onzin, is geeft in dit geval precies dezelfde output als as type != null. Dit klopt ook, want volgens de MSDN:
[...]

Helemaal gelijk. Had het een keer geprobeerd, en dacht dat het toen mis ging (als je een vergelijk doet met een SubClass is Class). Maar blijkt inderdaad ook zonder problemen te kunnen .

[MSalters]

Je .sig is veelzeggend: het gebruik van is Class is een teken van mental mutilation. Dat doe je niet in OO. Je hoeft je dus geen zorgen te maken of het wel werkt.

[ Voor 20% gewijzigd door MSalters op 13-07-2005 14:45 ]

[Alarmnummer]

MSalters schreef op woensdag 13 juli 2005 @ 14:44:
Je .sig is veelzeggend: het gebruik van is Class is een teken van mental mutilation. Dat doe je niet in OO. Je hoeft je dus geen zorgen te maken of het wel werkt.

Mwuah.. nogal ongenuanceerd imho. Ik gebruik zelf regelmatig een instanceof. Zowel voor marker interfaces als voor een andere zaken.

[riezebosch]

MSalters schreef op woensdag 13 juli 2005 @ 14:44:
Je .sig is veelzeggend: het gebruik van is Class is een teken van mental mutilation. Dat doe je niet in OO. Je hoeft je dus geen zorgen te maken of het wel werkt.

Moet je inderdaad is nader toelichten. Voor markerclasses/interfaces is dit toch juist dé werkwijze? Of zie ik dat nu verkeerd?

[Alarmnummer]

riezebosch schreef op woensdag 13 juli 2005 @ 15:06:
[...]


Moet je inderdaad is nader toelichten. Voor markerclasses/interfaces is dit toch juist dé werkwijze? Of zie ik dat nu verkeerd?

Jij ziet het niet verkeerd.

[riezebosch]

Alarmnummer schreef op woensdag 13 juli 2005 @ 15:13:
[...]


Jij ziet het niet verkeerd.

offtopic:
Leuke reactie van je. Heb over het algemeen wel ontzag voor MSalters' kennis.