C业务应用程序中的不可变类

尽管乔恩确实提出了一个令人信服的理由来说明不可变对象的好处,但我会采取一种稍微不同的策略。

当您在代码中建模业务流程时,显然您想要做的是在代码中使用机制来表示关于模型的事实。例如,如果一个客户是一种人,那么您可能有一个Person基类和一个客户派生类,等等。

不变性只是这些机制中的另一个。因此,在您的业务流程中,考虑一下什么事情会发生一次,然后再也不会改变,与之形成对比的是,什么事情会随着时间的推移而改变。

例如,考虑“客户”。客户有名字。客户的名字有变化吗?当然。客户的名字一直在变化,通常是在他们结婚的时候。那么,客户应该是一个不变的类吗?大概不会。从逻辑上讲,当客户更改其名称时,您不会从旧客户中创建新客户;旧客户和新客户是同一对象,但名称属性已更改。

现在考虑“合同”。合同有变吗?不,对现有合同的修正产生了新的、不同的合同。特定合同中的日期、当事人、条款等及时冻结。契约对象可以是不可变的。

现在有趣的问题是 当一个合同提到一个客户,而客户改变了他们的名字时,该怎么办? . 正是可变对象和不可变对象之间的交互作用使这成为一个棘手的设计问题。

不可变类型比可变类型更容易解释——当您有一个实例的引用时,您知道您可以依赖它而不改变。您可以构建一种功能性的工作方式,在这种工作方式中,您希望执行的任何突变都将成为一个创建新实例的操作(就像它对字符串的操作一样),这些功能性操作可以安全地组合,而不必担心如果其中一个操作以特定方式更改对象会对另一个操作造成伤害时会发生什么情况。操作。

一旦您根据不可变值的状态做出了一个决定,您就知道该决定对于该值仍然有效,因为该值本身无法更改。

此外,不变性对于线程很有用——当您希望跨多个线程使用单个对象时,不变性可以避免数据争用等许多问题。

这些好处中有很多对业务对象很有用,但您确实需要以不同的心态处理问题。尤其是,如果您的数据库行 不是 不可变(即,您将修改行,而不是总是创建行的新“版本”),那么您需要知道,任何给定的值都可能不再代表该行的数据库状态。

一旦您打印出一张发票并将其发给客户,该发票将永远冻结。任何调整都需要在随后的发票上应用。