twc
Posts: 129
Nickname: twc
Registered: Feb, 2004
|
|
Re: Private Inner Class Question
|
Posted: Mar 5, 2004 4:38 PM
|
|
> First off, it makes sense to me that the line below would > compile because the left side of the expression is defined > as "Contents" (which is a public interface). > > > Contents c = p.cont();
>
c is actually an PContents object since the method returns a PContents object. Since the PContents class implements the Contents interface, c can also be considered to be a Contents object. At this point in the code, the compiler only realizes that c is a Contents object.
An analogy might be if Sue Smith marries John Jones, she is considered both a Smith and a Jones. (Why we rarely think of men as being both is another issue.) If you see her at a Smith family reunion, you would know she is a Smith (but might not know whether that is by blood or marriage). Ditto if she's at the Jones reunion.
Any class that implements a particular interface can be considered an object of that type. For example, the Integer, Double, and String class all implement the Comparable interface. Therefore they can all be considered Comparable objects as well as objects of their own type. > However, I don't understand how this line compiles... > > > System.out.println("c.value() = "+ c.value());
>
> > Why would the compiler let someone call a method from an > interface unless there was a downcast?? Below is the way > that I would have EXPECTED the call would HAVE to be > made...
What an interface does is guarantee that certain methods exist. For example, all Comparable objects are required to have an int method named compareTo(Object o) and a boolean method named equals(Object o). These methods must work in a fashion specified by the interface.
The Contents interface probably requires that the value() method return an int value. If that is the case, then the compiler knows that all Contents objects have a value() method and have no reason not to compile this code.
On the other hand, suppose that the PContents class had another method called foo() that was NOT required by the Contents interface. Then c.foo() would cause a compiler error since the compiler (at this point in the code) only knows that c is a Contents object (which wouldn't be guaranteed to have a foo() method). > > ((Parcel3.PContents) c).value();
>
> > I realize that that WOULDN'T compile because > Parcel3.PContents is a private class and, thus, there > would be no access. But, that's why I don't understand > why this thing works to begin with.
Ignoring the private class issue, the beauty of Interfaces is that you DON'T have typecast! While you can't compare Integers to Strings, even though both are Comparable objects, you know that both have certain characteristics.
That makes a method such as what I have below possible.
public Comparable[] sort(Comparable[] array)
{
//code to sort the array
}
Such a method could sort an array of Strings, then sort an array of Integers, because both use the Comparable interface which guarantees that the objects will have a compareTo method that determines if the given objects value is less than, greater than, or equal to the parameter objects value.
You cannot sort a mixed array (since you can't compare Strings to Integers), but it allows the method to be reusable.
I hope this helps.
twc
|
|