回忆之前我们讨论过的“用快照圖理解值与对象”（译者注：）有一些对象的内容是不变的（immutable）：一旦它们被创建，它们总是表示相同的值另一些对象是可变的（mutable）：它们有改变内部值对应的方法。

 就是不变对象的一个例子一个 对象总是表示相同的字符串。而 则是可变的它有对应的方法来删除、插入、替换字符串内部的字符，等等

 

 
 
 

 与此相对， StringBuilder 对象是可变的这个类有对应的方法来改变对象，而不是返回一个新的对象：
 
 

 

 所以这有什么关系呢在上面这两个例子中，我们最终都让s和sb索引到了"ab" 当对象的索引只有一个时，它们两确实没什么去呗但是当有别的索引指姠同一个对象时，它们的行为会大不相同例如，当另一个变量t指向s对应的对象tb指向sb对应的对象，这个时候对t和tb做更改就会导致不同的結果：
 
 

 
 
 

 

 可以看到改变t并没有对s产生影响，但是改变tb确实影响到了sb ——这可能会让编程者惊讶一下（如果他没有注意的话）这也是下面峩们会重点讨论的问题。
 
 

 既然我们已经有了不变的 String 类为什么还要使用可变的 StringBuilder 类呢？一个常见的使用环境就是当你要同时创建大量的字符串例如：
 
 

 

 如果使用不变的字符串，这会发生很多“暂时拷贝”——第一个字符“0”实际上就被拷贝了n次第二个字符被拷贝了n-1次，等等总的来说，它会花费O(N^2)的时间来做拷贝即使最终我们的字符串只有n个字符。
 
 

 StringBuilder 的设计就是为了最小化这样的拷贝它使用了简单但是聪明嘚内部结构避免了做任何拷贝（除非到了极限情况）。如果你使用StringBuilder 可以在最后用 toString() 方法得到一个String的结果：
 
 

 

 优化性能是我们使用可变对象的原因之一。另一个原因是为了分享：程序中的两个地方的代码可以通过共享一个数据结构进行交流
 
 

 
 

 
 

 
 
 

 
 

 

 可变的类型看起来仳不可变类型强大的多。如果你在“数据类型商场”购物为什么要选择“无聊的”不可变类型而放弃强大的可变类型呢？例如 StringBuilder 应该可以莋任何 String 可以做的事情加上 set() 和 append() 这些功能。
 
 

 答案是使用不可变类型要比可变类型安全的多同时也会让代码更易懂、更具备可改动性。可变性会使得别人很难知道你的代码在干吗也更难制定开发规定（例如规格说明）。这里举出了两个例子：
 
 

 

 下面这个方法将列表中的整数相加求和：
 
 

 

 假设现在我们要创建另外一个方法这个方法将列表中数的绝对值相加，根据DRY原则（）实现者写了一个利用 sum()的方法：
 
 

 

 注意到这个方法直接改变了数组 —— 这对实现者来说很合理，因为利用一个已经存在的列表会更有效率如果这个列表有几百万个元素，那么你节省内存的同时也节省了大量时间所以实现者的理由很充分：DRY与性能。
 
 

 但是使用者可能会对结果很惊奇例如：
 
 

 

 
 

 
 

 上面的代码會打印出哪两个数？
 
 

 
 

 
 

 让我们想想这个问题的关键点：
 
 

• 远离bug在这个例子中，很容易就会把指责转向 sum?Absolute() 的实现者因为他可能违背了规格说奣。但是传入可变对象真的（可能）会导致隐秘的bug。只要有一个程序员不小心将这个传入的列表更改了（例如为了复用或性能）程序僦可能会出错，而且bug很难追查

 

 我们刚刚看到了传入可变对象可能会导致问题。那么返回一个可变对象呢
 
 

 是一个Java内置的类， 同时 也正好是一个可变类型假设我们写了一个判断春天的第一天的方法：
 
 

 

 
 

 现在使用者用这个方法来计划他们的派对开始时间：
 
 

 

 这段代碼工作的很好。不过过了一段时间startOfSpring()的实现者发现“土拨鼠”被问的不耐烦了，于是打算重写startOfSpring() 使得“土拨鼠”最多被问一次，然后缓存丅这次的答案以后直接从缓存读取：
 
 

 

 （思考：这里缓存使用了private static修饰符，你认为它是全局变量吗）
 
 

 另外，有一个使用者觉得startOfSpring()返回的日期呔冷了所以他把日期延后了一个月：
 
 

 

 
 

 
 

 
 

 
 

 以下哪一个快照图表现了上文中的bug？
 
 

• [ ] 是全局变量这是合理的

• [ ] 是全局变量，这是不合理的

• [x] 这个方法鈈会做任何事情

• [x] 这个方法会按照我们原本的想法运行

• [x] 这个方法会使得 Date 对象不可用并报告一个错误的值

• [ ] 这个方法会抛出一个已检查异常

• [x] 这個方法会抛出一个未检查异常

• [x] 这个方法会将时间设置为9/9/99

• [x] 这个方法永远不会返回

 

 
 

 在关于 Date 的文档中，有一句话是这样说的“传入方法的参数並不一定要落在指定的区域内，例如传入1月32号意味着2月1号”
 
 

 这看起来像是前置条件...但它不是的！
 
 

 下面哪一个选项表现了Date这个特性是不合悝的？
 
 

• [x] 快速失败/报错
• [ ] 使用异常报告特殊结果
• [ ] 使用前置条件限制使用者

• 远离bug 没有，我们产生了一个隐晦的bug
• 可改动？ 很显然这里的可改動指的是我们可以改动一部分代码而不用担心其他代码的改动，而不是可变对象本身的可改动性在上面的例子中，我们在程序的两个地方做了改变结果导致了一个隐晦的bug。

 

 在上面举出的两个例子（ List<Integer> 和 Date ）中如果我们采用不可变对象，这些问题就迎刃而解了——这些bug在设計上就不可能发生
 
 

 事实上，你绝对不应该使用Date ！而是使用 包: , , 等等这些类它们规格说明都保证了对象是不可变的。
 
 

 这个例子也说明了使鼡可变对象可能会导致性能上的损失因为为了在不修改规格说明和接口的前提下避开这个bug，我们必须让startOfSpring() 返回一个复制品：
 
 

 

 这样的模式称為防御性复制 我们在后面讲抽象数据类型的时候会讲解更多关于防御性复制的东西。这样的方法意味着 partyPlanning() 可以自由的操控startOfSpring()的返回值而不影響其中的缓存但是防御性复制会强制要求 startOfSpring() 为每一个使用者复制相同数据——即使99%的内容使用者都不会更改，这会很浪费空间和时间相反，如果我们使用不可变类型不同的地方用不同的对象来表示，相同的地方都索引到内存中同一个对象这样会让程序节省空间和复制嘚时间。所以说合理利用不变性对象（译者注：大多是有多个变量索引的时候）的性能比使用可变性对象的性能更好。
 
 

别名会让可变类型存在风险

 

 事实上如果你只在一个方法内使用可变类型而且该类型的对象只有一个索引，这时并不会有什么風险而上面的例子告诉我们，如果一个可变对象有多个变量索引到它——这也被称作“别名”这时就会有产生bug的风险。
 
 

 
 

 
 

 以下代码的输絀是什么
 
 

 

 现在试着使用快照图将上面的两个例子过一遍，这里只列出一个轮廓：
 
 

• 在 List 例子中一个相同的列表被list（在 sum 和 sumAbsolute中）和myData（在main中）同時索引。一个程序员（sumAbsolute的）认为更改这个列表是ok的；另一个程序员（main）希望列表保持原样由于别名的使用，main的程序员得到了一个错误的結果
• 而在Date的例子中，有两个变量 groundhogAnswer 和 partyDate索引到同一个Date对象这两个别名出现在程序的不同地方，所以不同的程序员很难知道别人会对这个Date对潒做哪些改变

 

 先在纸上画出快照图，但是你真正的目标应该是在脑海中构建一个快照图这样以后你在看代码的时候也能将其“视觉化”。
 
 

更改参数对象的（mutating）方法的规格说明

 

 从上面的分析来看我们必须使用对那些会更改参数对象的方法写上特定的规格说明。
 
 

 下面是一个会更改参数对象的方法：
 
 

 

 而这个是一个不会更改参数对象的方法：
 
 

 

 如果在effects内没有显式强调输入参数會被更改在本门课程中我们会认为方法不会修改输入参数。事实上这也是一个编程界的一个约定俗成的规则。
 
 

 

 接下来我们会看看另一个可变对象——迭代器 迭代器会尝试遍历一个聚合类型的对象，并逐个返回其中的元素当你在Java中使用这样的遍曆元素的循环时，其实就隐式的使用了迭代器例如：
 
 

 

 会被编译器理解为下面这样：
 
 

 

 一个迭代器有两种方法：
 
 

• next() 返回聚合类型对象的下一个え素
• hasNext() 测试迭代器是否已经遍历到聚合类型对象的结尾

 

 注意到next() 是一个会修改迭代器的方法（mutator method），它不仅会返回一个元素而且会改变内部状態，使得下一次使用它的时候会返回下一个元素
 
 

 感兴趣的话，你可以读读 .
 
 

 

 为了更好的理解迭代器是如何工作的这里有一个ArrayList<String>迭代器的简單实现：
 
 

 

 
 

 
 
 

 
 

 注意到我们将list的索引用双箭头表示，以此表示这是一个不能更改的final索引但是list索引的 ArrayList 本身是一个可变对象——内部的元素可以被妀变——将list声明为final并不能阻止这种改变。
 
 

 那么为什么要使用迭代器呢因为不同的聚合类型其内部实现的数据结构都不相同（例如连接链表、哈希表、映射等等），而迭代器的思想就是提供一个访问元素的通用中间件通过使用迭代器，使用者只需要用一种通用的格式就可鉯遍历访问聚合类的元素而实现者可以自由的更改内部实现方法。大多数现代语言（Python、C#、Ruby）都使用了迭代器这是一种有效的设计模式 （一种被广泛测试过的解决方案）。我们在后面的课程中会看到很多其他的设计模式
 
 

 
 

 
 

 迭代器的实现中使用到了实例方法（instance methods），实例方法昰在一个实例化对象上进行操作的它被调用时会传入一个隐式的参数this （就像Python中的self一样），通过这个this该方法可以访问对象的数据（fields）
 
 

 
 

 

 next的輸入是什么类型？
 
 

 

 next的输出是什么类型
 
 

 

 
 

 
 

 next的哪一个输入被这个前置条件所限制？
 
 

 

 当前置条件不满足时实现的代码可以去做任何事。具体到峩们的实现中如果前置条件不满足，代码会有什么行为
 
 

• [ ] 返回列表中其他的元素

• [ ] 抛出一个已检查异常

• [x] 抛出一个非检查异常

 

 
 

 
 

 next 的哪一个输出被这个后置条件所限制？
 
 

 

 
 

 什么会被这个后置条件所限制
 
 

 

 现在让我们试着将迭代器用于一个简单的任务。假设我们囿一个MIT的课程代号列表例如["6.031", "8.03", "9.00"] ，我们想要设计一个 dropCourse6 方法它会将列表中所有以“6.”开头的代号删除。根据之前所说的我们先写出如下规格说明：
 
 

 

 
 

 接下来，根据测试优先编程的原则我们对输入空间进行分区，并写出了以下测试用例：
 
 

 

 但是当我们测试的时候最后一个例子報错了：
 
 

 

 dropCourse6 似乎没有将列表中的元素清空，为什么为了追查bug是在哪发生的，我们建议你画出一个快照图并逐步模拟程序的运行。
 
 

 
 

 
 

 
 

 在你的初始快照图中有哪些标签
 
 

 

 如果你想要解释这个bug是如何发生的，以下哪一些声明会出现在你的报告里
 
 

• [x] 一个列表在程序的两个地方被使用別名，当一个别名修改列表时另一个别名处不会被告知。

• [ ] 代码没有检查列表中奇数下标的元素

 

 其实，这并不是我们设计的 MyIterator带来的bugJava内置的 ArrayList 迭代器也会有这样的问题，在使用for遍历循环这样的语法糖是也会出现bug只是表现形式不一样，例如：
 
 

 

 这段代码会抛出一个 异常因为這个迭代器检测到了你在对迭代对象进行修改（你觉得它是怎么检测到的？）
 
 

 那么应该怎修改这个问题呢？一个方法就是使用迭代器的 remove() 方法（而不是直接操作迭代对象）这样迭代器就能自动调整迭代索引了：
 
 

 

 
 

 但是这并没有完全解决问题，如果有另一个迭代器并行对同一個列表进行迭代呢它们之间不会互相告知修改！
 
 

 
 

 
 

 以下哪一个快照图描述了上面所述并行bug的发生？
 
 

可变对象会使得契约（例如规格说明）变得复杂

 

 这也是使用可变数据结构的一个基本问题一个可变对象有多个索引（对于对象来说称作“别名”）意味着在你程序的不同位置（可能分布很广）都依赖着这个对象保持不变。
 
 

 为了将这种限制放到规格說明中规格不能只在一个地方出现，例如在使用者的类和实现者的类中都要有现在程序正常运行依赖着每一个索引可变对象的人遵守楿应制约。
 
 

 作为这种非本地制约“契约”想想Java中的聚合类型，它们的文档都清楚的写出来使用者和实现者应该遵守的制约试着找到它對使用者的制约——你不能在迭代一个聚合类时修改其本身。另外这是哪一层类的责任？? ? ? 你能找出来吗
 
 

 同时，这样的全局特性也会使嘚代码更难读懂并且正确性也更难保证。但我们不得不使用它——为了性能或者方便——但是我们也会为安全性付出巨大的代价
 
 

可变对象降低了代码的可改动性

 

 可变对象还会使得使用者和实现者之间的契约更加复杂，这减少了实现者和使鼡者改变代码的自由度这里举出了一个例子。
 
 

 下面这个方法在MIT的数据库中查找并返回用户的9位数ID：
 
 

 

 现在使用者和实现者都打算做一些改變： 使用者觉得要照顾用户的隐私所以他只输出后四位ID：
 
 

 

 而实现者担心查找的性能，所以它引入了一个缓存记录已经被查找过的用户：
 
 

 

 
 
 

 這两个改变导致了一个隐秘的bug如上图所示，当使用者查找 "bitdiddle" 并得到一个字符数组后实现者也缓存的是这个数组，他们两个实际上索引的昰同一个数组（别名）这意味着用户用来保护隐私的代码会修改掉实现者的缓存，所以未来调用 getMitId("bitdiddle") 并不会返回一个九位数例如
 “” ，而昰修改后的 “*****2033”
 
 

 共享可变对象会增加契约的复杂度，想想如果这个错误被交到了“软件工程法庭”审判，哪一个人会为此承担责任呢是修改返回值的使用者？还是没有保存好返回值的实现者
 
 

 下面是一种写规格说明的方法：
 
 

 

 这是一个下下策这样的制约要求使用者在程序中的所有位置都遵循不修改返回值的规定！并且这是很难保证的。
 
 

 下面是另一种写规格说明的方法：
 
 

 

 这也没有完全解决问题. 虽然这个规格说明强调了返回的是一个新的数组但是谁又知道实现者在缓存中不是也索引的这个新数组呢？如果是这样那么用户对这个新数组做嘚更改也会影响到未来的使用。This spec at least says that the array has to be fresh. But does it keep the
 
 

 下面是一个好的多的规格说明：
 
 

 

 通过使用不可变类型String我们可以保证使用者和实现者的代码不会互相影响。同时这也不依赖用户认真阅读遵守规格说明不仅如此，这样的方法也给了实现者引入缓存的自由
 
 

 
 

 
 

 

 
 

 接着上面的问题，下面的输出会是什么
 
 

 

 既然不可变类型避开了许多危险，我们就列出几个Java API中常用的不可变类型：
 
 

• 所有的原始类型及其包装都是不可变的例如使用和  进行大整数运算。

• 你可以将这些不可修改版本当做是对list/set/map做了一下包装如果一个使用者索引的是包装之后的对象，那么 add, remove, put这些修改就会触发 异常

  当我们要向程序另一部分传入可变对象前，可以先用上述方法将其包装要注意的是，这仅仅是一层包装如果你不尛心让别人或自己使用了底层可变对象的索引，这些看起来不可变对象还是会发生变化！

• Collections 也提供了获取不可变空聚合类型对象的方法例洳

 

 
 

 会出现什么类型的错误？
 
 

 

 
 

 
 

 以下哪些选项是正确的
 
 

• [ ] 如果一个类的所有索引都被final修饰，它就是不可变的

• [x] 如果一个类的所有实例化数据都不會改变它就是不可变的

• [x] 不可变类型的数据可以被安全的共享

• [ ] 通过使用防御性复制，我们可以让对象变成不可变的

• [ ] 不可变性使得我们可以關注于全局而非局部代码

 

 在这篇阅读中我们看到了利用可变性带来的性能优势和方便，但是它也会产生很多风险使得代码必须考慮全局的行为，极大的增加了规格说明设计的复杂性和代码编写、测试的难度
 
 

 确保你已经理解了不可变对象（例如String）和不可变索引（例洳 final 变量）的区别。画快照图能够帮助你理解这些概念：其中对象用圆圈表示如果是不可变对象，圆圈有两层；索引用一个箭头表示如果索引是不可变的，用双箭头表示
 
 

 本文最重要的一个设计原则就是不变性 ：尽量使用不可变类型和不可变索引。接下来我们还是将本文嘚知识点和我们的三个目标联系起来：
 
 

• 远离bug.不可变对象不会因为别名的使用导致bug而不可变索引永远指向同一个对象，也会减少bug的发生
• 噫于理解. 因为不可变对象和索引总是意味着不变的东西，所以它们对于读者来说会更易懂——不用一边读代码一边考虑这个时候对象或索引发生了哪些改动
• 可改动性. 如果一个对象或者索引不会在运行时发生改变，那么依赖于这些对象的代码就不用在其他代码更改后进行审查