何时在Scala中使用mutable vs immutable类
|
关于不可变状态的优势有很多,但是
Scala中常见的情况是哪里可以选择可变类？ (这是使用可变类的“经典”OOP设计背景的人的Scala新手问题.)
对于像3维Point类的小事,我得到了不变性的优点.但是,像Motor Class这样的东西,暴露了各种控制变量和/或传感器读数呢？一个经验丰富的Scala开发人员通常会写这样一个类是不可变的吗？在这种情况下,’speed’会在内部表示为’val’而不是’var’,而’setSpeed’方法返回一个新的类的实例？同样地,传感器描述电机内部状态的每一次新读数是否会引起Motor的一个新实例被实例化？ 在Java或C#中使用类来封装可变状态的“旧方法”似乎非常适合Motor的例子.所以我很想知道如果一旦你获得使用不变状态范例的经验,你甚至会设计一个像马达这样的课程是不可改变的. 解决方法
我将使用不同的经典OO建模示例：银行账户.
这些在几乎每个OO课程中都被使用在地球上,你通常最终的设计就是这样： class Account(var balance: BigDecimal) {
def transfer(amount: BigDecimal,to: Account): Unit = {
balance -= amount
to.balance += amount
}
}
IOW：平衡是数据,转移是一个操作. (还要注意,传输是一个涉及多个可变对象的复杂操作,但是应该是原子的,而不是复杂的…所以你需要锁定等等) 但是,这是错误的.这不是银行系统的实际设计.事实上,这不是实际的现实世界(实体)银行如何工作.实际的实体银行和实际银行系统的工作原理如下： class Account(implicit transactionLog: TransactionLog) {
def balance = transactionLog.reduceLeft(_ + _)
}
class TransactionSlip(from: Account,to: Account,amount: BigDecimal)
IOW：平衡是一个操作,传输是数据.请注意,这里的一切都是不可变的.余额只是交易日志的左侧折叠. 还要注意,我们甚至没有以纯粹的功能,不可变的设计作为一个明确的设计目标.我们只是想正确地建立银行体系,最终以纯粹的功能,不可变的设计巧合. (嗯,实际上并不是巧合,现实世界的银行有这样的一个原因,它与编程有着相同的好处：可变状态和副作用使系统复杂和混乱…而在银行业钱消失了.) 这里的观点是,完全相同的问题可以以非常不同的方式建模,并且根据模型,您可能会采取一些简单的做法,使其完全不可变或非常困难. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |