10

就代码行而言，对于“获取”的大小是否有任何指导方针或普遍共识？我有一个成员的 Get 方法，这里的代码很容易增长到 30 行。我不确定应该在什么时候将其提取到方法中。但是我只会将其称为 GetMyString 并将值分配给另一个成员并在构造函数中调用它。

这样做值得吗？

这对SO来说太主观了吗？

4

5 回答 5

15

dcastro 的回答很好，但可以使用一些扩展：

  • 不需要很长时间才能返回

这不是量化的；让我们量化一下。一个属性不应该比获取一个字段花费的时间长十倍。

  • 它不连接到外部资源（数据库、服务等）

这些速度很慢，因此通常属于第一条规则，但还有第二个方面：失败应该是罕见的或不可能的。属性 getter 不应该抛出异常。

  • 它没有任何副作用

我会澄清可观察到的副作用。属性 getter 通常具有副作用，即他们计算一次属性并将其缓存以供以后使用，但这不是可观察到的副作用。

让属性产生可观察到的副作用不仅在哲学上是不好的，而且还会扰乱您的调试体验。请记住，默认情况下，当您在调试器中查看对象时，调试器会自动调用其属性 getter 并显示结果。如果这样做很慢，那么这会减慢调试速度。如果这样做可能会失败，那么您的调试体验就会充满失败消息。如果这样做有副作用，那么调试你的程序会改变程序的工作方式，这可能会使发现错误变得非常困难。您当然可以关闭自动属性评估，但最好首先设计好的属性。

于 2013-11-25T15:51:19.167 回答
12

这并不是真正重要的大小（没有双关语）。只要将您的逻辑放在吸气剂中就可以了

  • 不需要很长时间才能返回
  • 它不连接到外部资源（数据库、服务等）
  • 它没有任何副作用

这些只是正确使用物业的一些准则。

编辑

上述指导方针有一个共同点：属性访问器的行为应该像数据访问一样，因为这是用户所期望的。

来自 Bill Wagner 的《Effective C#》一书：

属性是可以从调用代码中查看的方法，例如数据。这使您的用户产生了一些期望。他们将看到属性访问，就好像它是数据访问一样。毕竟，这就是它的样子。您的财产访问者应该不辜负这些期望。获取访问器不应有可观察到的副作用。设置访问器确实会修改状态，用户应该能够看到这些更改。

属性访问器对您的用户也有性能期望。属性访问看起来像数据字段访问。它不应具有与简单数据访问显着不同的性能特征。

属性访问器不应执行冗长的计算，或进行跨应用程序调用（例如执行数据库查询），或执行与用户对属性访问器的期望不一致的其他冗长操作。

阿尔贝托的奖金：http: //msdn.microsoft.com/en-us/library/vstudio/ms229054%28v=vs.100%29.aspx

于 2013-11-25T14:26:11.507 回答
3

这不一定是坏事，但如果是我的话，我会很紧张，我会试着以某种方式打破它。getter 是一种方法，因此在我看来，简单地将整个事物拉入 30+ 行方法将是浪费时间。我会试着把它切碎。例如，如果它是带有一些检查的循环，则将检查提取为方法等。

于 2013-11-25T14:32:28.490 回答
2

将一大堆行推入 Get 方法是一种常见的不良做法。我在 Visual Studio 中安装了一些名为 CodeMaid 的东西。它有一个叫做 CodeMaid Spade 的东西，它对每种方法进行评分并给你一个分数。分数越高，您的方法越差。它也可以用于属性。我建议你试一试，它也有助于格式化、缩进和一堆其他的好习惯

于 2013-11-25T14:24:49.890 回答
1

作为一般准则，方法的行数不应超过一个屏幕的容量。如果你必须滚动，它太大了。将其拆分为更小的方法。

于 2013-11-25T14:26:28.833 回答