Re: error CS0621: virtual or abstract members cannot be private
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Sun, 22 Feb 2009 17:40:05 -0800
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.
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.
> 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 also feel that combining your factory and implementation in the same class is awkward and unnecessary. 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 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 don't see anything fundamentally unworkable in what you're suggesting, but it does seem awkward and likely to lead to 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
.
- Follow-Ups:
- References:
- Prev by Date: Re: convert the byte to a unsigned char
- Next by Date: Re: setting an event to null.
- Previous by thread: Re: error CS0621: virtual or abstract members cannot be private
- Next by thread: Re: error CS0621: virtual or abstract members cannot be private
- Index(es):
Relevant Pages
|
