[C#] Statics en overerving

[Kama]

Ik zit met het volgende probleem:

- Ik heb een abstracte baseclass, zeg "Plugin".
- Ik heb n van A afgeleide classes zeg "PluginA" en "PluginB"

Nu wil ik een static method toevoegen die me wat informatie kan geven over de subclass die ik gebruik (UserMayLoadPlugin). In principe wil ik die code op de base stoppen omdat deze code generiek is. Er is alleen wat specifieke informatie nodig uit de afgeleide class die wat karakteristieke eigenschappen beschrijft (bij static member _IsAdminOnly).

Dat dacht ik op te lossen door aan de base class deze static members toe te voegen en die in de static construtor van de afgeleide classes te vullen. Resultaat wat ik hoopte is dat je van een afgeleide class kan vragen of ie door een bepaalde user geladen kan worden op de volgende manier:

PluginA.UserMayLoad(MyUserType user);

Het werkt echter net iets subtieler dan ik dacht. De static constructor wordt aangeroepen op het moment dat het type voor het eerst gerefereerd wordt. Dit vult het static member op baseclass niveau. Maw. de static method werkt altijd met de informatie die de laatste geinitialiseerde afgeleide class gezet heeft... En dat is niet wat ik wil.

Ik hoop dat de casus duidelijk is... Hoe zou ik dit moeten oplossen? Heeft iemand ervaring met deze structuren die me kan uitleggen hoe je dit hoort op te lossen?

---- edit ----
Ik realiseer me net dat _IsAdminOnly geen goed voorbeeld is... Dat zou je via een afgeleide klasse PluginAdminOnly oplossen. Dan maar het praktijkvoorbeeld: In een database staat of een user toegang heeft tot een plugin. Om de benodigde toegangsrecords te vinden moet bekend zijn wat de "primary key" van de plugin in de database is. Die info heb ik dus nodig: static member _PluginKey.

[ Voor 13% gewijzigd door Kama op 06-11-2007 01:42 ]

[MisterBlue]

Enige reden waarom je class methods wilt gebruiken? Ik zou dit anders gewoon via instance methods oplossen.

[BoAC]

Static functions zijn niet overerfbaar. Wat jij wil is een object factory ofzoiets. Je vraagt dan aan een factory een object van een bepaald type. De factory zoekt dan uit of de betreffende gebruiker het object/plugin/whatever mag aanmaken enz.

[4of9]

gewoon je members in je baseclasse niet static maken.

en dan in je subclasse base.JouwMethod/base.jouwMember etc. etc.

[ Voor 39% gewijzigd door 4of9 op 06-11-2007 08:54 ]

[Kama]

Bedankt voor de vroege reacties!

BoAC schreef op dinsdag 06 november 2007 @ 08:03:
Static functions zijn niet overerfbaar. Wat jij wil is een object factory ofzoiets. Je vraagt dan aan een factory een object van een bepaald type. De factory zoekt dan uit of de betreffende gebruiker het object/plugin/whatever mag aanmaken enz.

Object factory? Dat zeg me alleen vaag iets.. Dat ga ik eens nakijken.

MisterBlue schreef op dinsdag 06 november 2007 @ 07:55:
Enige reden waarom je class methods wilt gebruiken? Ik zou dit anders gewoon via instance methods oplossen.

4of9 schreef op dinsdag 06 november 2007 @ 08:53:
gewoon je members in je baseclasse niet static maken.
en dan in je subclasse base.JouwMethod/base.jouwMember etc. etc.

Dat zou een logisch gevolg zijn, maarja, dan heb ik een instance nodig en ik wil niet telkens een plugin de lucht in trekken om te controleren of ie wel de mag bestaan en dan weer afbreken. Soms zijn het meerdere plugins waar ik dit mee wil doen, dat zou naar mijn gevoel zonde zijn. Ik zou nog moeten nagaan of het mogelijk om even "snel" een plugin te constructen om aan dit soort informatie te komen.

Het "charmante" vond ik juist dat een class iets over zichzelf kan vertellen zonder geinstanteerd te hoeven zijn. Dat lijkt me precies iets wat in een static thuishoort.

[4of9]

iets wat state heeft kan niet static zijn. Dus wat je wilt kan niet echt volgens mij.

[riezebosch]

Voor zover ik weet kan je ook niet static methods abstract of virtual maken, dus kan je toch ook nooit afdwingen dat afgeleide classes ze implementeren? Dat is waar ik ook tegenaanliep toen ik met een soort van plugins bezig was.

[DrDelete]

Ik zou een static Plugin factory maken. Daar heb je alle handling in zitten die controleert op welke wijze een instance gemaakt wordt.

Op internet zijn legio voorbeelden te vinden hiervoor.

[Verwijderd]

kun je niet een custom attribute schrijven die je gebruikt in PluginA en PluginB?? Aangezien wie toegang heeft tot de afgeleide klasse een soort van metadata is. Vervolgens kun je dan mbv reflection achterhalen of je de klasse wel of niet mag gebruiken

[ Voor 25% gewijzigd door Verwijderd op 06-11-2007 10:03 ]

[Kama]

Bedankt allemaal voor de input...

4of9: Of een user toegang heeft tot een plugin is m.i. geen state (van een instance) van de plugin.

riezebosch: Inderdaad. Dat kan ik ergens wel begrijpen, maar het zou de oplossing zijn...

Een pluginfactory is waarschijnlijk nog de netste oplossing. Als ik het concept goed begrijp stop je dan alle "metadata" eigenlijk in je factory in plaats van in bijv. statics. Nu weet ik in principe wel welke afgeleide klasse ik geinstantieerd wil hebben, dus daar heb ik de factory niet voor nodig, maar de factory zou eventueel wel kunnen vertellen of een user recht heeft op een afgeleide (alleen weten of een user recht heeft is soms genoeg... ik hoef niet perse altijd een instantie):

dus: bool PluginFactory.UserMayUsePlugin(Type plugintype, User user);

Dat is wel "redelijk" netjes...

Reflection vind ik ook nog wel een aardige optie om uit te zoeken.

Voorlopig het ik het opgelost om alles toch maar op instance niveau onder te brengen en dan maar even een plugin te instantieren voor de rechtencontrole (levert hier en daar wat smerige code op). Ik denk dat ik op termijn voor de Factory ga.

Nogmaals dank.

[ Voor 4% gewijzigd door Kama op 06-11-2007 12:53 ]

[whoami]

Kama schreef op dinsdag 06 november 2007 @ 12:49:
Bedankt allemaal voor de input...

4of9: Of een user toegang heeft tot een plugin is m.i. geen state (van een instance) van de plugin.

Nee, en die verantwoordelijkheid ligt ook helemaal niet bij de plugin, maar bij de factory / manager die de plugin moet instantieëren. Die moet nagaan of de plugin kan/mag gecreeërd worden voor de bepaalde user.
Op basis van wat wil je bepalen of een user al of niet toegang mag hebben tot een plugin ?

Die info heb ik dus nodig: static member _PluginKey.

Hiervoor zou ik -zoals darkblade al aangeeft- gebruik maken van een custom attribute ipv een static member.
Dan kan je dit doen:

code:

[PluginId ("someguidid")]
class PluginA : BasePlugin
{
}

[ Voor 19% gewijzigd door whoami op 06-11-2007 13:40 ]