Comments on: Skummelt med virtuelle metoder

By: Mark Nijhof

Mark Nijhof — Wed, 02 Dec 2009 10:40:57 +0000

I guess perhaps one reason for the methods in FNH to be virtual is because they use Castle DynamicProxy. WIll think a bit if I can dind an other valid reason :)

By: Torbjørn

Torbjørn — Wed, 02 Dec 2009 10:15:51 +0000

Mark, I haven’t used Flient NHibernate, so I don’t know the particulars you are talking about. This post is based on advise from C# guru Bill Wagner, and this is some of what he is saying:

“Calling virtual functions in constructors works only under the strictest of conditions. The derived class must initialize all instance variables properly in variable initializers. That rules out quite a few objects: Most constructors take some parameters that are used to set the internal state properly. So you could say that calling a virtual function in a constructor mandates that all derived classes define a default constructor, and no other constructor”

If anyone have a real use case for calling virtual methods in a constructor, I would like to see it – and then help you refactor it ;)

By: Mark Nijhof

Mark Nijhof — Wed, 02 Dec 2009 09:54:46 +0000

Hmm weird, I remember to call virtual methods on my base class for f.ex. Fluent NHibernate MapClass stuff, R# tells you that you shouldn’t but you can and it will compile just fine. One way of cheating is to create a private method that calls the virtual method and call that from the Ctor.

But perhaps I missed something in the translation :)

By: Rune Grimstad

Rune Grimstad — Wed, 02 Dec 2009 09:26:54 +0000

Som sagt, eksempelet er ikke veldig bra, men read-only properties for statiske data fungerer fint det. Det er kjappere enn å ha en privat variabel som du skriver til. Bruddet er i propertyen. Denne vil kompileres til en metode som heter get_WorkPosition() og denne vil også være virtual. Så ved å bruke denne fra konstruktøren vil du få trøbbel. Søkt kanskje, men det er en mulig situasjon. hehe.

Jeg er helt enig angående det å ha kontroll – det er veldig lett å tro at man har oversikten for så å miste den. Så jeg synes ikke man skal unngå dette for en hver pris, men er helt enig i at man skal være forsiktig. Veldig forsiktig!

By: Anders Knutsen

Anders Knutsen — Wed, 02 Dec 2009 09:07:43 +0000

Rune Grimstad: Å ha virtuelle metoder er bare risikabel praksis i de tilfellene hvor man bruker en metode/property i konstruktøren til baseklassen. Hvis man ikke gjør dette vil ikke resharper reagere, da det tross alt bare er en ordinær override.

By: Torbjørn

Torbjørn — Wed, 02 Dec 2009 09:04:10 +0000

Jeg bruker CodeRush selv, og har ikke sett at den gir noen advarsel på dette, så her er ReSHarper hakket bedre ser det ut til.

Utfordringer i det du sier ligger i at man gjerne *mener* at man har kontroll, men at det i praksis er urealistisk. Hva vet du om hvordan programvaren du skriver i dag ser ut om to år? Hva vet du om dem som kommer til å bruke klassene dine, og ikke minst, hva vet de om deg og dine antagelser? “Kontroll” er noe man har på prosjekter med én utvikler og varihet én uke eller mindre. Etter helgen er det lett å gjøre feil når objektene ikke oppfører seg som man intuitivt forventer.

Eksempelet ditt gir forøvrig ikke helt mening for meg. Hvor er bruddet på denne regelen? Og overstyrer du virkelig implementasjonen av en property for å endre data? :)

By: Rune Grimstad

Rune Grimstad — Wed, 02 Dec 2009 08:35:38 +0000

ReSharper advarer også mot dette.
Det er absolutt en risikabel praksis, men har du kontrollen så synes jeg ikke det er noe problem å gjøre det. Noen ganger kan det tenkes at baseklassen gir en default-verdi, men at du ønsker å override denne i en subklasse.
For å ta et dumt eksempel: Si at du har en Employee-klasse med en read-only property som gir WorkPosition: public virtual string WorkPosition { get { return “Employee”; } }
Så har du en manager-klasse som arver fra employee, men der du vil overridde WorkPosition til å returnere “Manager”. Her vil du få denne advarselen, men du har kontroll og ønsker at det skal være slik.
Nå var dette et simpelt eksempel, for det er andre bedre måter å gjøre dette på, men poenget er at selv om advarselen er godt begrunnet så er det ikke gitt at du absolutt må følge den. :-)