javax.swing.JApplet
If you create a class that extends JApplet for example, then your
class is asubclass of JApplet, which in turn is a subclass of Applet,
which in turn is a subclass
of Panel. I think you get the picture. The domino effect starts at the
top
and pyramids down in this specific hierarchy. We know the methods that
are
provided in the Object class.eg, ToString etc.. Coming down the
hierarchy, methods are
either overridden, overloaded, or newly created. Bottom line is that
your new class
has a whole lot of capabilities (methods) before you actually even code
one of your own.
A class in the hierarchical structure of java only has one parent. But a
parent has
a parent that has a parent etc.
Many classes implement interfaces, which in turn have respective
supporting
partial implementations (abstract classes) already written (to help
you). The domino
effect that I have described also applies to interfaces implemented and
respective
abstract classes within the hierarchy.
If you go to the above link, and start clicking on the different
parts of the structure
noted above, you will see how a specific class is a subclass of the one
above, how it has its own subclasses, and a list of interfaces that are
involved.
Spend some time doing what I just said and you will feel comfortable
about
the hierarchical structure of java and how your specific class fits into
the bigger picture.
By the way, if you create an object within your class of a specific type
(class), the
hierarchical rules apply to that object also. NOT the rules just
discussed above for an
extension of the Japplet class, but another set dictated by where that
specific class
existed in its own hierarchical structure in the java framework of its
package.
This material is important because once you understand the structure
of the
packages and where you class is inserted (extended) or where your new
object lies in
the structure then you will see the real power of casting ,
polymorphism, and the use of
interfaces to bring together objects of different hierarchies for the
sake of analysis.
Remember that references to objects can be stored in variables or
passed as parameters of
any type as long as the new type is an ancestor of this class in the
hierarchical
line and that includes the interfaces.. Obviously only the methods that
exist in this new class type, or above in the hierarchy, can be invoked
on
this reference variables. By exist I mean either they were inherited in,
originally implemented there, or declared as Abstract
THE MOST IMPORTANT PART OF THIS RULE IS..."If any of these
methods are
implemented in the original subclass THEN THE ORIGINAL METHOD IS BOUND
TO
THE OBJECT EVEN THOUGH IT ID STORED IN A REFERENCE VARIABLE HIGHER UP IN
THE HIERARCHAL CHAIN. THIS SINGLE CONCEPT IS CRITICAL TO THE USE OF
INTERFACES AND ADVANCED JAVA PROGRAMMING ESPECIALLY INVOLVING ABSTRACT
CLASSES."
Remember our example of the Animal class that had 3 subclasses --
dog, cat, etc. Remember that references to these subclass objects were
stored in an Animal reference variable ( more specifically an array).
When we invoked the Speak method on the Animal reference variable,
(which contained a reference to one of the 3 subclasses) the appropriate
method respective to that animal (dog, cat, etc) was invoked. (dynamic
method binding). The Speak method
existed in the Animal class and was declared ABSTRACT. It was
implemented in the
dog, cat, etc. classes.
There are thousands of hierarchical combination in the varying java
packages. For example