Thinking in Java 3rd Edition phần 10 docx

This is the world view that the reference is an alias for the object, so you don’t think about passing references, but instead say “I’m passing the object.” Since you don’t get a local

books (generally, however, these books are small and pleasant to read) Feedback

XP is both a philosophy about programming work and a set of guidelines

to do it Some of these guidelines are reflected in other recent

methodologies, but the two most important and distinct contributions, in

my opinion, are “write tests first” and “pair programming.” Although he argues strongly for the whole process, Beck points out that if you adopt only these two practices you’ll greatly improve your productivity and reliability Feedback

Write tests first

Testing has traditionally been relegated to the last part of a project, after you’ve “gotten everything working, but just to be sure.” It’s implicitly had

a low priority, and people who specialize in it have not been given a lot of status and have often even been cordoned off in a basement, away from the “real programmers.” Test teams have responded in kind, going so far

as to wear black clothing and cackling with glee whenever they break something (to be honest, I’ve had this feeling myself when breaking compilers) Feedback

XP completely revolutionizes the concept of testing by giving it equal (or

even greater) priority than the code In fact, you write the tests before you

write the code that will be tested, and the tests stay with the code forever The tests must be executed successfully every time you do a build of the project (which is often, sometimes more than once a day) Feedback

Writing tests first has two extremely important effects Feedback

First, it forces a clear definition of the interface of a class I’ve often suggested that people “imagine the perfect class to solve a particular problem” as a tool when trying to design the system The XP testing strategy goes further than that—it specifies exactly what the class must look like, to the consumer of that class, and exactly how the class must behave In no uncertain terms You can write all the prose, or create all the diagrams you want, describing how a class should behave and what it looks like, but nothing is as real as a set of tests The former is a wish list, but the tests are a contract that is enforced by the compiler and the test

framework It’s hard to imagine a more concrete description of a class than the tests Feedback

While creating the tests, you are forced to completely think out the class and will often discover needed functionality that might be missed during the thought experiments of UML diagrams, CRC cards, use cases, etc Feedback

The second important effect of writing the tests first comes from running the tests every time you do a build of your software This activity gives you the other half of the testing that’s performed by the compiler If you look

at the evolution of programming languages from this perspective, you’ll see that the real improvements in the technology have actually revolved around testing Assembly language checked only for syntax, but C

imposed some semantic restrictions, and these prevented you from

making certain types of mistakes OOP languages impose even more semantic restrictions, which if you think about it are actually forms of testing “Is this data type being used properly?” and “Is this method being called properly?” are the kinds of tests that are being performed by the compiler or run-time system We’ve seen the results of having these tests built into the language: people have been able to write more complex systems, and get them to work, with much less time and effort I’ve

puzzled over why this is, but now I realize it’s the tests: you do something wrong, and the safety net of the built-in tests tells you there’s a problem and points you to where it is Feedback

But the built-in testing afforded by the design of the language can only go

so far At some point, you must step in and add the rest of the tests that

produce a full suite (in cooperation with the compiler and run-time

system) that verifies all of your program And, just like having a compiler watching over your shoulder, wouldn’t you want these tests helping you right from the beginning? That’s why you write them first, and run them automatically with every build of your system Your tests become an extension of the safety net provided by the language Feedback

One of the things that I’ve discovered about the use of more and more powerful programming languages is that I am emboldened to try more brazen experiments, because I know that the language will keep me from wasting my time chasing bugs The XP test scheme does the same thing

for your entire project Because you know your tests will always catch any problems that you introduce (and you regularly add any new tests as you think of them), you can make big changes when you need to without worrying that you’ll throw the whole project into complete disarray This

is incredibly powerful Feedback

In this third edition of this book, I realized that testing was so important that it must also be applied to the examples in the book itself With the help of the Crested Butte Summer 2002 Interns, we developed the testing system that you will see used throughout this book The code and

description is in Chapter 15 This system has increased the robustness of the code examples in this book immeasurably Feedback

Pair programming

Pair programming goes against the rugged individualism that we’ve been indoctrinated into from the beginning, through school (where we succeed

or fail on our own, and working with our neighbors is considered

“cheating”), and media, especially Hollywood movies in which the hero is usually fighting against mindless conformity13 Programmers, too, are considered paragons of individuality—“cowboy coders” as Larry

Constantine likes to say And yet XP, which is itself battling against

conventional thinking, says that code should be written with two people per workstation And that this should be done in an area with a group of workstations, without the barriers that the facilities-design people are so fond of In fact, Beck says that the first task of converting to XP is to arrive with screwdrivers and Allen wrenches and take apart everything that gets

in the way.14 (This will require a manager who can deflect the ire of the facilities department.) Feedback

interrupted our productivity (but the managers couldn’t begin to conceive of stifling such

an important service as the PA) Finally, when no one was looking I started snipping speaker wires

The value of pair programming is that one person is actually doing the coding while the other is thinking about it The thinker keeps the big picture in mind—not only the picture of the problem at hand, but the guidelines of XP If two people are working, it’s less likely that one of them will get away with saying, “I don’t want to write the tests first,” for example And if the coder gets stuck, they can swap places If both of them get stuck, their musings may be overheard by someone else in the work area who can contribute Working in pairs keeps things flowing and on track Probably more important, it makes programming a lot more social and fun Feedback

I’ve begun using pair programming during the exercise periods in some of

my seminars and it seems to significantly improve everyone’s experience Feedback

Strategies for transition

If you buy into OOP, your next question is probably, “How can I get my manager/colleagues/department/peers to start using objects?” Think about how you—one independent programmer—would go about learning

