被保护的成员/田真的那么糟吗？ [英] Are protected members/fields really that bad?

问题描述

现在如果你读了C＃中的MSDN的命名约定，你会发现，它指出的属性总是优先于公共和受保护的领域。我甚至已经告诉一些人，你不应该使用公共或受保护的领域。现在，我会同意我还没有找到一个理由，我需要有一个公共领域，但保护领域真的那么糟糕吗？

我可以看到它，如果你需要以确保获取/设置但是值了很多，好像在我看来，只是额外的开销的时候一定验证检查执行。我的意思是可以说我有一类GameItem与baseName的，prefixName和suffixName领域。为什么要参加两个创建属性（ C＃）或访问方法，并会出现我的表现打的开销（如果我这样做的每一个领域中的应用，我相信，它会在少一点特别增加了在某些语言，如 PHP 或性能有一定的应用就像是游戏的关键）？

解决方案

是受保护的成员/田真的那么糟糕吗？

否。他们是方式，方法更糟糕。

当一个成员比更容易获得私人，你正在担保有关成员将如何表现其他类。由于现场是完全失控，把它在野外打开你的类和继承或类较高风险的错误交互类。有没有办法知道什么时候一个场的变化，没办法控制谁或什么样的变化吧。

如果现在或者在未来的某个时刻，你的任何代码永远依赖于现场一定的价值，你现在必须添加有效性检查，并后备逻辑的情况下，它不是预期值 - 每次你使用它的地方。这时候，你可能已经只是做它一个该死的属性，而不是无用功，数额巨大;）

的

最佳的方式与共享信息派生类是在只读属性

 受保护对象myProperty的{搞定; } 
  

如果你绝对的有无的使它读/写，不要吨。如果你真的，真的要使其读写，重新考虑你的设计。如果您仍然需要它是可读写，道歉，你的同事，不要再这样做：）

很多开发商认为 - 并会告诉你 - 这是过于严格。而且这是真的，你可以的按的获得只是罚款而不被这种严格的。但采用这种方法会帮助你从刚开通过为显着功能强大的软件去。你会花更少的时间修复bug

和关于对性能有任何疑虑 - 不。我保证你永远不会在你的整个职业生涯中，编写代码如此之快，瓶颈是调用栈本身。

Now if you read the naming conventions in the MSDN for C# you will notice that it states that properties are always preferred over public and protected fields. I have even been told by some people that you should never use public or protected fields. Now I will agree I have yet to find a reason in which I need to have a public field but are protected fields really that bad?

I can see it if you need to make sure that certain validation checks are performed when getting/setting the value however a lot of the time it seems like just extra overhead in my opinion. I mean lets say I have a class GameItem with fields for baseName, prefixName, and suffixName. Why should I take the overhead of both creating the properties (C#) or accessor methods and the performance hit I would occur (if I do this for every single field in an application, I am sure that it would adds up at less a little especially in certain languages like PHP or certain applications with performance is critical like games)?

解决方案

Are protected members/fields really that bad?

No. They are way, way worse.

As soon as a member is more accessible than private, you are making guarantees to other classes about how that member will behave. Since a field is totally uncontrolled, putting it "out in the wild" opens your class and classes that inherit from or interact with your class to higher bug risk. There is no way to know when a field changes, no way to control who or what changes it.

If now, or at some point in the future, any of your code ever depends on a field some certain value, you now have to add validity checks and fallback logic in case it's not the expected value - every place you use it. That's a huge amount of wasted effort when you could've just made it a damn property instead ;)

The best way to share information with deriving classes is the read-only property:

protected object MyProperty { get; }

If you absolutely have to make it read/write, don't. If you really, really have to make it read-write, rethink your design. If you still need it to be read-write, apologize to your colleagues and don't do it again :)

A lot of developers believe - and will tell you - that this is overly strict. And it's true that you can get by just fine without being this strict. But taking this approach will help you go from just getting by to remarkably robust software. You'll spend far less time fixing bugs.

And regarding any concerns about performance - don't. I guarantee you will never, in your entire career, write code so fast that the bottleneck is the call stack itself.

这篇关于被保护的成员/田真的那么糟吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！