在同一单元的类方法中使用属性而不是字段是一种不好的做法？答案

【问题标题】：Using properties instead of fields in class methods of the same unit is a bad practice?在同一单元的类方法中使用属性而不是字段是一种不好的做法？
【发布时间】：2011-11-26 21:01:36
【问题描述】：

我已经为给定的类声明了一个私有字段和一个公共属性。

我可以从其他单位通过提供访问权限的公共属性访问该字段。

但在声明此类的同一单元内，我可以选择直接或通过属性访问该字段。

建议的最佳做法是什么：直接读取/写入字段或通过提供读取和写入访问权限的属性？

【问题讨论】：

一般来说，如果你在类之外（有字段和属性的那个），只使用属性会更有意义。
最新版本的Delphi允许将字段声明为strict private，这将禁止在类外使用该字段。

标签： delphi

【解决方案1】：

与David's taste 相反，我总是使用私有/受保护字段，但仅在同一类中（私有时）或派生类中（受保护时）。奇怪的是，原因对我来说也是可读性：

现在，FCount 读取为 Count，
使用私有字段表明我正在研究内部，
而在我使用该属性的零星情况下，很明显我需要触发它背后的setter或getter。

这里的关键是保持一致。选择一个，并坚持下去。没有对错之分。

由于 Jerry 的评论而更新：

我关于保持一致的观点是为每个人的利益提供一般性建议。让自己习惯一种默认语法，你的代码将在你的余生中清晰可见（我的意思是对你而言）。

当然，当你选择使用私有字段时，会有一些偶然的情况你必须使用属性来代替。但这反之亦然：如果您选择使用属性，那么在某些情况下您必须使用私有字段。我只是说，当你坚持一个系统时，异常会更清楚地看起来像异常。

【讨论】：

我不同意最后一行“选择一个并坚持下去” - 正如这里的其他 cmets 所提到的，这取决于您打算做什么。如果你的属性后面有一个 getter/setter 方法，那么你需要小心你如何使用它。假设您有 property Caption: String read FCaption write SetCaption 和 SetCaption 执行一系列这样和那样的操作来验证值，但您需要做的就是显式分配该字段而不进行检查，当然您需要设置 FCaption:= 'My Value' 而不是 @ 987654325@.
我选择了这个答案，因为经过一些调查，我注意到这是大多数 VCL/RTL 单元使用的做法
@FabioVitale 但是不要忘记看看一般的 OOP 原则，比如 SOLID，在设计你的类时总是值得了解的。

【解决方案2】：

嗯，这可能很大程度上取决于个人喜好。

我自己总是选择该属性，即使在声明该属性的类的内部编码时也是如此。例如，在我看来，Count 而不是 FCount 读起来更好。

另一种观点是，如果您将财产暴露给公众，并且它足以供公共消费，那么它应该适合私人消费。

另一种看法是，如果您尽可能选择使用最公开可用的界面，那么当您使用私有内容时会更加明显。所以，如果你发现因为没有 Count 而需要写 FCount，那么你有一个温柔的提醒，这是你正在使用的私有名称。

所以，正如我所说，没有明确的答案，只是我个人的意见和偏好。

【讨论】：

像“总是选择该属性”这样的语句的唯一问题是，当该属性有一个具有您可能不想要的副作用（例如，执行计算或设置其他属性）的设置器时发生在内部。 :)
@ken 好点。我隐含地假设该属性直接映射到该字段。我认为问题中暗示了这一点，但没有明确的地方。
@David 即使是这样，类也会发展。
对我来说，“选择属性”的例外是构造函数、析构函数和类似的方法，例如 Assign 或 CreateCopy。我已经看到了许多通过 setter 和 getter 并导致 av 或泄漏的分配方法，因为并非所有 setter 都具有相同的行为，即执行分配检查并释放当前实例。在“构造”方法中，我选择了田野，在极少数情况下我不这样做（不要问这是一个长篇大论），我会在 cmets 中解释原因。
我正要回答肯提到的完全相同的观点。

【解决方案3】：

如果你不使用任何 getter 和 setter，那只是口味问题。使用属性或字段将生成完全相同的代码。

如果您确实使用 getter 和 setter，如果您不想使用 getter/setter 代码（例如在 constructor 中），则可以显式使用私有字段。

如果您的 getter 和 setter 是 virtual，即使默认实现只是一个赋值，您也必须检查 SOLID principles，并确保您至少遵循 Liskov 替换和打开/关闭原则。

【讨论】：

我刚刚完成了一篇关于SOLID principles 的博客文章。毫无疑问，我不是一个非常优雅的编码器（我承认我有时会违反这些原则，即使在我的开源库中也是如此） - 但我有兴趣阅读您的 cmets，并让这些原则在 Delphi 社区中得到更好的了解。 Delphi 有时被同化为 RAD 产品——这是一个营销标签——但恕我直言，Delphi 不仅仅是 RAD。使用 Delphi，您可以进行非常严肃和干净的编程。
嗨。链接断开:)
该博客文章已包含在我们的框架文档中，并已完成。 A working link to the article.