RE: Understanding Implements -- JAVA400-L

To follow up on the Airplane vs Automobile thought. I have my application up
and running. Now someone wants a totally new class that can also use the
GenerateSounds program. By implementing Noisable and coding a blareItOut()
method in this new class, I can use the GenerateSounds program without any
changes to it.

Think if you had a shipping program that accepted a Vector of OrderDetail
objects. What if you wanted to use the same program for shipping marketing
materials but didn't want to make a change to your Sales Order system to
accomodate transactions that really weren't sales orders. If OrderDetail
implemented Shippable and MarketingDetail implemented Shippable and the
shipping program accepted a Vector of Shippable objects, you could use the
same shipping program for orders or marketing materials. It also means you
can easily use it for other things very easily.

Interfaces provide for a deeper encapsulation than data or behavior. It
really encapsulates (read hides) implementation. You are actually hiding the
type of object it is. Anything you can hide, you can easily change!

To take it a step farther, OrderDetail is an abstract class. The concrete
classes are FinishedGoodItem and DropShipItem. Most of the data and methods
are implemented in the class OrderDetail, but a few have to be implemented
in the subclasses because it is specific to thier nature [like
calcAvailableToShipDate()]. The Vector of OrderDetail objects are actually
FinishedGoodItem objects and/or DropShipItem objects. Users of the
OrderDetail don't have to know which, they use them interchangably. Yet they
behave differently. I need to add another kind of item. I create a new
class, extend OrderDetail and implement only that which makes it unique. All
programs except the one that interfaces with the database use OrderDetail
unchanged.

That's the benefit of abstraction, inheritance, encapsulation and
polymorphism.

Joe Teff

-----Original Message-----
From: owner-java400-l@midrange.com
[mailto:owner-java400-l@midrange.com]On Behalf Of John Taylor
Sent: Wednesday, March 21, 2001 5:34 PM
To: JAVA400-L@midrange.com
Subject: Re: Understanding Implements


Buck,

In the given example, without the interface you would be forcing a class
relationship between GenerateSounds() and Airplane(). Let's look at Joel's
example:

public class GenerateSounds {
    public static void blareItOut( Noiseable obj ) {
        obj.makeSound();

In the context of a method parameter, the Noisable interface above is being
used as a reference data type so that blareItOut() can operate on any object
that provides the method(s) of a Noisable device. Let's see what happen's if
you don't have a noisable interface:

public class GenerateSounds {
    public static void blareItOut( Airplane obj ) {
        obj.makeSound();

Now, the original example will still work, as long as you're passing it an
F-14 Tomcat, but what happens when you want to hear the sound of a 12
cylinder Dodge Viper? See the dilemna? In order to accomplish the cast,
you're going to need to impose an unnecessary object hierarchy upon your
design where Airplane and Automobile are both subclasses of a more
generic --most likely abstract-- "NoiseMaker" object. So now you're right
back to:

public class GenerateSounds {
    public static void blareItOut( NoiseMaker obj ) {
        obj.makeSound();

Except you've lost a lot of flexibility because you've had to force a class
hierarchy.

I'll leave you with one final thought; interfaces are also useful for
exposing an object's programming interface without revealing its class.
These are usually known as anonymous objects, and can be useful when
shipping a package of classes to other developers.


HTH,

John Taylor
Canada

----- Original Message -----
From: "Buck Calabro" <buck.calabro@aptissoftware.com>
To: <JAVA400-L@midrange.com>
Sent: Wednesday, March 21, 2001 13:41
Subject: RE: Understanding Implements


> I'm working toward the "ah-HA!" here, and I deeply appreciate the
discussion
> to date...
>
> I'm missing the advantage of the extra layer of abstraction involved in
> using interface Noisable.  Since every class that implements Noisable will
> be required to have a makeSound() method anyway, what does the empty
> interface bring to the table?
>
> If this is way too "newbie" tell me to go away and read some more.  I will
> do the right thing, I promise!
>
> Buck
>
> > -----Original Message-----
> > From: Joe Teff
> > Sent: Wednesday, March 21, 2001 10:20 AM
> > To: JAVA400-L@midrange.com
> > Subject: RE: Understanding Implements
> >
> > The following is an interface, stored in a .java source file and
compiled
> > the same as classes:
> >
> > public interface Noisable {
> >    public void makeSound();
> > }
> >
> > Notice that the method only contains the signature and no
implementation.
> > Methods in an interface are abstract. The interface only requires that
you
> > supply the method(s) listed. There is no inheritence here.
> >
> > This class will implement that interface:
> >
> > public class Airplane implements Noisable {
> >    // various methods and data
> >    public void makeSound() {
> >       // code to here to make airplane noise
> >    }
> > }
> >
> > This class will not compile unless I code all methods listed in the
> > interface, hence the "contract" reference.
> >
> > Now lets make an application that generates sounds:
> >
> > public class GenerateSounds {
> >    public static void blareItOut( Noiseable obj ) {
> >       obj.makeSound();
> >    }
> > }
> >
> > I can call GenerateSounds.blareItOut(xxx) where xxx is an object created
> > from any class that implements Noisable. The actual code to make the
noise
> > is coded into each class's makeSound() method, thus each one will do it
> > slightly different. blareItOut() doesn't care how the code works, it
just
> > cares that the appropriate method is there. It doesn't even care what
kind
> > of object (class) it even is. The only thing it knows is that it has to
> > have a makeSound() method that it can call.
> >
> > Joe Teff


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---