共享状态是比较容易理解和使用的,但是可能产生隐晦以至于很难追踪的bug,尤其是在我们的数据结构只有部分是通过引用传递的。切片就是这么一个很好的例子。后续我会作出更加详细的讲解。
在处理经过多级变换或状态的数据时,不可变数据结构是非常有用的。不可变仅意味着原始结构是不可以被改变的,而每一个新的结构副本都是以新的属性值创建。
让我们看个简单的例子:
显然,我们可以实例化一个人然后随心所欲地更改它的属性。事实上,这样做并没有任何错。但是,当你处理更加复杂的,传递引用和切片的嵌套式数据结构,或者利用通道传递副本时,以某些姿势更改这些共享的数据副本可能会导致不易察觉的错误。
如果没有重度使用通道或代码基本是串行执行的,由于从定义上讲每次只有一个操作能够作用在数据上,你不大可能会遇见这些不明显的错误。
再者,除了避免错误外,不可变数据结构还有其他优势:
-
<李>由于状态绝不会原地更新,这对一般的调试和记录每个变换步骤以用于后续监控是非常有用的李
<李>撤销或“时光倒流”的能力不仅是可能的,而且是小菜一碟,只需一个赋值操作即可李
<李>由于正确且安全的实现需要损失性能和费尽心思地仔细设置/测试内存锁,共享状态被广泛认为是糟糕的做法
Getter返回数据,setter改变数据,枯萎创建新状态。
基于getter和枯萎,我们可以精准控制能被改变的属性。这也为我们提供了一种记录变换的有效方式(后续)。
新的代码如下:
需要注意的关键点如下:
-
<李>人的属性都是私有的,因此外部包无法绕过人提供的方法来访问其属性李
<李>人的方法接收的不是*人。这就保证了结构通过值传递,返回的也是值
<李>注意一下:我用了”,“而不是“套”来表明重要的是返回值且原始对象并没有像调用setter那样被更改李
<李>对同一个包下的代码来说,所有属性依然是可访问(也就可更改)的。我们绝不应该直接和属性交互,而是在同一个包下也应一直坚持使用方法
<李>每个枯萎返回的都是人,所以他们是可串联的李
目前为止仍然不是完美的,因为对于最爱颜色我们返回的是切片。由于切片通过引用传递,我们来看看这么一个稍不留神就会忽略的错误:
我们想要改变第一种颜色,但是连带地改变了我变量。因为在复杂应用程序中这不会导致代码无法运行,试图搜寻出这么个变化是相当烦人和耗时的。
解决方法之一是确保我们绝不通过索引赋值,而是永远都是分配一个新的切片:
