It is not possible, period. They tried to give a solution, but it does not exist. Once the field (and not attribute, this term is wrong, but it is worse because this is not even a field is a property) declared as public it is impossible to decrease its visibility in the inherited classes. Classes that inherit must have all the public API of the inherited class, nothing less, what you’re trying to do is eliminate what already existed in the class, so break the inheritance, so if you want to do this it’s because should not use inheritance there, plain as that.
The question does not help much because it has an abstract example and model correctly in abstract example never works, in a real case we could see some other solution or identify what is the real problem.
But what is clear is that if a field should be public in the more general class and have a more restricted access in the more specific inheritance class is the wrong mechanism. Can’t put protected
because besides changing the desired original visibility still doesn’t make it private afterwards. And you can’t replace the property with a new one because it’s not respecting polymorphism, although this could be a solution in some specific case where you don’t want the same inheritance, probably you don’t want that (almost all use of the modifier new
in a method is wrong, it was created for quite extraordinary situations), only with the concrete case we could state whether the new
serves, but reinforcement that almost never serves.
In some scenario perhaps it would be the case to create another field or property that is private leaving the one that is already public aside, but also think that in this case is using inheritance mistakenly.
A possible coarse gambit is to make the method in the daughter class throw a NotSupportedException
and force it to do otherwise, but it’s obviously wrong. I’m not saying you should never do something wrong, but you need to justify it well, you can’t do it because it’s easier or because you can’t do it any other way. Today’s easy is tomorrow’s hard.
Object-oriented programming is about modeling correctly, it only has advantage if it respects how the actual model is, if inventing crazy things to type less code and associate things that should not be associated is bringing more problem to your code not improving.