to use a new language and a new programming paradigm You’ve done it before First comes education and examples; then comes a trial project to give you a feel for the basics without doing anything too confusing Then comes a “real world” project that actually does something useful

Throughout your first projects you continue your education by reading, asking questions of experts, and trading hints with friends This is the approach many experienced programmers suggest for the switch to Java Switching an entire company will of course introduce certain group

dynamics, but it will help at each step to remember how one person would

do it Feedback

Guidelines

Here are some guidelines to consider when making the transition to OOP and Java: Feedback

1 Training

The first step is some form of education Remember the company’s

investment in code, and try not to throw everything into disarray for six to nine months while everyone puzzles over unfamiliar features Pick a small group for indoctrination, preferably one composed of people who are curious, work well together, and can function as their own support

network while they’re learning Java Feedback

An alternative approach is the education of all company levels at once, including overview courses for strategic managers as well as design and programming courses for project builders This is especially good for smaller companies making fundamental shifts in the way they do things,

or at the division level of larger companies Because the cost is higher, however, some may choose to start with project-level training, do a pilot project (possibly with an outside mentor), and let the project team

become the teachers for the rest of the company Feedback

2 Low-risk project

Try a low-risk project first and allow for mistakes Once you’ve gained some experience, you can either seed other projects from members of this first team or use the team members as an OOP technical support staff This first project may not work right the first time, so it should not be mission-critical for the company It should be simple, self-contained, and instructive; this means that it should involve creating classes that will be meaningful to the other programmers in the company when they get their turn to learn Java Feedback

3 Model from success

Seek out examples of good object-oriented design before starting from scratch There’s a good probability that someone has solved your problem already, and if they haven’t solved it exactly you can probably apply what you’ve learned about abstraction to modify an existing design to fit your

needs This is the general concept of design patterns, covered in Thinking

in Patterns with Java at www.BruceEckel.com Feedback

4 Use existing class libraries

An important economic motivation for switching to OOP is the easy use of existing code in the form of class libraries (in particular, the Standard Java libraries, which are covered throughout this book) The shortest application development cycle will result when you can create and use objects from off-the-shelf libraries However, some new programmers don’t understand this, are unaware of existing class libraries, or, through fascination with the language, desire to write classes that may already exist Your success with OOP and Java will be optimized if you make an effort to seek out and reuse other people’s code early in the transition process Feedback

5 Don’t rewrite existing code in Java

It is not usually the best use of your time to take existing, functional code and rewrite it in Java (If you must turn it into objects, you can interface

to the C or C++ code using the Java Native Interface or XML) There are incremental benefits, especially if the code is slated for reuse But chances are you aren’t going to see the dramatic increases in productivity that you hope for in your first few projects unless that project is a new one Java and OOP shine best when taking a project from concept to reality FeedbackManagement obstacles

If you’re a manager, your job is to acquire resources for your team, to overcome barriers to your team’s success, and in general to try to provide the most productive and enjoyable environment so your team is most likely to perform those miracles that are always being asked of you

Moving to Java falls in all three of these categories, and it would be

wonderful if it didn’t cost you anything as well Although moving to Java may be cheaper—depending on your constraints—than the OOP

alternatives for a team of C programmers (and probably for programmers

in other procedural languages), it isn’t free, and there are obstacles you should be aware of before trying to sell the move to Java within your company and embarking on the move itself Feedback

Startup costs

The cost of moving to Java is more than just the acquisition of Java

compilers (the Sun Java compiler is free, so this is hardly an obstacle) Your medium- and long-term costs will be minimized if you invest in training (and possibly mentoring for your first project) and also if you identify and purchase class libraries that solve your problem rather than trying to build those libraries yourself These are hard-money costs that must be factored into a realistic proposal In addition, there are the

hidden costs in loss of productivity while learning a new language and possibly a new programming environment Training and mentoring can certainly minimize these, but team members must overcome their own struggles to understand the new technology During this process they will make more mistakes (this is a feature, because acknowledged mistakes are the fastest path to learning) and be less productive Even then, with some types of programming problems, the right classes, and the right development environment, it’s possible to be more productive while you’re learning Java (even considering that you’re making more mistakes and writing fewer lines of code per day) than if you’d stayed with C Feedback

Performance issues

A common question is, “Doesn’t OOP automatically make my programs a lot bigger and slower?” The answer is, “It depends.” The extra safety features in Java have traditionally extracted a performance penalty over a language like C++ Technologies such as “hotspot” and compilation

technologies have improved the speed significantly in most cases, and efforts continue toward higher performance Feedback

When your focus is on rapid prototyping, you can throw together

components as fast as possible while ignoring efficiency issues If you’re using any third-party libraries, these are usually already optimized by their vendors; in any case it’s not an issue while you’re in rapid-

development mode When you have a system that you like, if it’s small and fast enough, then you’re done If not, you begin tuning with a profiler, looking first for speedups that can be done by rewriting small portions of code If that doesn’t help, you look for modifications that can be made in the underlying implementation so no code that uses a particular class needs to be changed Only if nothing else solves the problem do you need

to change the design If performance is so critical in that portion of the design, it must be part of the primary design criteria You have the benefit

of finding this out early using rapid development

Chapter 15 introduces profilers, which can help you discover bottlenecks

in your system so you can optimize that portion of your code (with the hotspot technologies, Sun no longer recommends using native methods for performance optimization) Optimization tools are also available Feedback

Common design errors

When starting your team into OOP and Java, programmers will typically

