[ Pobierz całość w formacie PDF ]
.Animal@\\w+\\], c11.House@\\w+","%%, Fronk the cat" +"\\[c11.Animal@\\w+\\], c11.House@\\w+","]","%%animals3: \\[Bosco the dog" +"\\[c11.Animal@\\w+\\], c11.House@\\w+","%%, Ralph the hamster" +"\\[c11.Animal@\\w+\\], c11.House@\\w+","%%, Fronk the cat" +"\\[c11.Animal@\\w+\\], c11.House@\\w+","]"});}} ///:~One thing that’s interesting here is that it’s possible to use object serialization to and from a byte array as a way of doing a “deep copy” of any object that’s Serializable.(A deep copy means that you’re duplicating the entire web of objects, rather than just the basic object and its references.) Copying is covered in depth in Appendix A.Animal objects contain fields of type House.In main( ), an ArrayList of these Animals is created and it is serialized twice to one stream and then again to a separate stream.When these are deserialized and printed, you see the following results for one run (the objects will be in different memory locations each run):animals: [Bosco the dog[Animal@1cc76c], House@1cc769, Ralph the hamster[Animal@1cc76d], House@1cc769, Fronk the cat[Animal@1cc76e], House@1cc769]animals1: [Bosco the dog[Animal@1cca0c], House@1cca16, Ralph the hamster[Animal@1cca17], House@1cca16, Fronk the cat[Animal@1cca1b], House@1cca16]animals2: [Bosco the dog[Animal@1cca0c], House@1cca16, Ralph the hamster[Animal@1cca17], House@1cca16, Fronk the cat[Animal@1cca1b], House@1cca16]animals3: [Bosco the dog[Animal@1cca52], House@1cca5c, Ralph the hamster[Animal@1cca5d], House@1cca5c, Fronk the cat[Animal@1cca61], House@1cca5c]Of course you expect that the deserialized objects have different addresses from their originals.But notice that in animals1 and animals2 the same addresses appear, including the references to the House object that both share.On the other hand, when animals3 is recovered the system has no way of knowing that the objects in this other stream are aliases of the objects in the first stream, so it makes a completely different web of objects.As long as you’re serializing everything to a single stream, you’ll be able to recover the same web of objects that you wrote, with no accidental duplication of objects.Of course, you can change the state of your objects in between the time you write the first and the last, but that’s your responsibility—the objects will be written in whatever state they are in (and with whatever connections they have to other objects) at the time you serialize them.The safest thing to do if you want to save the state of a system is to serialize as an “atomic” operation.If you serialize some things, do some other work, and serialize some more, etc., then you will not be storing the system safely.Instead, put all the objects that comprise the state of your system in a single container and simply write that container out in one operation.Then you can restore it with a single method call as well.The following example is an imaginary computer-aided design (CAD) system that demonstrates the approach.In addition, it throws in the issue of static fields—if you look at the documentation you’ll see that Class is Serializable, so it should be easy to store the static fields by simply serializing the//: c11:CADState.java// Saving and restoring the state of a// pretend CAD system.package c11;import com.bruceeckel.simpletest.*;import java.io.*;import java.util.*;abstract class Shape implements Serializable {public static final intRED = 1, BLUE = 2, GREEN = 3;private int xPos, yPos, dimension;private static Random r = new Random();private static int counter = 0;abstract public void setColor(int newColor);abstract public int getColor();public Shape(int xVal, int yVal, int dim) {xPos = xVal;yPos = yVal;dimension = dim;}public String toString() {return getClass() +" color[" + getColor() +"] xPos[" + xPos +"] yPos[" + yPos +"] dim[" + dimension + "]\n";}public static Shape randomFactory() {int xVal = r.nextInt() % 100;int yVal = r.nextInt() % 100;int dim = r
[ Pobierz całość w formacie PDF ]