CODEWITHSUNDEEP
c#propertiesoverridingnew-operator
scott.smart
scott.smart

Reputation: 538

How do I block the new modifier?

I have a property in a base class that I don't want overridden for any reason. It assigns an ID to the class for use with a ThreadQueue I created. I see no reason whatsoever for anyone to override it. I was wondering how I can block anyone from attempting to override it short of them changing its modifier.

private int _threadHostID = 0;
    public int ThreadHostID
    {
        get
        {
            if (_threadHostID == 0)
            {
                _threadHostID = ThreadQueue.RequestHostID();
            }
            return _threadHostID;
        }
    }

Edit: totally forgot the language: C#.

Edit2: It is not virtual or overriding anything else so please no sealed.

Upvotes: 4

Views: 320

Answers (5)

Eric Lippert
Eric Lippert

Reputation: 660297

First off: "Overriding" refers to virtual overriding. You are talking about creating hiding methods, not overriding methods.

I have a property in a base class that I don't want hidden

You are free to want that, but you are going to have to learn to live with the disappointment of not getting what you want.

I see no reason whatsoever for anyone to hide it.

Then there won't be a problem, will there? If no one could possible want to hide it, then they won't hide it. You're basically saying "I have an object of no value to anyone; how do I keep someone from stealing it?" Well, if it is of no value, then no one is going to want to steal it, so why would you spend money on a safe to protect something that no one wants to steal in the first place?

If there is no reason for someone to hide or override your method then no one will. If there is a reason for someone to hide or override your method, then who are you to tell them not to? You are providing a base class; you are the servant of the derived class author, not their master.

Now, sometimes being a good servant means building something that resists misuse, is robust, and reasonably priced. I encourage people to build sealed classes, for example. Designing secure, robust, inheritable classes that meet the real needs of inheritors is expensive and difficult.

But if you are going to create a robust unsealed base class designed for inheritance, why try to stop the derived class author from hiding, if they have a reason to do so? It cannot possibly hurt the base class. The only people it could hurt are the users of the derived class, and those people are the derived class author's problem, not yours.

Upvotes: 9

Adam Houldsworth
Adam Houldsworth

Reputation: 64517

There is no way to stop member hiding. If you don't make it virtual or abstract, then a derived class cannot override it properly anyway, hiding isn't polymorphic.

If a derived class hides it using the new operator, then they are opening up problems for themselves as any code that decides to use a reference to the base class will not touch the derived member. So basically, all code that utilises the "base class"-ness of the type hierarchy will bypass all member hiding anyway.

The sealed keyword only works if a derived type overrides a base type and doesn't want it to be overridden further... not sure how it plays with the new operator though. Most likely the member hiding will still be allowed, but will still have the same direct-type problem.

Your task is done by not making the method virtual or abstract, if a person wants to hide members then they are responsible for anything that breaks because they decided to abuse the design.

Upvotes: 8

Trevor Pilley
Trevor Pilley

Reputation: 16413

Does it actually matter if someone does put a 'new' implementation in? I'm assuming you will always be referring to the base class in any code using that property since that is where it is declared and since it's not override or virtual it won't polymorphically call up to a 'new' implementation anyway.

Upvotes: 0

Riccardo Tramma
Riccardo Tramma

Reputation: 593

I think you should not worry about this. If you don't write it as virtual then you are making clear that it is not intended to be overridden and in fact you will receive a warning if you will override it (without the "new" modifier):

Warning: [...] hides inherited member [...].
Use the new keyword if hiding was intended

If you have this fear you should worry about any method that you write in a non-sealed class. So the job for you is just make sure that the design of your class is consistent and clear and if someone wants to inherit it then should be not dumb to just go and redefine non-virtual properties/methods. You cannot completely shield yourself from others stupidity :).

Upvotes: 2

3Dave
3Dave

Reputation: 29051

As far as I can tell, you apparently can't do that on a property level. However, if you seal the class:

public class Base
{
  public int ID { get; set; } 
}

public sealed class Child : Base
{
  /// blah
}

then ...

public class Grandchild : Child
{ 
  public int ID { get; set; } 
}

will throw an error on the class definition, so using new doesn't even come into play.

Not an exact solution to your problem, but it does keep others from extending or interfering with your API.

Upvotes: 0

Related Questions