go through a series of common design errors This often happens due to insufficient feedback from experts during the design and implementation

of early projects, because no experts have been developed within the company, and because there may be resistance to retaining consultants It’s easy to feel that you understand OOP too early in the cycle and go off

on a bad tangent Something that’s obvious to someone experienced with the language may be a subject of great internal debate for a novice Much

of this trauma can be skipped by using an experienced outside expert for training and mentoring Feedback

Summary

This chapter was only intended to give you concepts of OOP

methodologies, and the kinds of issues you will encounter when moving your own company to OOP and Java More about Object design can be learned at the MindView seminar “Designing Objects and Systems” (see

“Seminars” at www.MindView.net).

A: Passing &

Returning

Objects

By now you should be reasonably comfortable with the

idea that when you’re “passing” an object, you’re actually

passing a reference

In many programming languages you can use that language’s “regular”

way to pass objects around, and most of the time everything works fine

But it always seems that there comes a point at which you must do

something irregular and suddenly things get a bit more complicated (or in

the case of C++, quite complicated) Java is no exception, and it’s

important that you understand exactly what’s happening as you pass

objects around and manipulate them This appendix will provide that

insight Feedback

Another way to pose the question of this appendix, if you’re coming from

a programming language so equipped, is “Does Java have pointers?”

Some have claimed that pointers are hard and dangerous and therefore

bad, and since Java is all goodness and light and will lift your earthly

programming burdens, it cannot possibly contain such things However,

it’s more accurate to say that Java has pointers; indeed, every object

identifier in Java (except for primitives) is one of these pointers, but their

use is restricted and guarded not only by the compiler but by the run-time

system Or to put it another way, Java has pointers, but no pointer

arithmetic These are what I’ve been calling “references,” and you can

think of them as “safety pointers,” not unlike the safety scissors of

elementary school—they aren’t sharp, so you cannot hurt yourself without

great effort, but they can sometimes be slow and tedious Feedback

Passing references around When you pass a reference into a method, you’re still pointing to the same object A simple experiment demonstrates this:

//: appendixa:PassReferences.java

// Passing references around

import com.bruceeckel.simpletest.*;

