Java Reference
In-Depth Information
For a class to be serializable, all its data members must be either serializable or declared as
transient
. If
this is not the case, then an exception of type
NotSerializableException
is thrown when you try to seri-
alize an object. To avoid this, you must trawl through the data members of the
SketcherModel
class and
make sure they either implement the
Serializable
interface or are declared as
transient
.
You cannot assume that objects of a standard class type are serializable, because some most definitely are
not. It's a fairly quick fishing trip though, because the
SketcherModel
class has only one data member —
the linked list of elements that make up the sketch. If the
SketcherModel
object is to be serializable, you
simply need to make sure the
elements
field is serializable.
Serializing the List of Elements
If you look through the JDK documentation, you'll see that the
LinkedList<>
generic class implements the
Serializable
interface, so all you need to worry about are the elements you store in the list.
Class fields of any of the basic types are always serializable. The data members of our
Element
class that
are object references are of types
java.awt.Color
,
java.awt.Point
, and
java.awt.Rectangle
. You can
verify from the JDK documentation that all three classes are serializable, so our
Element
class is serializ-
able. Now you need to look at the subclasses of
Element
.
Subclasses of
Element
inherit the implementation of the
Serializable
interface, so they are all declared
to be serializable by default. All of the concrete classes in the
java.awt.geom
package that implement the
java.awt.Shape
interface are already serializable, as is the
java.awt.Font
field in the
Element.Text
class. All the other fields in the classes that define sketch elements are of basic types. This means that
all
the
sketch element types are serializable without any further effort on your part, so writing a sketch to a file is
going to be fairly trivial.
BASIC INFRASTRUCTURE FOR SAVING
SKETCHES
Putting in place the graphical user interface functionality for saving a sketch on disk and reading it back
from a file is significantly more work than implementing serialization for the model. The logic of opening
and saving files so as not to lose anything accidentally can get rather complex. Before you get into that, there
are some fundamental points that need to be addressed.
For starters, a sketch doesn't have a name. You should at least make provision for assigning a file name
to a sketch, and maybe displaying the name of the current sketch in the title bar of the application window.
You also need ways to record the file name for a sketch and the directory where it is stored. Let's name that
sketch first.
Assigning a Document Name
The sketch is going to have a name, and because you intend to store it somewhere, let's define a default dir-
ectory to hold sketches. Add the following lines to the end of the
SketcherConstants
class that you defined
in the
Constants
package:
