Sealed class is a class which cannot be inherited, so why is it allowed to write protected members in sealed class
-
It doesn't make sense, but it is doesn't violate anything and is not considered to ab an error. For example, you may also have public constructor on abstract class which is the same as having protected constructor. – Yeldar Kurmangaliyev Aug 25 '18 at 19:51
-
@YeldarKurmangaliyev ok, I just was thinking that it could make some sense – Levon Petrosyan Aug 25 '18 at 19:57
-
It is a good practice to seal. And a good practice to not make life difficult when you have to give up on a good practice some rainy day. – Hans Passant Aug 25 '18 at 20:26
2 Answers
Because Microsoft decided it to not be an error.
I agree that it makes no sense to declare a protected
member in a sealed
class. Using protected
on a member in a sealed
class is the same as having a private
member
Therefore you will get the following compiler warning: https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/7x8ekes3(v=vs.90)
Sealed classes can still have inherited Protected members, so to me it makes sense. Maybe the designers did this to allow inheritance without needing to make a special compiler case.
public class Foo
{
protected virtual string Name { get; set; } = "Foo";
}
public sealed class Bar : Foo
{
protected override string Name { get; set; } = "Bar";
}
Update: From Eric Lippert in 2009:
The language design notes document that the decision to make introducing a virtual method into a sealed type an error was made on the 18th of October, 1999, but does not give any justification for the decision. I can find nowhere in the notes that justifies why introducing a new protected member ought to be legal. My best guess: this was probably simply an oversight in the first version, and then it became a breaking change to ever fix it. – Eric Lippert

- 3,148
- 18
- 40
-
yes, for sure it makes sense when you are overriding, but if you are declaring a new protected member then its not normal I think – Levon Petrosyan Aug 25 '18 at 19:04
-
You could also make the member Name private in class Bar which is basicly the point of this discussion: Why does Microsoft not force me to make Name private in class Bar as I won't be able to use it outside of the class anyways. – Dominik Aug 25 '18 at 19:05
-
@Dominik there are some cases where you do want Protected access on subclasses though, and I don't think the compiler can infer use cases. – Parrish Husband Aug 25 '18 at 19:06
-
@ParrishHusband I don't get what you mean. Making Name protected in class Foo is OK and I also understand why. Making Name protected in class Bar which is sealed is the same as making it private. The compiler doesn't have to infer use cases because there are no use cases. You are not able to use the property Name of class Bar outside of Bar because it's sealed. – Dominik Aug 25 '18 at 19:08
-
@Dominik you cannot change access modifiers when overriding a base class member. – Parrish Husband Aug 25 '18 at 19:09
-
2@ParrishHusband Yea ofc you can't. But I mean "use case based". Sure the compiler must let you declare protected on a not sealed class. This question isn't about overriding a protected property. The access modifier will also be "inherited" and therefore the compiler forces you to use the same as in the base class. – Dominik Aug 25 '18 at 19:10
-
@Dominik The point of my post was to suggest inherited protected members was the underlying reason they made it allowable on sealed classes. – Parrish Husband Aug 25 '18 at 19:17
-
2`-(-5)` is the same as `5`. It does not make much sense but is logical and perfectly legal. `protected` in a `sealed class` is the same as `private`. It does not make much sense but is logical and perfectly legal. – Olivier Jacot-Descombes Aug 25 '18 at 19:49