public class PassReferences {

private static Test monitor = new Test();

public static void f(PassReferences h) {

System.out.println("h inside f(): " + h);

}

public static void main(String[] args) {

PassReferences p = new PassReferences();

System.out.println("p inside main(): " + p);

of toString( ) Thus, Object’s version of toString( ) is used, which

prints out the class of the object followed by the address where that object

is located (not the reference, but the actual object storage) The output looks like this: Feedback

p inside main(): PassReferences@ad3ba4

Aliasing

Aliasing means that more than one reference is tied to the same object, as

in the above example The problem with aliasing occurs when someone

writes to that object If the owners of the other references aren’t expecting

that object to change, they’ll be surprised This can be demonstrated with

a simple example: Feedback

//: appendixa:Alias1.java

// Aliasing two references to one object

import com.bruceeckel.simpletest.*;

public class Alias1 {

private static Test monitor = new Test();

private int i;

public Alias1(int ii) { i = ii; }

public static void main(String[] args) {

Alias1 x = new Alias1(7);

Alias1 y = x; // Assign the reference

Alias1 y = x; // Assign the reference

a new Alias1 reference is created, but instead of being assigned to a fresh object created with new, it’s assigned to an existing reference So the contents of reference x, which is the address of the object x is pointing to,

is assigned to y, and thus both x and y are attached to the same object So when x’s i is incremented in the statement: Feedback

to work—you automatically alias because the local reference that’s created can modify the “outside object” (the object that was created outside the scope of the method) Here’s an example: Feedback

//: appendixa:Alias2.java

// Method calls implicitly alias their arguments

import com.bruceeckel.simpletest.*;

public class Alias2 {

private static Test monitor = new Test();

private int i;

public Alias2(int ii) { i = ii; }

public static void f(Alias2 reference) { reference.i++; } public static void main(String[] args) {

Alias2 x = new Alias2(7);

The method is changing its argument, the outside object When this kind

of situation arises, you must decide whether it makes sense, whether the user expects it, and whether it’s going to cause problems Feedback

In general, you call a method in order to produce a return value and/or a

change of state in the object that the method is called for It’s much less

common to call a method in order to manipulate its arguments; this is

referred to as “calling a method for its side effects.” Thus, when you create

a method that modifies its arguments, the user must be clearly instructed and warned about the use of that method and its potential surprises Because of the confusion and pitfalls, it’s much better to avoid changing the argument Feedback

If you need to modify an argument during a method call and you don’t intend to modify the outside argument, then you should protect that argument by making a copy inside your method That’s the subject of much of this appendix Feedback

Making local copies

To review: All argument passing in Java is performed by passing

references That is, when you pass “an object,” you’re really passing only a reference to an object that lives outside the method, so if you perform any modifications with that reference, you modify the outside object In addition: Feedback

• Aliasing happens automatically during argument passing

• There are no local objects, only local references

• References have scopes, objects do not

• Object lifetime is never an issue in Java

• There is no language support (e.g., “const”) to prevent objects from being modified and stop the negative effects of aliasing You

can’t simply use the final keyword in the argument list; that

simply prevents you from rebinding the reference to a different object

If you’re only reading information from an object and not modifying it, passing a reference is the most efficient form of argument passing This is nice; the default way of doing things is also the most efficient However, sometimes it’s necessary to be able to treat the object as if it were “local”

so that changes you make affect only a local copy and do not modify the outside object Many programming languages support the ability to automatically make a local copy of the outside object, inside the method1 Java does not, but it allows you to produce this effect Feedback

Pass by value

This brings up the terminology issue, which always seems good for an argument The term is “pass by value,” and the meaning depends on how you perceive the operation of the program The general meaning is that you get a local copy of whatever you’re passing, but the real question is how you think about what you’re passing When it comes to the meaning

of “pass by value,” there are two fairly distinct camps:Feedback

1 Java passes everything by value When you’re passing primitives into a method, you get a distinct copy of the primitive When you’re passing a reference into a method, you get a copy of the reference Ergo, everything is pass-by-value Of course, the assumption is that you’re always thinking (and caring) that references are being passed, but it seems like the Java design has gone a long way toward allowing you to ignore (most of the time) that you’re

working with a reference That is, it seems to allow you to think of the reference as “the object,” since it implicitly dereferences it whenever you make a method call Feedback

2 Java passes primitives by value (no argument there), but objects are passed by reference This is the world view that the reference is

an alias for the object, so you don’t think about passing references,

but instead say “I’m passing the object.” Since you don’t get a local copy of the object when you pass it into a method, objects are clearly not passed by value There appears to be some support for this view within Sun, since at one time, one of the “reserved but not

implemented” keywords was byvalue (This will probably never be

implemented) Feedback

1 In C, which generally handles small bits of data, the default is pass-by-value C++ had to follow this form, but with objects pass-by-value isn’t usually the most efficient way In addition, coding classes to support pass-by-value in C++ is a big headache

Having given both camps a good airing, and after saying “It depends on how you think of a reference,” I will attempt to sidestep the issue In the

end, it isn’t that important—what is important is that you understand that

passing a reference allows the caller’s object to be changed unexpectedly Feedback

Cloning objects

The most likely reason for making a local copy of an object is if you’re going to modify that object and you don’t want to modify the caller’s object If you decide that you want to make a local copy, one approach is

to use the clone( ) method to perform the operation This is a method that’s defined as protected in the base class Object, and which you must override as public in any derived classes that you want to clone For example, the standard library class ArrayList overrides clone( ), so we can call clone( ) for ArrayList: Feedback

//: appendixa:Cloning.java

// The clone() operation works for only a few

// items in the standard Java library

import com.bruceeckel.simpletest.*;

import java.util.*;

class Int {

private int i;

public Int(int ii) { i = ii; }

public void increment() { i++; }

public String toString() { return Integer.toString(i); } }

public class Cloning {

private static Test monitor = new Test();

public static void main(String[] args) {

ArrayList v = new ArrayList();

does not automatically try to clone each of the objects that the ArrayList

contains—the old ArrayList and the cloned ArrayList are aliased to the

same objects This is often called a shallow copy, since it’s copying only

the “surface” portion of an object The actual object consists of this

“surface,” plus all the objects that the references are pointing to, plus all

the objects those objects are pointing to, etc This is often referred to as the “web of objects.” Copying the entire mess is called a deep copy FeedbackYou can see the effect of the shallow copy in the output, where the actions

performed on v2 affect v:

v: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

v: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

Not trying to clone( ) the objects contained in the ArrayList is probably

a fair assumption because there’s no guarantee that those objects are

cloneable2 Feedback

Adding cloneability to a class

Even though the clone method is defined in the base-of-all-classes

Object, cloning is not automatically available in every class3 This would

2 This is not the dictionary spelling of the word, but it’s what is used in the Java library, so I’ve used it here, too, in some hopes of reducing confusion

3 You can apparently create a simple counter-example to this statement, like this:

public class Cloneit implements Cloneable {

public static void main (String[] args)

throws CloneNotSupportedException {

Cloneit a = new Cloneit();

Cloneit b = (Cloneit)a.clone();

seem to be counterintuitive to the idea that base-class methods are always available in derived classes Cloning in Java does indeed go against this idea; if you want it to exist for a class, you must specifically add code to make cloning work Feedback

Using a trick with protected

To prevent default cloneability in every class you create, the clone( ) method is protected in the base class Object Not only does this mean

that it’s not available by default to the client programmer who is simply using the class (not subclassing it), but it also means that you cannot call

clone( ) via a reference to the base class (Although that might seem to be

useful in some situations, such as to polymorphically clone a bunch of

Objects.) It is, in effect, a way to give you, at compile time, the

information that your object is not cloneable—and oddly enough most classes in the standard Java library are not cloneable Thus, if you say:

Integer x = new Integer(1);

x = x.clone();

You will get, at compile time, an error message that says clone( ) is not accessible (since Integer doesn’t override it and it defaults to the

protected version) Feedback

If, however, you’re in a method of a class derived from Object (as all

classes are), then you have permission to call Object.clone( ) because it’s protected and you’re an inheritor The base class clone( ) has useful

functionality—it performs the actual bitwise duplication of the

derived-class object, thus acting as the common cloning operation However, you

then need to make your clone operation public for it to be accessible So,

two key issues when you clone are: Feedback

However, this only works because main( ) is a method of Cloneit and thus has

permission to call the protected base-class method clone( ) If you call it from a

different class, it won’t compile

You’ll probably want to override clone( ) in any further derived classes, otherwise your (now public) clone( ) will be used, and that might not do the right thing (although, since Object.clone( ) makes a copy of the actual object, it might) The protected trick works only once—the first

time you inherit from a class that has no cloneability and you want to make a class that’s cloneable In any classes inherited from your class the

clone( ) method is available since it’s not possible in Java to reduce the

access of a method during derivation That is, once a class is cloneable, everything derived from it is cloneable unless you use provided

mechanisms (described later) to “turn off” cloning Feedback

Implementing the Cloneable interface

There’s one more thing you need to do to complete the cloneability of an

object: implement the Cloneable interface This interface is a bit

strange, because it’s empty!

interface Cloneable {}

The reason for implementing this empty interface is obviously not because you are going to upcast to Cloneable and call one of its methods

The use of interface in this way is called a tagging interface because it

acts as a kind of flag, wired into the type of the class Feedback

There are two reasons for the existence of the Cloneable interface

First, you might have an upcast reference to a base type and not know whether it’s possible to clone that object In this case, you can use the

instanceof keyword (described in Chapter 10) to find out whether the

reference is connected to an object that can be cloned: Feedback

if(myReference instanceof Cloneable) //

The second reason is that mixed into this design for cloneability was the thought that maybe you didn’t want all types of objects to be cloneable So

Object.clone( ) verifies that a class implements the Cloneable

interface If not, it throws a CloneNotSupportedException exception

So in general, you’re forced to implement Cloneable as part of support

for cloning Feedback

Successful cloning

Once you understand the details of implementing the clone( ) method,

you’re able to create classes that can be easily duplicated to provide a local copy:

public MyObject(int n) { this.n = n; }

public Object clone() {

public int getValue() { return n; }

public void setValue(int n) { this.n = n; }

public void increment() { n++; }

public String toString() { return Integer.toString(n); } }

public class LocalCopy {

private static Test monitor = new Test();

public static MyObject g(MyObject v) {

// Passing a reference, modifies outside object:

v.increment();

return v;

}

public static MyObject f(MyObject v) {

v = (MyObject)v.clone(); // Local copy

v.increment();

return v;

}

public static void main(String[] args) {

MyObject a = new MyObject(11);

MyObject b = g(a);

// Reference equivalence, not object equivalence:

First of all, for clone( ) to be accessible you must make it public

Second, for the initial part of your clone( ) operation you should call the base-class version of clone( ) The clone( ) that’s being called here is the one that’s predefined inside Object, and you can call it because it’s

protected and thereby accessible in derived classes Feedback

Object.clone( ) figures out how big the object is, creates enough

memory for a new one, and copies all the bits from the old to the new

This is called a bitwise copy, and is typically what you’d expect a clone( )

method to do But before Object.clone( ) performs its operations, it first checks to see if a class is Cloneable—that is, whether it implements the Cloneable interface If it doesn’t, Object.clone( ) throws a

CloneNotSupportedException to indicate that you can’t clone it Thus, you’ve got to surround your call to super.clone( ) with a try

block, to catch an exception that should never happen (because you’ve

implemented the Cloneable interface) Feedback

In LocalCopy, the two methods g( ) and f( ) demonstrate the difference between the two approaches for argument passing g( ) shows passing by

reference in which it modifies the outside object and returns a reference

to that outside object, while f( ) clones the argument, thereby decoupling

it and leaving the original object alone It can then proceed to do whatever

it wants, and even to return a reference to this new object without any ill

effects to the original Notice the somewhat curious-looking statement: Feedback

v = (MyObject)v.clone();

This is where the local copy is created To prevent confusion by such a statement, remember that this rather strange coding idiom is perfectly feasible in Java because every object identifier is actually a reference So

the reference v is used to clone( ) a copy of what it refers to, and this returns a reference to the base type Object (because it’s defined that way

in Object.clone( )) that must then be cast to the proper type Feedback

In main( ), the difference between the effects of the two different

argument-passing approaches is tested It’s important to notice that the equivalence tests in Java do not look inside the objects being compared to

see if their values are the same The == and != operators are simply

comparing the references If the addresses inside the references are the

same, the references are pointing to the same object and are therefore

“equal.” So what the operators are really testing is whether the references are aliased to the same object! Feedback

The effect of Object.clone( )

What actually happens when Object.clone( ) is called that makes it so essential to call super.clone( ) when you override clone( ) in your class? The clone( ) method in the root class is responsible for creating

the correct amount of storage and making the bitwise copy of the bits from the original object into the new object’s storage That is, it doesn’t

just make storage and copy an Object—it actually figures out the size of

the real object (not just the base-class object, but the derived object)

that’s being copied and duplicates that Since all this is happening from

the code in the clone( ) method defined in the root class (that has no idea

what’s being inherited from it), you can guess that the process involves RTTI to determine the actual object that’s being cloned This way, the

clone( ) method can create the proper amount of storage and do the

correct bitcopy for that type Feedback

Whatever you do, the first part of the cloning process should normally be

a call to super.clone( ) This establishes the groundwork for the cloning

operation by making an exact duplicate At this point you can perform other operations necessary to complete the cloning Feedback

To know for sure what those other operations are, you need to understand

exactly what Object.clone( ) buys you In particular, does it

automatically clone the destination of all the references? The following example tests this:

//: appendixa:Snake.java

// Tests cloning to see if destination

// of references are also cloned

import com.bruceeckel.simpletest.*;

public class Snake implements Cloneable {

private static Test monitor = new Test();

private Snake next;

private char c;

// Value of i == number of segments

public Snake(int i, char x) {

Snake s = new Snake(5, 'a');

A Snake is made up of a bunch of segments, each of type Snake Thus,

it’s a singly linked list The segments are created recursively,

decrementing the first constructor argument for each segment until zero

is reached To give each segment a unique tag, the second argument, a

char, is incremented for each recursive constructor call Feedback

The increment( ) method recursively increments each tag so you can see the change, and the toString( ) recursively prints each tag From the

output, you can see that only the first segment is duplicated by

Object.clone( ), therefore it does a shallow copy If you want the whole

snake to be duplicated—a deep copy—you must perform the additional

operations inside your overridden clone( ) Feedback

You’ll typically call super.clone( ) in any class derived from a cloneable

class to make sure that all of the base-class operations (including

Object.clone( )) take place This is followed by an explicit call to

clone( ) for every reference in your object; otherwise those references

will be aliased to those of the original object It’s analogous to the way constructors are called—base-class constructor first, then the next-derived constructor, and so on to the most-derived constructor The difference is

that clone( ) is not a constructor, so there’s nothing to make it happen

automatically You must make sure to do it yourself Feedback

Cloning a composed object

There’s a problem you’ll encounter when trying to deep-copy a composed

object You must assume that the clone( ) method in the member objects

will in turn perform a deep copy on their references, and so on This is

quite a commitment It effectively means that for a deep copy to work you must either control all of the code in all of the classes, or at least have enough knowledge about all of the classes involved in the deep copy to know that they are performing their own deep copy correctly FeedbackThis example shows what you must do to accomplish a deep copy when dealing with a composed object:

//: appendixa:DeepCopy.java

// Cloning a composed object

// {Depends: junit.jar}

import junit.framework.*;

class DepthReading implements Cloneable {

private double depth;

public DepthReading(double depth) { this.depth = depth; } public Object clone() {

public double getDepth() { return depth; }

public void setDepth(double depth){ this.depth = depth; } public String toString() { return String.valueOf(depth);} }

class TemperatureReading implements Cloneable {

private long time;

private double temperature;

public TemperatureReading(double temperature) {

class OceanReading implements Cloneable {

private DepthReading depth;

private TemperatureReading temperature;

public OceanReading(double tdata, double ddata) {

temperature = new TemperatureReading(tdata);

depth = new DepthReading(ddata);

public String toString() {

return "temperature: " + temperature +

", depth: " + depth;

}

}

public class DeepCopy extends TestCase {

public DeepCopy(String name) { super(name); }

public void testClone() {

OceanReading reading = new OceanReading(33.9, 100.5); // Now clone it:

OceanReading clone = (OceanReading)reading.clone(); TemperatureReading tr = clone.getTemperatureReading(); tr.setTemperature(tr.getTemperature() + 1);

OceanReading is composed of DepthReading and

TemperatureReading objects and so, to produce a deep copy, its clone( ) must clone the references inside OceanReading To

accomplish this, the result of super.clone( ) must be cast to an

OceanReading object (so you can access the depth and temperature

references) Feedback

A deep copy with ArrayList

Let’s revisit Cloning.java from earlier in this appendix This time the Int2 class is cloneable, so the ArrayList can be deep copied:

//: appendixa:AddingClone.java

// You must go through a few gyrations

// to add cloning to your own class

import com.bruceeckel.simpletest.*;

import java.util.*;

class Int2 implements Cloneable {

private int i;

public Int2(int ii) { i = ii; }

public void increment() { i++; }

public String toString() { return Integer.toString(i); } public Object clone() {

// Inheritance doesn't remove cloneability:

class Int3 extends Int2 {

private int j; // Automatically duplicated

public Int3(int i) { super(i); }

}

public class AddingClone {

private static Test monitor = new Test();

public static void main(String[] args) {

Int2 x = new Int2(10);

Int2 x2 = (Int2)x.clone();

x2.increment();

System.out.println("x = " + x + ", x2 = " + x2);

// Anything inherited is also cloneable:

Int3 x3 = new Int3(7);

for(int i = 0; i < v.size(); i++)

v2.set(i, ((Int2)v2.get(i)).clone());

// Increment all v2's elements:

for(Iterator e = v2.iterator(); e.hasNext(); )

performs all of the necessary duplication, regardless of how far down in

the hierarchy clone( ) is defined Feedback

You can see what’s necessary in order to do a deep copy of an ArrayList: after the ArrayList is cloned, you have to step through and clone each one of the objects pointed to by the ArrayList You’d have to do

something similar to this to do a deep copy of a HashMap Feedback

The remainder of the example shows that the cloning did happen by showing that, once an object is cloned, you can change it and the original object is left untouched Feedback

Deep copy via serialization

When you consider Java’s object serialization (introduced in Chapter 12), you might observe that an object that’s serialized and then deserialized is,

in effect, cloned Feedback

So why not use serialization to perform deep copying? Here’s an example that compares the two approaches by timing them:

//: appendixa:Compete.java

import java.io.*;

class Thing1 implements Serializable {}

class Thing2 implements Serializable {

Thing1 o1 = new Thing1();

}

class Thing3 implements Cloneable {

public Object clone() {

class Thing4 implements Cloneable {

private Thing3 o3 = new Thing3();

public Object clone() {

public class Compete {

public static final int SIZE = 25000;

public static void main(String[] args) throws Exception { Thing2[] a = new Thing2[SIZE];

for(int i = 0; i < a.length; i++)

a[i] = new Thing2();

Thing4[] b = new Thing4[SIZE];

for(int i = 0; i < b.length; i++)

b[i] = new Thing4();

long t1 = System.currentTimeMillis();

ByteArrayOutputStream buf= new ByteArrayOutputStream(); ObjectOutputStream o = new ObjectOutputStream(buf); for(int i = 0; i < a.length; i++)

o.writeObject(a[i]);

// Now get copies:

ObjectInputStream in = new ObjectInputStream(

new ByteArrayInputStream(buf.toByteArray()));

Thing2[] c = new Thing2[SIZE];

for(int i = 0; i < c.length; i++)

Thing4[] d = new Thing4[SIZE];

for(int i = 0; i < d.length; i++)

duplication of objects is relatively simple The results are interesting Here

is the output from three different runs:

Duplication via serialization: 547 Milliseconds

Duplication via cloning: 110 Milliseconds

Duplication via serialization: 547 Milliseconds

Duplication via cloning: 109 Milliseconds

Duplication via serialization: 547 Milliseconds

Duplication via cloning: 125 Milliseconds

In earlier versions of the JDK, the time required for serialization was much longer than that of cloning (roughly 15 times slower), and the serialization time tended to vary a lot More recent versions of the JDK have sped up serialization and apparently made the time more consistent,

as well Here, it’s approximately four times slower, which brings it into the realm of reasonability for use as a cloning alternative Feedback

Adding cloneability

further down a hierarchy

If you create a new class, its base class defaults to Object, which defaults

to noncloneability (as you’ll see in the next section) As long as you don’t explicitly add cloneability, you won’t get it But you can add it in at any layer and it will then be cloneable from that layer downward, like this:

class Hero extends Person {}

class Scientist extends Person implements Cloneable {

public Object clone() {

class MadScientist extends Scientist {}

public class HorrorFlick {

public static void main(String[] args) {

Person p = new Person();

Hero h = new Hero();

Scientist s = new Scientist();

MadScientist m = new MadScientist();

//! p = (Person)p.clone(); // Compile error

//! h = (Hero)h.clone(); // Compile error

s = (Scientist)s.clone();

m = (MadScientist)m.clone();

}

} ///:~

Before cloneability was added in the hierarchy, the compiler stopped you

from trying to clone things When cloneability is added in Scientist, then Scientist and all its descendants are cloneable Feedback

Why this strange design?

If all this seems to be a strange scheme, that’s because it is You might wonder why it worked out this way What is the meaning behind this design? Feedback

Originally, Java was designed as a language to control hardware boxes, and definitely not with the Internet in mind In a general-purpose

language like this, it makes sense that the programmer be able to clone

any object Thus, clone( ) was placed in the root class Object, but it was

a public method so you could always clone any object This seemed to be

the most flexible approach, and after all, what could it hurt? Feedback

Well, when Java was seen as the ultimate Internet programming

language, things changed Suddenly, there are security issues, and of course, these issues are dealt with using objects, and you don’t necessarily want anyone to be able to clone your security objects So what you’re seeing is a lot of patches applied on the original simple and

straightforward scheme: clone( ) is now protected in Object You must

override it and implement Cloneable and deal with the exceptions

Feedback

It’s worth noting that you must implement the Cloneable interface only

if you’re going to call Object’s clone( ), method, since that method checks at run time to make sure that your class implements Cloneable But for consistency (and since Cloneable is empty anyway) you should

implement it Feedback

1 Indifference You don’t do anything about cloning, which means that your class can’t be cloned but a class that inherits from you can add cloning if it wants This works only if the default

Object.clone( ) will do something reasonable with all the fields in

your class Feedback

2 Support clone( ) Follow the standard practice of implementing Cloneable and overriding clone( ) In the overridden clone( ), you call super.clone( ) and catch all exceptions (so your

overridden clone( ) doesn’t throw any exceptions) Feedback

3 Support cloning conditionally If your class holds references to other objects that might or might not be cloneable (a container

class, for example), your clone( ) can try to clone all of the objects

for which you have references, and if they throw exceptions just pass those exceptions out to the programmer For example,

consider a special sort of ArrayList that tries to clone all the objects it holds When you write such an ArrayList, you don’t

know what sort of objects the client programmer might put into

your ArrayList, so you don’t know whether they can be cloned

Feedback

4 Don’t implement Cloneable but override clone( ) as protected,

producing the correct copying behavior for any fields This way,

anyone inheriting from this class can override clone( ) and call super.clone( ) to produce the correct copying behavior Note that your implementation can and should invoke super.clone( ) even though that method expects a Cloneable object (it will throw an

exception otherwise), because no one will directly invoke it on an

object of your type It will get invoked only through a derived class,

which, if it is to work successfully, implements Cloneable Feedback

5 Try to prevent cloning by not implementing Cloneable and

overriding clone( ) to throw an exception This is successful only if any class derived from this calls super.clone( ) in its redefinition

of clone( ) Otherwise, a programmer may be able to get around it

Feedback

6 Prevent cloning by making your class final If clone( ) has not

been overridden by any of your ancestor classes, then it can’t be If

it has, then override it again and throw

CloneNotSupportedException Making the class final is the

only way to guarantee that cloning is prevented In addition, when dealing with security objects or other situations in which you want

to control the number of objects created you should make all

constructors private and provide one or more special methods for

creating objects That way, these methods can restrict the number

of objects created and the conditions in which they’re created (A

particular case of this is the singleton pattern shown in Thinking in

Patterns with Java at www.BruceEckel.com.) Feedback

Here’s an example that shows the various ways cloning can be

implemented and then, later in the hierarchy, “turned off”: Feedback

// Overrides clone, but doesn't implement Cloneable:

class WrongClone extends Ordinary {

public Object clone() throws CloneNotSupportedException { return super.clone(); // Throws exception

}

}

// Does all the right things for cloning:

class IsCloneable extends Ordinary implements Cloneable { public Object clone() throws CloneNotSupportedException {

return super.clone();

}

}

// Turn off cloning by throwing the exception:

class NoMore extends IsCloneable {

public Object clone() throws CloneNotSupportedException { throw new CloneNotSupportedException();

}

}

class TryMore extends NoMore {

public Object clone() throws CloneNotSupportedException { // Calls NoMore.clone(), throws exception:

return super.clone();

}

}

class BackOn extends NoMore {

private BackOn duplicate(BackOn b) {

// Somehow make a copy of b and return that copy

// This is a dummy copy, just to make the point:

return new BackOn();

}

public Object clone() {

// Doesn't call NoMore.clone():

return duplicate(this);

}

}

// You can't inherit from this, so you can't override

// the clone method as you can in BackOn:

final class ReallyNoMore extends NoMore {}

public class CheckCloneable {

private static Test monitor = new Test();

public static Ordinary tryToClone(Ordinary ord) {

Ordinary x = new Ordinary();

// This won't compile; clone() is protected in Object: //! x = (Ordinary)x.clone();

// Checks first to see if a class implements Cloneable: for(int i = 0; i < ord.length; i++)

The first class, Ordinary, represents the kinds of classes we’ve seen

throughout this book: no support for cloning, but as it turns out, no

prevention of cloning either But if you have a reference to an Ordinary

object that might have been upcast from a more derived class, you can’t tell if it can be cloned or not Feedback

The class WrongClone shows an incorrect way to implement cloning It does override Object.clone( ) and makes that method public, but it doesn’t implement Cloneable, so when super.clone( ) is called (which results in a call to Object.clone( )), CloneNotSupportedException

is thrown so the cloning doesn’t work Feedback

IsCloneable performs all the right actions for cloning: clone( ) is overridden and Cloneable is implemented However, this clone( )

method and several others that follow in this example do not catch

CloneNotSupportedException, but instead pass it through to the

caller, who must then put a try-catch block around it In your own

clone( ) methods you will typically catch

CloneNotSupportedException inside clone( ) rather than passing it

through As you’ll see, in this example it’s more informative to pass the exceptions through Feedback

Class NoMore attempts to “turn off” cloning in the way that the Java designers intended: in the derived class clone( ), you throw

CloneNotSupportedException The clone( ) method in class

TryMore properly calls super.clone( ), and this resolves to

NoMore.clone( ), which throws an exception and prevents cloning

Feedback

But what if the programmer doesn’t follow the “proper” path of calling

super.clone( ) inside the overridden clone( ) method? In BackOn,

you can see how this can happen This class uses a separate method

duplicate( ) to make a copy of the current object and calls this method

inside clone( ) instead of calling super.clone( ) The exception is never

thrown and the new class is cloneable You can’t rely on throwing an exception to prevent making a cloneable class The only sure-fire solution

is shown in ReallyNoMore, which is final and thus cannot be inherited That means if clone( ) throws an exception in the final class, it cannot

be modified with inheritance and the prevention of cloning is assured

(You cannot explicitly call Object.clone( ) from a class that has an arbitrary level of inheritance; you are limited to calling super.clone( ),

which has access to only the direct base class.) Thus, if you make any

objects that involve security issues, you’ll want to make those classes

final Feedback

The first method you see in class CheckCloneable is tryToClone( ), which takes any Ordinary object and checks to see whether it’s cloneable with instanceof If so, it casts the object to an IsCloneable, calls

clone( ) and casts the result back to Ordinary, catching any exceptions

that are thrown Notice the use of run-time type identification (see

Chapter 10) to print the class name so you can see what’s happening Feedback

In main( ), different types of Ordinary objects are created and upcast to Ordinary in the array definition The first two lines of code after that create a plain Ordinary object and try to clone it However, this code will not compile because clone( ) is a protected method in Object The

remainder of the code steps through the array and tries to clone each object, reporting the success or failure of each Feedback

So to summarize, if you want a class to be cloneable: Feedback

1 Implement the Cloneable interface

2 Override clone( )

3 Call super.clone( ) inside your clone( )

4 Capture exceptions inside your clone( )

This will produce the most convenient effects Feedback

The copy constructor

Cloning can seem to be a complicated process to set up It might seem like there should be an alternative One approach is to use serialization, as shown earlier Another approach that might occur to you (especially if you’re a C++ programmer) is to make a special constructor whose job it is

to duplicate an object In C++, this is called the copy constructor At first,

this seems like the obvious solution, but in fact it doesn’t work Here’s an example:

//: appendixa:CopyConstructor.java

// A constructor for copying an object of the same

// type, as an attempt to create a local copy

import com.bruceeckel.simpletest.*;

import java.lang.reflect.*;

class FruitQualities {

private int weight;

private int color;

private int firmness;

private int ripeness;

private int smell;

public Seed() { /* Default constructor */ }

public Seed(Seed s) { /* Copy constructor */ }

for(int i = 0; i < seeds; i++)

s[i] = new Seed();

}

// Call all Seed copy-constructors:

for(int i = 0; i < seeds; i++)

s[i] = new Seed(f.s[i]);

// Other copy-construction activities

}

// To allow derived constructors (or other

// methods) to put in different qualities:

protected void addQualities(FruitQualities q) {

public Tomato(Tomato t) { // Copy-constructor

super(t); // Upcast for base copy-constructor

// Other copy-construction activities

}

}

class ZebraQualities extends FruitQualities {

private int stripedness;

public ZebraQualities() { // Default constructor