受保护的成员/字段真的那么糟糕吗?

2024-01-14

现在,如果您阅读 MSDN 中 C# 的命名约定,您会注意到它指出属性始终优先于公共字段和受保护字段。有些人甚至告诉我,你永远不应该使用公共或受保护的领域。现在我同意我还没有找到需要拥有公共领域的理由,但受保护的领域真的那么糟糕吗?

如果您需要确保在获取/设置值时执行某些验证检查,我可以看到它,但在我看来,很多时候这似乎只是额外的开销。我的意思是,假设我有一个 GameItem 类,其中包含 baseName、prefixName 和 suffixName 字段。为什么我应该承担创建属性的开销(C#)或访问器方法以及我会发生的性能影响(如果我对应用程序中的每个字段都这样做,我确信它会增加一点点,特别是在某些语言中,例如PHP或者某些性能至关重要的应用程序(例如游戏)?


受保护的成员/字段真的那么糟糕吗?

不,他们的情况要糟糕得多。

一旦会员比private,您正在向其他类保证该成员的行为方式。由于字段完全不受控制,因此将其“放在野外”会使您的类以及从您的类继承或与您的类交互的类面临更高的错误风险。无法知道字段何时发生变化,也无法控制谁或什么改变了它。

如果现在或将来的某个时候,您的任何代码曾经依赖于某个字段的某个特定值,那么您现在必须添加有效性检查和回退逻辑,以防它不是预期值 - 您使用它的每个地方。当你可以把它变成一个该死的财产时,这是浪费大量的精力;)

The best与派生类共享信息的方法是只读属性:

protected object MyProperty { get; }

如果你绝对have要使其读/写,请不要。如果您确实必须使其可读,请重新考虑您的设计。如果您仍然需要它是可读写的,请向您的同事道歉,并且不要再这样做了:)

许多开发人员相信(并且会告诉您)这过于严格。确实,你可以get by不用这么严格就好了。但采用这种方法将帮助您从勉强过得去的软件变成非常强大的软件。您将花费更少的时间来修复错误。

至于对性能的任何担忧——不要担心。我保证,在你的整个职业生涯中,你永远不会写代码太快,以至于瓶颈是调用堆栈本身。

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

受保护的成员/字段真的那么糟糕吗? 的相关文章

随机推荐