How to block a new modifier?

Question

I have a property in the base class that I do not want to override for any reason. It assigns an identifier to the class for use with the created ThreadQueue. I see no reason for anyone to redefine it. I was wondering how I can block someone from trying to override it without changing its modifier.

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

Edit: completely forgot the language: C #.

Edit2: it is not virtual or does not cancel anything else, so please do not sealed .

Answer 1

Unable to stop hiding an item. If you do not make it virtual or abstract, then the derived class cannot override it properly; hiding is not polymorphic.

If a derived class hides it using the new operator, then they open up problems for themselves, since any code that decides to use a reference to the base class does not affect the derived member. Thus, in any case, all code that uses the "base class" for the type hierarchy will still bypass all members.

The sealed only works if the derived type overrides the base type and does not want it to be redefined further ... not sure how it works with the new operator. Most likely, hiding the element will still be allowed, but it will still have the same direct type problem.

Your task is not to make the method virtual or abstract, if a person wants to hide the participants, then they are responsible for everything that breaks down, because they decided to abuse the design.

Answer 2

First: "Override" refers to virtual override. You are talking about creating hide methods, not about overriding methods.

I have a property in the base class that I do not want to hide

You may want this, but you will have to learn to live with the disappointment that you are not getting what you want.

I see no reason for anyone to hide it.

Then there will be no problems, right? If no one can hide it, they will not hide it. You basically say: "I have an object that no one needs, how to make someone steal it?" Well, if that doesn't matter, then no one wants to steal it, so why are you spending money on a safe to protect what nobody wants to steal in the first place?

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

Now, sometimes being a good servant means creating something that resists misuse, is reliable and reasonably priced. For example, I urge people to build private classes. Designing safe, reliable, inherited classes that meet the real needs of the heirs is expensive and complicated.

But if you are going to create a reliable unsealed base class for inheritance, why try to stop the created author of the derived class if they have a reason to do so? This cannot damage the base class. The only people this can hurt are users of the derived class, and these people are the problem of the author of the derived class, not yours.

Answer 3

I think you should not worry about this. If you do not write it as virtual, you make it clear that it is not intended to be overridden, and in fact you will receive a warning if you redefine 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-printable class. Thus, the work for you is simply to make sure that the design of your class is consistent and understandable, and if someone wants to inherit it, then it should not be foolish to simply pass and redefine non-virtual properties / methods. You cannot completely protect yourself from other nonsense :).

Answer 4

As far as I can tell, you apparently cannot do this at the 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; } } 

throws an error in the definition of the class, so using new does not even come into play.

Not an exact solution to your problem, but it does not allow others to extend or interfere with your API.

Answer 5

Does it really matter if someone really introduces a "new" implementation? I assume that you will always refer to the base class in any code using this property, since this is where it is declared, and since it does not override or not virtual, it will still not polymorphically move to the "new" implementation.