0

让我们假设[数据库触发器是邪恶的]。1

这是否意味着在 java 或 C# 对象上设置属性时的副作用也是邪恶的？

在我看来，所有相同的问题都存在。

4

6 回答 6

3

在这里与谷物背道而驰...

属性不应触发副作用。这就是 Method 的用途。

通过让属性导致副作用，您最终会陷入代码基本上被隐藏的情况。人们很少期望物业启动某些过程或导致其他事情发生翻转。如果这必须记录在案，那么它并不明显并且会被忽略。

但是，我们确实希望在调用方法时会发生一些事情。

以@astander 为例，他说更改“价格”的行为应该导致不同的属性“成本”发生变化。但是，如果我们稍后添加一个名为“折扣”的新属性会怎样？Price 和 Amount 属性的代码必须更改。这不是很容易发现。

但是，如果成本自己计算......那么一切都会变得更好。

于 2010-12-01T06:20:09.073 回答
0

不一定，不。如果您有PriceorAmount属性，并且您更改了它，那么似乎Cost应该相应地更改？

或者你对这篇文章有什么不同的想法？

于 2010-12-01T05:49:32.717 回答
0

不会。许多属性可以而且应该触发副作用。

例如：想象两个视觉元素，其中一个孩子包含在一个父母中。设置 parent.Visible = false 也应该设置 child.Visible = false。

通常这些副作用是通过事件（System.Windows.Forms 充满了 PropertyChanged 事件）或接口（例如 INotifyPropertyChanged）来显式显示的。

于 2010-12-01T06:04:16.907 回答
0

尽管属性有时很有用，但它们确实在团队环境中的日常编码中引入了一些不确定性，在这种环境中，并非每个人都必须以相同的方式解释属性的目的和适当使用。

这是出现的许多问题之一：

  • 属性设置器是否应该有不明显的副作用。
  • 他们是否应该进行潜在的密集处理？
  • 公共字段是否还有位置，或者所有字段都应该是私有的/受保护的并通过属性访问？这在使用反射时会产生影响：知道您永远不必搜索类型的 Fields 集合会很方便。

最终，我认为只要记录了任何副作用或可能代价高昂的操作，上述两点并不重要，因为这同样适用于方法。

您可以安全地做出的假设越多，代码复杂性就越低，但这种收益在某种程度上被额外的通信开销所抵消。它只在团队中的每个人都在同一页面上并且保持在同一页面上时才有效。

有时我认为属性导致的问题多于解决的问题。

于 2010-12-01T06:16:11.793 回答
0

那要看。当然有副作用，这会让用户大吃一惊，最好避免那些 IMO。

我更喜欢属性的行为与字段非常相似，因为从读者的角度来看它们看起来是一样的（无论如何在 C# 中）。如果一个属性有任何不明显的副作用，我更喜欢方法而不是属性。

于 2010-12-01T06:19:42.340 回答
0

除了上面 Chris 的评论之外，我确实同意，还有另一个方面导致触发器被认为有点曲折，那就是它们并不明显。

这使得很容易忘记，这反过来又使它们很难调试。

人们（我肯定是其中之一，而不是唯一一个）已经花费数小时尝试调试问题并从头到尾进行流程（明显结束，即数据库过程/DML查询）以了解一直以来导致问题的原因是触发器 - 因为它们本质上是后台操作。

You could also argue that proper logging of triggers should result in easy avoidance of this kind of issue but usually logging is never done in the Database layer itself hence complicating this aspect of troubleshooting a bit more.

于 2010-12-01T06:43:23.433 回答