chap01.htm

Thinking in Java, 2nd edition

[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I25' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I26>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">So the first reason for access control is
to keep client programmers&#8217; hands off portions they shouldn&#8217;t
touch&#8212;parts that are necessary for the internal machinations of the data
type but not part of the interface that users need in order to solve their
particular problems. This is actually a service to users because they can easily
see what&#8217;s important to them and what they can
ignore.
</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I26' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I27>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The second reason for access control is
to allow the library designer to change the internal workings of the class
without worrying about how it will affect the client programmer. For example,
you might implement a particular class in a simple fashion to ease development,
and then later discover that you need to rewrite it in order to make it run
faster. If the interface and implementation are clearly separated and protected,
you can accomplish this
easily.<A NAME="Index61"></A><A NAME="Index62"></A><A NAME="Index63"></A>
</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I27' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I28>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Java uses three explicit keywords to set
the boundaries in a class: <B>public</B>, <B>private</B>, and <B>protected</B>.
Their use and meaning are quite straightforward. These <I>access specifiers</I>
<A NAME="Index64"></A><A NAME="Index65"></A><A NAME="Index66"></A>determine who
can use the definitions that follow. <B>public</B> <A NAME="Index67"></A>means
the following definitions are available to everyone. The <B>private</B>
<A NAME="Index68"></A>keyword, on the other hand, means that no one can access
those definitions except you, the creator of the type, inside member functions
of that type. <B>private</B> is a brick wall between you and the client
programmer. If someone tries to access a <B>private</B> member, they&#8217;ll
get a compile-time error. <A NAME="Index69"></A><B>protected</B> acts like
<B>private</B>, with the exception that an inheriting class has access to
<B>protected</B> members, but not <B>private</B> members. Inheritance will be
introduced shortly.
</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I28' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I29>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Java also has a &#8220;default&#8221;
access, which comes into play if you don&#8217;t use one of the aforementioned
specifiers. This is sometimes called &#8220;friendly&#8221; access because
classes can access the friendly members of other classes in the same package,
but outside of the package those same friendly members appear to be
<B>private</B>.
</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I29' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I30>
</FONT><A NAME="_Toc375545191"></A><A NAME="_Toc408018388"></A><A NAME="_Toc472654685"></A><A NAME="_Toc481064470"></A><BR></P></DIV>
<A NAME="Heading25"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
Reusing the implementation</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Once a class has been created and tested,
it should (ideally) represent a useful unit of code. It turns out that this
<A NAME="Index70"></A>reusability is not nearly so easy to achieve as many would
hope; it takes experience and insight to produce a good design. But once you
have such a design, it begs to be reused. Code reuse is one of the greatest
advantages that object-oriented programming languages
provide.
</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I30' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I31>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The simplest way to reuse a class is to
just use an object of that class directly, but you can also place an object of
that class inside a new class. We call this &#8220;creating a
<A NAME="Index71"></A><A NAME="Index72"></A>member object.&#8221; Your new class
can be made up of any number and type of other objects, in any combination that
you need to achieve the functionality desired in your new class. Because you are
composing a new class from existing classes, this concept is called
<A NAME="Index73"></A><I>composition</I> (or more generally,
<A NAME="Index74"></A><I>aggregation</I>). Composition is often referred to as a
&#8220;<A NAME="Index75"></A>has-a&#8221; relationship, as in &#8220;a car has
an engine.&#8221;
</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I31' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I32>
</FONT><BR></P></DIV>
<DIV ALIGN="CENTER"><FONT FACE="Georgia"><IMG SRC="TIJ204.gif"></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">(The above <A NAME="Index76"></A>UML
diagram indicates composition with the filled diamond, which states there is one
car. I will typically use a simpler form: just a line, without the diamond, to
indicate an
association.</FONT><A NAME="fnB5" HREF="#fn5">[5]</A><FONT FACE="Georgia">)
</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I32' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I33>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Composition comes with a great deal of
flexibility. The member objects of your new class are usually private, making
them inaccessible to the client programmers who are using the class. This allows
you to change those members without disturbing existing client code. You can
also change the member objects at run-time, to dynamically change the behavior
of your program. Inheritance, which is described next, does not have this
flexibility since the compiler must place compile-time restrictions on classes
created with inheritance.
</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I33' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I34>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Because inheritance is so important in
object-oriented programming it is often highly emphasized, and the new
programmer can get the idea that inheritance should be used everywhere. This can
result in awkward and overly complicated designs. Instead, you should first look
to composition when creating new classes, since it is simpler and more flexible.
If you take this approach, your designs will be cleaner. Once you&#8217;ve had
some experience, it will be reasonably obvious when you need
inheritance.
</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I34' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I35>
</FONT><A NAME="_Toc375545192"></A><A NAME="_Toc408018389"></A><A NAME="_Toc472654686"></A><A NAME="_Toc481064471"></A><BR></P></DIV>
<A NAME="Heading26"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
Inheritance:<BR>reusing the interface</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">By itself, the idea of an object is a
convenient tool. It allows you to package data and functionality together by
<I>concept</I>, so you can represent an appropriate problem-space idea rather
than being forced to use the idioms of the underlying machine. These concepts
are expressed as fundamental units in the programming language by using the
<A NAME="Index77"></A><A NAME="Index78"></A><B>class</B>
keyword.
</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I35' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I36>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">It seems a pity, however, to go to all
the trouble to create a class and then be forced to create a brand new one that
might have similar functionality. It&#8217;s nicer if we can take the existing
class, clone it, and then make additions and modifications to the clone. This is
effectively what you get with <A NAME="Index79"></A><I>inheritance</I>, with the
exception that if the original class (called the <I>base</I> or <I>super</I> or
<I>parent</I> class) is changed, the modified &#8220;clone&#8221; (called the
<I>derived </I>or <I>inherited</I> or <I>sub</I> or <I>child</I><B> </B>class)
also reflects those
changes.
</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I36' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I37>
</FONT><BR></P></DIV>
<DIV ALIGN="CENTER"><FONT FACE="Georgia"><IMG SRC="TIJ205.gif"></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">(The arrow in the above UML diagram
points from the derived class to the base class. As you will see, there can be
more than one derived
class.)
</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I37' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I38>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">A type does more than describe the
constraints on a set of objects; it also has a relationship with other types.
Two types can have characteristics and behaviors in common, but one type may
contain more characteristics than another and may also handle more messages (or
handle them differently). Inheritance expresses this similarity between types
using the concept of <A NAME="Index80"></A><A NAME="Index81"></A>base types and
<A NAME="Index82"></A><A NAME="Index83"></A>derived types. A base type contains
all of the characteristics and behaviors that are shared among the types derived
from it. You create a base type to represent the core of your ideas about some
objects in your system. From the base type, you derive other types to express
the different ways that this core can be
realized.
</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I38' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I39>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">For example, a trash-recycling machine
sorts pieces of trash. The base type is &#8220;trash,&#8221; and each piece of
trash has a weight, a value, and so on, and can be shredded, melted, or
decomposed. From this, more specific types of trash are derived that may have
additional characteristics (a bottle has a color) or behaviors (an aluminum can
may be crushed, a steel can is magnetic). In addition, some behaviors may be
different (the value of paper depends on its type and condition). Using
inheritance, you can build a type hierarchy that expresses the problem
you&#8217;re trying to solve in terms of its
types.
</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I39' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I40>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">A second example is the classic
&#8220;<A NAME="Index84"></A>shape&#8221; example, perhaps used in a
computer-aided design system or game simulation. The base type is
&#8220;shape,&#8221; and each shape has a size, a color, a position, and so on.
Each shape can be drawn, erased, moved, colored, etc. From this, specific types
of shapes are derived (inherited): circle, square, triangle, and so on, each of
which may have additional characteristics and behaviors. Certain shapes can be
flipped, for example. Some behaviors may be different, such as when you want to
calculate the area of a shape. The type hierarchy embodies both the similarities
and differences between the
shapes.
</backtalk:display>
[&nbsp;<a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I40' 
  target="_blank">Add&nbsp;Comment</a>&nbsp;]

<backtalk:display ID=TIJ3_CHAPTER1_I41>
</FONT><BR></P></DIV>
<DIV ALIGN="CENTER"><FONT FACE="Georgia"><IMG SRC="TIJ206.gif"></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Casting the solution in the same terms as
the problem is tremendously beneficial because you don&#8217;t need a lot of
intermediate models to get from a description of the problem to a description of
the solution. With objects, the type hierarchy is the primary model, so you go
directly from the description of the system in the real world to the description