Java Reference
In-Depth Information
}
}
An attribute must have a name, so each
Attr
constructor requires a
name parameter. The name must be immutable (and so is marked
fi-
nal
) because it may be used, for example, as a key into a hashtable or
sorted list. In such a case, if the
name
field were modified, the attribute
object would become "lost" because it would be filed under the old
name, not the modified one. Attributes can have any type of value, so
the value is stored in a variable of type
Object
. The value can be changed
at any time. Both
name
and
value
are
private
members so that they can
be accessed only via the appropriate methods. This ensures that the
contract of
Attr
is always honored and allows the designer of
Attr
the
freedom to change implementation details in the future without affect-
ing clients of the class.
Every class you have seen so far is an extended class, whether or not it
is declared as such. A class such as
Attr
that does not explicitly extend
another class implicitly extends the
Object
class.
Object
is at the root of
the class hierarchy. The
Object
class declares methods that are imple-
instance or an array. The
Object
class itself is described in more detail
on page
99
.
The next class extends the notion of attribute to store color attributes,
which might be strings that name or describe colors. Color descriptions
might be color names like "red" or "ecru" that must be looked up in a
table, or numeric values that can be decoded to produce a standard,
more efficient color representation we call
ScreenColor
(assumed to be
defined elsewhere). Decoding a description into a
ScreenColor
object is
expensive enough that you would like to do it only once. So we extend
the
Attr
class to create a
ColorAttr
class to support a method to retrieve
a decoded
ScreenColor
object. We implement it so the decoding is done
only once: