java 传递和返回对象

《java 传递和返回对象》由会员分享，可在线阅读，更多相关《java 传递和返回对象（18页珍藏版）》请在金锄头文库上搜索。

1、第 12 章 传递和返回对象 到目前为止，读者应对对象的“传递”有了一个较为深刻的认识，记住实际传递 的只是一个句柄。在许多程序设计语言中，我们可用语言的“普通”方式到处传递对象，而且大多 数时候都不会遇到问题。但有些时候却不得不采取一些非常做法，使得情况突然 变得稍微复杂起来（在C+中则是变得非常复杂）。Java亦不例外，我们十分有 必要准确认识在对象传递和赋值时所发生的一切。这正是本章的宗旨。若读者是从某些特殊的程序设计环境中转移过来的，那么一般都会问到：“Java 有指针吗？”有些人认为指针的操作很困难，而且十分危险，所以一厢情愿地认 为它没有好处。同时由于Java有如此好的口碑，所以应

2、该很轻易地免除自己以 前编程中的麻烦，其中不可能夹带有指针这样的“危险品”。然而准确地说Java 是有指针的！事实上，Java中每个对象（除基本数据类型以外）的标识符都属 于指针的一种。但它们的使用受到了严格的限制和防范，不仅编译器对它们有 “戒心”，运行期系统也不例外。或者换从另一个角度说，Java有指针，但没 有传统指针的麻烦。我曾一度将这种指针叫做“句柄”，但你可以把它想像成“安全指针”。和预备学校为学生提供的安全剪刀类似除非特别有意，否则 不会伤着自己，只不过有时要慢慢来，要习惯一些沉闷的工作。12.1 传递句柄 将句柄传递进入一个方法时，指向的仍然是相同的对象。一个简单的实验可以证

3、明这一点（若执行这个程序时有麻烦，请参考第 3 章 3.1.2 小节“赋值”）：542 页程序toString 方法会在打印语句里自动调用，而 PassHandles 直接从 Object 继承， 没有 toString 的重新定义。因此，这里会采用 toString 的 Object 版本，打印 出对象的类，接着是那个对象所在的位置（不是句柄，而是对象的实际存储位置）。 输出结果如下：p inside main（）: PassHandles1653748h inside f（） : PassHandles1653748可以看到，无论p还是h引用的都是同一个对象。这比复制一个新的PassHan

4、dles 对象有效多了，使我们能将一个参数发给一个方法。但这样做也带来了另一个重 要的问题。12.1.1 别名问题“别名”意味着多个句柄都试图指向同一个对象，就象前面的例子展示的那样。 若有人向那个对象里写入一点什么东西，就会产生别名问题。若其他句柄的所有 者不希望那个对象改变，恐怕就要失望了。这可用下面这个简单的例子说明：543 页程序对下面这行：Alias1 y = x; / Assign the handle它会新建一个 Alias1 句柄，但不是把它分配给由 new 创建的一个新鲜对象，而 是分配给一个现有的句柄。所以句柄 x 的内容即对象 x 指向的地址被分 配给y,所以无论x还是y

5、都与相同的对象连接起来。这样一来，一旦x的i在 下述语句中增值：x.i+;y的i值也必然受到影响。从最终的输出就可以看出：544 页上程序此时最直接的一个解决办法就是干脆不这样做：不要有意将多个句柄指向同一个 作用域内的同一个对象。这样做可使代码更易理解和调试。然而，一旦准备将句 柄作为一个自变量或参数传递这是 Java 设想的正常方法别名问题就会 自动出现，因为创建的本地句柄可能修改“外部对象”（在方法作用域之外创建 的对象）。下面是一个例子：544 页程序输出如下：x: 7Calling f（x）x: 8方法改变了自己的参数外部对象。一旦遇到这种情况，必须判断它是否合理， 用户是否愿意这样

6、，以及是不是会造成问题。通常，我们调用一个方法是为了产生返回值，或者用它改变为其调用方法的那个 对象的状态（方法其实就是我们向那个对象“发一条消息”的方式）。很少需要 调用一个方法来处理它的参数；这叫作利用方法的“副作用”（SideEffec t）。 所以倘若创建一个会修改自己参数的方法，必须向用户明确地指出这一情况，并 警告使用那个方法可能会有的后果以及它的潜在威胁。由于存在这些混淆和缺 陷，所以应该尽量避免改变参数。若需在一个方法调用期间修改一个参数，且不打算修改外部参数，就应在自己的 方法内部制作一个副本，从而保护那个参数。本章的大多数内容都是围绕这个问 题展开的。12.2 制作本地副本

7、稍微总结一下： Java 中的所有自变量或参数传递都是通过传递句柄进行的。也 就是说，当我们传递“一个对象”时，实际传递的只是指向位于方法外部的那个 对象的“一个句柄”。所以一旦要对那个句柄进行任何修改，便相当于修改外部 对象。此外：参数传递过程中会自动产生别名问题 不存在本地对象，只有本地句柄句柄有自己的作用域，而对象没有对象的“存在时间”在 Java 里不是个问题 没有语言上的支持（如常量）可防止对象被修改（以避免别名的副作用）若只是从对象中读取信息，而不修改它，传递句柄便是自变量传递中最有效的一 种形式。这种做非常恰当；默认的方法一般也是最有效的方法。然而，有时仍需 将对象当作“本地的”

8、对待，使我们作出的改变只影响一个本地副本，不会对外 面的对象造成影响。许多程序设计语言都支持在方法内自动生成外部对象的一个 本地副本(注释)。尽管Java不具备这种能力，但允许我们达到同样的效果。：在C语言中，通常控制的是少量数据位，默认操作是按值传递。C+也必须 遵照这一形式，但按值传递对象并非肯定是一种有效的方式。此外，在C+中用 于支持按值传递的代码也较难编写，是件让人头痛的事情。12.2.1 按值传递 首先要解决术语的问题，最适合“按值传递”的看起来是自变量。“按值传递” 以及它的含义取决于如何理解程序的运行方式。最常见的意思是获得要传递的任 何东西的一个本地副本，但这里真正的问题是如

9、何看待自己准备传递的东西。对 于“按值传递”的含义，目前存在两种存在明显区别的见解：(1) Java按值传递任何东西。若将基本数据类型传递进入一个方法，会明确得 到基本数据类型的一个副本。但若将一个句柄传递进入方法，得到的是句柄的副 本。所以人们认为“一切”都按值传递。当然，这种说法也有一个前提：句柄肯 定也会被传递。但 Java 的设计方案似乎有些超前，允许我们忽略(大多数时候) 自己处理的是一个句柄。也就是说，它允许我们将句柄假想成“对象”，因为在 发出方法调用时，系统会自动照管两者间的差异。(2) Java 主要按值传递(无自变量)，但对象却是按引用传递的。得到这个结 论的前提是句柄只是

10、对象的一个“别名”，所以不考虑传递句柄的问题，而是直 接指出“我准备传递对象”。由于将其传递进入一个方法时没有获得对象的一个 本地副本，所以对象显然不是按值传递的。 Sun 公司似乎在某种程度上支持这一 见解，因为它“保留但未实现”的关键字之一便是byvalue (按值)。但没人知 道那个关键字什么时候可以发挥作用。尽管存在两种不同的见解，但其间的分歧归根到底是由于对“句柄”的不同解释 造成的。我打算在本书剩下的部分里回避这个问题。大家不久就会知道，这个问 题争论下去其实是没有意义的最重要的是理解一个句柄的传递会使调用者 的对象发生意外的改变。12.2.2 克隆对象若需修改一个对象，同时不想改

11、变调用者的对象，就要制作该对象的一个本地副 本。这也是本地副本最常见的一种用途。若决定制作一个本地副本，只需简单地 使用clone()方法即可。Clone是“克隆”的意思，即制作完全一模一样的副本。 这个方法在基础类Object中定义成“protected”(受保护)模式。但在希望克 隆的任何衍生类中，必须将其覆盖为“public”模式。例如，标准库类Vector 覆盖了 clone()，所以能为Vector调用clone()，如下所示： 547 页程序 clone()方法产生了一个Object，后者必须立即重新造型为正确类型。这个例子 指出Vector的clone()方法不能自动尝试克隆Ve

12、ctor内包含的每个对象 由 于别名问题，老的Vector和克隆的Vector都包含了相同的对象。我们通常把这 种情况叫作“简单复制”或者“浅层复制”，因为它只复制了一个对象的“表 面”部分。实际对象除包含这个“表面”以外，还包括句柄指向的所有对象，以 及那些对象又指向的其他所有对象，由此类推。这便是“对象网”或“对象关系 网”的由来。若能复制下所有这张网，便叫作“全面复制”或者“深层复制”。在输出中可看到浅层复制的结果，注意对v2采取的行动也会影响到v：548 页上程序一般来说，由于不敢保证Vector里包含的对象是“可以克隆”(注释)的， 所以最好不要试图克隆那些对象。：“可以克隆”用英语

13、讲是cloneable，请留意Java库中专门保留了这样的 一个关键字。12.2.3 使类具有克隆能力 尽管克隆方法是在所有类最基本的 Object 中定义的，但克隆仍然不会在每个类 里自动进行。这似乎有些不可思议，因为基础类方法在衍生类里是肯定能用的。 但Java确实有点儿反其道而行之；如果想在一个类里使用克隆方法，唯一的办 法就是专门添加一些代码，以便保证克隆的正常进行。1. 使用 protected 时的技巧为避免我们创建的每个类都默认具有克隆能力，clone()方法在基础类Object 里得到了“保留”(设为pro tec ted)。这样造成的后果就是：对那些简单地使 用一下这个类的客

14、户程序员来说，他们不会默认地拥有这个方法；其次，我们不 能利用指向基础类的一个句柄来调用clone()(尽管那样做在某些情况下特别有 用，比如用多形性的方式克隆一系列对象)。在编译期的时候，这实际是通知我 们对象不可克隆的一种方式而且最奇怪的是，Java库中的大多数类都不能克隆。因此，假如我们执行下述代码：Integer x = new Integer(l);x = x.clone();那么在编译期，就有一条讨厌的错误消息弹出，告诉我们不可访问clone() 因为 Integer 并没有覆盖它，而且它对 protected 版本来说是默认的)。但是，假若我们是在一个从Object衍生出来的类中

15、(所有类都是从Object衍生 的)，就有权调用Objec t.clone()，因为它是“ pro tec ted”，而且我们在一个 继承器中。基础类clone()提供了一个有用的功能一一它进行的是对衍生类对象 的真正“按位”复制，所以相当于标准的克隆行动。然而，我们随后需要将自己 的克隆操作设为public，否则无法访问。总之，克隆时要注意的两个关键问题 是：几乎肯定要调用super.clone()，以及注意将克隆设为public。有时还想在更深层的衍生类中覆盖clone()，否则就直接使用我们的clone()(现 在已成为public)，而那并不一定是我们所希望的(然而，由于Objec t

16、.clone() 已制作了实际对象的一个副本，所以也有可能允许这种情况)。protected的技 巧在这里只能用一次：首次从一个不具备克隆能力的类继承，而且想使一个类变 成“能够克隆”。而在从我们的类继承的任何场合，clone()方法都是可以使用 的，因为Java不可能在衍生之后反而缩小方法的访问范围。换言之，一旦对象 变得可以克隆，从它衍生的任何东西都是能够克隆的，除非使用特殊的机制(后 面讨论)令其“关闭”克隆能力。2.实现 Cloneable 接口为使一个对象的克隆能力功成圆满，还需要做另一件事情:实现Cloneable接口。 这个接口使人稍觉奇怪，因为它是空的！interface Cloneable 之所以要实现这个空接口，显然不是因为我们准备上溯造型成一个Cloneable， 以及调