Re: error CS0621: virtual or abstract members cannot be private

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Peter Duniho wrote:
On Sun, 22 Feb 2009 16:56:08 -0800, cody <deutronium@xxxxxx> wrote:

Allowing *anybody* to derive from your class creates relationsships you not not want most time as inheritance is the strongest relationship between classes in existence.

There are certainly schools of thought in OOP that feel that way. But clearly, .NET/C# doesn't follow that philosophy. The OOP languages that are in the mainstream all encourage inheritance.

So generally it is discouraged to make virtual methods public,

Discouraged by whom? Public virtual members are quite common in OOP, certainly in .NET, and interfaces (found in Java and C#, as well as other languages) are basically _only_ public virtual members.

Yes it may be that this is not the opinion of everybody, just me and the authors of some books I've read.
But I feel that most of the virtual methods in the .NET framework are not public but protected (I didn't exactly count them so I may be wrong here)

instead internal or protected should be used, so why not allowing private virtual methods? To avoid things getting messy partial classes could be used.

I'm not sure where you're suggesting partial classes would help.

If you use the pattern I showed and you have a lot of derived classes as nested classes then partial classes certainly will help :)

> Have you an example of where you feel such a pattern might be useful?

Something like this, but certainly there are much more applications for this.

How is your example superior to simply making the Base.Doit() method virtual? It's not like you are somehow preventing someone from sub-classing your Base class. They can't override your private virtual method, but you've still got a public method they are going to _want_ to override and instead are going to wind up hiding (which whatever you think about public virtual methods seems to me to be much worse).

I could make the Base class constructor private so the nested classes can still derive from it but nobody else.

I also feel that combining your factory and implementation in the same class is awkward and unnecessary.

In the .NET framework this is used sometimes as in Image.FromFile().

If you want to hide _all_ of the implementation, better to make the base class private to your factory as well, the virtual method protected, and expose the API as an interface.

I'm not sure what you mean by "make the base class private to your factory".

I really can't speak for the C# designers. But, I suspect that if you asked them, they would suggest that with the current rules, developers are encouraged to keep their inheritance hierarchies and class structures simpler.

I agree with that because if they wouldn't they would have changed them :)

I don't see anything fundamentally unworkable in what you're suggesting, but it does seem awkward and likely to lead to maintenance issues.

I cannot see how *restricting* who is allowed to override a method impose maintenance issues.

The C# philosophy, at least originally, has been to keep things simple. To prefer simple rules and simple structures, even if sometimes that restricts what you can do. I suspect that's at least in part what's at play here.

Pete

"at least originally" :) Good spoken, because now we have lambda expressions, anonymous methods and delegates which are similar but different.
And extension methods are what I really call a maintenance issue ^^


--
Fun stuff, Java and C# programming, freeware games, applications and tools

www.deutronium.de.vu | www.deutronium.de.ki
.

Relevant Pages

  • Re: error CS0621: virtual or abstract members cannot be private
    ... The OOP languages that are in the mainstream all encourage inheritance. ... They can't override your private virtual method, but you've still got a public method they are going to _want_ to override and instead are going to wind up hiding (which whatever you think about public virtual methods seems to me to be much worse). ... If you want to hide _all_ of the implementation, better to make the base class private to your factory as well, the virtual method protected, and expose the API as an interface. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Some of the chapters of my new book
    ... > something else that lets me do programming ... doing is OOP. ... And tell me about inheritence, overloading, virtual methods, abstract ... The benefit of dynamic methods is that they can be called ...
    (alt.lang.asm)
  • Re: desgin tables into objects or vice versa?
    ... > to design a class tree according to it? ... virtual methods are probably good. ... If the processing is the same apart from some extra fields the probably best ... different and inheritance and polymorphism would be good. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Inheritance question
    ... I guess I did need to be a lot clearer on intent. ... I am trying to learn inheritance so i dont really know the questions to ask. ... public BaseClass() ... virtual methods to deal with per-type behaviors. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Pointer to virtual object on stack
    ... It is a very simple case of inheritance and dynamic binding. ... derived from clas A, which means that B 'isa' A, anytime an instance of ... > virtual methods then B's virtual methods. ...
    (comp.lang.cpp)