Jeg ved, at der er spørgsmål om at kalde basemetoden inde i en tilsidesat metode såsom dette . Men hvad hvis en tilsidesat metode kun kalder basisklassen? Er dette dårligt / godt værd? Det virker bare mærkeligt, hvorfor tilsidesætte en metode bare for at ringe til basen alligevel?
Se for eksempel:
public class BaseClass { virtual public void Method1() { //Do stuff } } public class InheritingClass : BaseClass { override public void Method1() { base.Method1(); } } Kommentarer
- Det tjener intet formål og kludrer bare koden, så slip den.
- @DavidArno at ' s hvad jeg også tænkte, bare sørg for, at der ikke var ' en grund til det, før jeg gjorde det
- I en ideel verden vil appen blive dækket af enhedstest, så du kunne fjerne det, og når alle testene stadig bestod, ' d ved, at det ikke var ' t nødvendigt. Vi lever ikke ' dog altid i den ideelle verden, så det var fornuftigt at spørge 🙂
- Den eneste grund til, at jeg ' Lad koden ligne det ovenstående ville være, hvis der tidligere var mere kode i den tilsidesatte metode, og den blev fjernet, men kunne ses gennem gamle versioner i kildekontrolsystemet. Efterladelse af en artefakt i den aktuelle kode som denne kan signalere til dev i dag om at se filens ' historie for den tidligere version af metoden.
Svar
Men hvad hvis en tilsidesat metode kun kalder basisklassen? Er dette dårligt / godt design?
Dårligt design ? Nej, temmelig dårlig implementering. Det er vildledende for vedligeholdelsesprogrammereren. Når jeg ikke kan se en tilsidesættelse, ved jeg ved , at basen kaldes. En tilsidesættelse fortæller mig, at der er noget andet, selvom basen også kaldes derinde.
At kræve en tilsidesættelse for at ringe til basen uden en skabelon er dårlig design
Refereret tråd – mest populære answser
Min indledende reaktion på den skandinaviske tilsidesættelse model er: CODING HORROR! Det ser ud til, at jeg er tvunget til at læse alt dette og derefter mere for at sikre, at “underadfærd” ikke bryder min kode og omvendt.
Skabelonmetodemønster er en god måde at udtrykke variabel kode inden for et større kodestrøm og sikre korrekt udførelsesrækkefølge.
Efter min erfaring er det så typisk for en underklasse at skulle vide hvilke basedeklarerede metoder at kalde og i rækkefølge. Tag en dyb håndfuld underklasser alle med samme cut-n-paste kontrolstruktur, tilføj 5 års vedligeholdelse; nu forstår du hvorfor jeg foretrækker 101 bevis Vilde Tyrkiet .
P.S. Alt dette er en stor grund til, at jeg skinner mod overbrug af interface s i stedet for abstract klasser.
Kommentarer
- Overanvendelse af grænseflader i C # kommer sandsynligvis fra ikke at ville binde implementereren til den specifikke abstrakte basisklasse. Brug af en grænseflade giver implementereren mulighed for at implementere en anden baseklasse og ikke kun den specifikke abstrakte klasse. Det afhænger dog meget af omstændighederne. Jeg finder en god praksis er at have både en
IFoogrænseflade og enFooBaseklasse, som implementererIFoointerface, med abstrakte metodeopkald til rekvisitterne og autoegenskaber. Måske også indsætte en ctor.
Svar
IMO, virtual metoder, i basisklasse, har meget grundlæggende implementering. Selvom vi override definitionen af virtual -metoden i barneklasse, kan vi stadig kalde virtual -metode (med grundlæggende implementering), mens den giver mening og ikke påvirker den tilsigtede opførsel af overridden -metoden i underklassen.
For eksempel BaseCalculator gør det rigtige arbejde. Lommeregner dekorerer BaseCalculator-biblioteket ved at udvide det.
public class BaseCalculator { public virtual T Add<T>(T number01, T number02) { return number01 + number02; } } public class Calculator: BaseCalculator { public override T Add<T>(T number01, T number02) { Console.WriteLine(number01 + " | " + number02); var result = base.Add<int>(1, 3); Console.WriteLine("Result: "+ result); return result; } } Q: Hvad hvis en tilsidesat metode kun kalder basisklassen?
A: I dit tilfælde har baseklassemetoden som virtual, vi behøver ikke at override det, før vi vil ændre dets adfærd.
Spørgsmål: Er dette dårlig / god deign?
A: Ja, det kan være dårligt design, da det kan rod i kildekodefilen, mens vi tilføjer unødvendige tilsidesættelser.
Q: Det virker bare mærkeligt, hvorfor tilsidesætte en metode bare for at ringe til basen alligevel?
A: BaseCalculator gør det rigtige arbejde . Lommeregner dekorerer BaseCalculator-biblioteket ved at udvide det.
Håber det hjælper!