Sealed metode i en abstrakt klasse

Du kan undlade at lave din metode virtual. Så vil din kode altid kalde din metode.

Du kan ikke forhindre dem der extender i at lave en new metode, som de så kalder.

Pointen i en sealed metoder er:

class A - virtual
class B extends class A - sealed override
class C extends class B - kan ikke override (d.v.s. metoden er ikke længere virtual)

Tak for svaret.
Kan det virkeligt passe, at jeg i så tilfælde må gå på kompromis med mine nuværende design ideer? Jeg vil gerne lave et framework til andre udviklere hvor de kan lave udvidelser til min applikation (kræver blot at de nedarver fra mine baseclasses), men jeg vil gerne have noget funktionalitet som de ikke kan få lov til at rode med.

Det kan du vel også.

Hvis du laver en ikke virtuel foobar metode, så vil al din kode kalde den metode.

Hvis brugerne laver en foobar metode (med samme signatur) kan de kalde den fra deres
kode.

Så er alle vel glade.

Hvad mener du helt præsis med metode de ikke skal rode med?...

Scenarie A: Dine "kunder" må gerne kalde metoden, men ikke over skrive den.

- Gør som Arne V foreslår.
- Lav din metode internal og lav en public metode der exponere den.

Scenarie B: Dine "kunder" må ikke kalde den eller overskrive den, men du har brug for at kalde den fra andre steder end klassen selv.

- Lav den internal.

===============================================================

For demonstration af det Arne V understreger.

    class Program
    {
        static void Main(string[] args)
        {
            B b = new B(); b.M();
            A a = b; a.M();
        }
    }

    public abstract class A
    {
        public void M() { Console.WriteLine("A.M"); }
    }

    public class B : A
    {
        public new void M() { Console.WriteLine("B.M"); }
    }

Giver:

B.M
A.M

Hvis det gør det lidt mere tydeligt for dig :)

Ja lige for yderligere klarlighed kan vi jo lige:

===============================================================

    class Program
    {
        static void Main(string[] args)
        {
            B b = new B(); b.M(); b.M2();
            A a = b; a.M(); a.M2();
        }
    }

    public abstract class A
    {
        public void M() { Console.WriteLine("A.M"); }
        public virtual void M2() { Console.WriteLine("A.M2"); }
    }

    public class B : A
    {
        public new void M() { Console.WriteLine("B.M"); }
        public override void M2() { Console.WriteLine("B.M2"); }
    }
===============================================================

som giver:

B.M
B.M2
A.M
B.M2

den metode som ikke er makeret virtual, kan kun overskrives ved brug af new keywordet, og læg mårke til at selv om du i alle tilfælde har fat i en B, så når du betragter den som en A (Up caster den). Så er det A's M() der bliver kaldt og IKKE B's...

modsat med den der er makeret med virtual og kan overskrives med keywordet override, her bliver B's metode altid kaldt hvad end vi betragter objectet som A eller B.

Hej begge.
Jeg kan fint følge jeres eksempler, men humlen i det jeg gerne vil hen til, er at mine "kunder" ikke må lave deres egen implementation af én eller flere metoder i min baseclass. Det kan jeg så forstå, at jeg ikke kan sikre mig. Dét jeg egentligt gerne ville, var at sikre mig imod, at kunderne kunne anvende New keywordet på f.eks metode M

Er der nogen pointe ?

Din M og deres M er forskellige metoder.

De kan jo under alle omstaendigheder lave en MM metode.

Og der er ikke rigtig forskel paa om de kalde deres MM eller new M.

Hvad er din bekymring ?

Dit eksempel med logning boer ikke vaere et problem. Al din kode vil kalde din
lognings metode. Og det er vel ikke dit ansvar hvilken lognings metode
deres kode kalder.

Mit "problem" er, at jeg vil være 100% sikker på, at det altid er min - og kun min - implementering der bliver kaldt.

Der er tale om udvikling af et framework, hvor kunden kan tilpasse dele af funktionaliteten via nedarvning fra abstrakte klasser, samtidig med at andre dele er låst fast - herunder logging. For at sikre at loggingen altid følger samme metodik - og skriver samme sted - er det derfor vigtigt for mig, at kunden ikke overskriver denne funktionalitet.

Hvis M er ikke virtual vil kode skrevet af dig altid kalde din M.

Hvis det er kode skrevet af kunden saa kan han kalde en MM metode eller en new M metode.

Du kan jo aabenlyst ikke forhindre ham i at lave en MM metode. Men C# giver dig heller
ikke mulighed for at forhindre ham i at lave en new M metode.

Hvis hans logning skal vaere konsistent med din logning, saa maa du dokumentere
hvad de skal goere.

Eller hvis du er til den slags saa lever en build procedure de skal bruge som
injecter al logning via AOP.

De kan stadig bruge en anden build procedure, men at genbruge en build procedure der
virker er nok mere sandsynligt end at de faktisk laeser dokumentation. Dokumentation
er jo som bekdnt noget man foerst laeser naar det ikke virker.

Hej Arne
Tak for dine kommentarer. Giv et svar så får du pointene.

svar

Pi... kom til at trykke på den forkerte. Én gang til Arne

svar