如何阻止新修改器?
我在基类中有一个属性,我不想以任何原因覆盖该属性。它为该类分配一个 ID,以便与我创建的 ThreadQueue 一起使用。我认为任何人都没有理由推翻它。我想知道如何阻止任何人在不更改其修饰符的情况下尝试覆盖它。
private int _threadHostID = 0;
public int ThreadHostID
{
get
{
if (_threadHostID == 0)
{
_threadHostID = ThreadQueue.RequestHostID();
}
return _threadHostID;
}
}
编辑:完全忘记了语言:C#。
Edit2:它不是虚拟的或覆盖其他任何东西,所以请不要密封
。
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
.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
我认为你不应该担心这个。如果您不将其写为虚拟,那么您就明确表示它不打算被覆盖,事实上,如果您覆盖它(没有“新”修饰符),您将收到警告:
如果您有这种恐惧,您 将收到警告。应该担心您在非密封类中编写的任何方法。因此,您的工作只是确保您的类的设计是一致且清晰的,如果有人想继承它,那么不应该愚蠢地重新定义非虚拟属性/方法。你无法完全保护自己免受他人愚蠢的影响:)。
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):
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 :).
据我所知,你显然不能在财产层面上做到这一点。但是,如果您密封该类:
then ...
将会在类定义上引发错误,因此使用
new
甚至不起作用。这不是您问题的精确解决方案,但它确实可以防止其他人扩展或干扰您的 API。
As far as I can tell, you apparently can't do that on a property level. However, if you seal the class:
then ...
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.
如果有人确实投入了“新”实施,这真的很重要吗?我假设您将始终在使用该属性的任何代码中引用基类,因为这是它的声明位置,并且由于它不是覆盖或虚拟的,所以无论如何都不会多态地调用“新”实现。
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.
首先:“覆盖”是指虚拟覆盖。您正在谈论创建隐藏方法,而不是覆盖方法。
它。你可以自由地想要它,但你必须学会忍受没有得到你想要的东西的失望。
那么就不会有问题了,不是吗?如果没有人可能想要隐藏它,那么他们就不会隐藏它。你基本上是在说“我有一个对任何人都没有价值的物品;我如何防止有人偷它?”好吧,如果它没有价值,那么没有人会想偷它,那么为什么你要花钱买一个保险箱来保护本来就没有人想偷的东西呢?
如果有人没有理由隐藏或覆盖你的方法,那么没有人会这样做。如果某人有理由隐藏或覆盖您的方法,那么您有什么资格告诉他们不要这样做呢?您正在提供一个基类;您是派生类作者的仆人,而不是他们的主人。
现在,有时成为一个好仆人意味着建造一些能够防止滥用、坚固且价格合理的东西。例如,我鼓励人们建立密封课程。设计满足继承者实际需求的安全、健壮、可继承的类是昂贵且困难的。
但是,如果您要创建一个专为继承而设计的健壮的未密封基类,那么为什么要尝试阻止派生类作者隐藏(如果他们有理由这样做的话)?它不可能伤害基类。它唯一可能伤害的人是派生类的用户,而这些人是派生类作者的问题,而不是您的问题。
First off: "Overriding" refers to virtual overriding. You are talking about creating hiding methods, not overriding methods.
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.
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.
没有办法阻止成员隐藏。如果您不将其设为虚拟或抽象,则派生类无论如何都无法正确覆盖它,隐藏不是多态的。
如果派生类使用 new 运算符隐藏它,那么它们就会给自己带来问题,因为任何决定使用基类引用的代码都不会触及派生成员。因此基本上,所有利用类型层次结构的“基类”的代码都将绕过所有成员隐藏。
sealed
关键字仅在派生类型重写基类型并且不希望它被进一步重写时才起作用...但不确定它如何与new
运算符一起使用。最有可能的是,成员隐藏仍然被允许,但仍然会遇到相同的直接类型问题。您的任务是通过不使方法虚拟或抽象来完成的,如果一个人想要隐藏成员,那么他们要对任何破坏负责,因为他们决定滥用设计。
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 thenew
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.