Re: Java "interface" vs. OO interface

From: Thomas G. Marshall (tgm2tothe10thpower_at_hotmail.replaceTextWithNumber.com)
Date: 11/13/03 

Date: Thu, 13 Nov 2003 21:40:40 GMT

Costin Cozianu <c_cozianu@hotmail.com> coughed up the following:

> Thomas G. Marshall wrote:
>
>> This is a beginner question for the OO purists in this group,
>> because I've often wondered if java made a mistake here (let's not
>> let this descend into a stack of all of java's mistakes).
>>
>> For this discussion "interface" will mean "java's interface", and
>> OO-interface will mean the general OO term /interface/.
>>
>> Java has a facility called literally the "interface", which as
>> expected allows me to establish part of an object's contract:
>>
>> public interface ChildInterface
>> {
>> public void runs(int reason, int speed);
>> public void sleeps(int seconds);
>> }
>>
>> I could then /implement/ this interface as such:
>>
>> public class DwightSchmidlap implements ChildInterface
>> {
>> public void runs(int reason, int speed)
>> { ....... }
>>
>> public void sleeps(int seconds)
>> { ....... }
>>
>> public void somethingelse() // not in interface
>> { ....... }
>> }
>>
>> And use the interface in variable /declarations/ where the actual
>> implementing classes are used in the variable /definition/:
>>
>> ChildInterface[] kids = {new DwightSchmidlap(), new Henry(), ...}
>>
>> ...if DwightSchmidlap and Henry both implemented the interface.
>> Because of /kids/ declaration I'm only able to access the members of
>> the interface:
>>
>> kids[0].runs(....)
>> kids[0].sleeps(...)
>>
>> and not:
>>
>> kids[0].somethingelse(); // error. In underlying class, but
>> not declaration.
>>
>> Fairly trivial. This is nothing you wouldn't expect.
>>
>>
>>
>> Now here's my complaint, and perhaps it's ok with you.
>>
>> The java interface allows me to specify constants in that interface.
>>
>> public interface ChildInterface
>> {
>> public static final int REASON_SCARED = 0;
>> public static final int REASON_HAPPY = 1;
>> public void runs(int reason, int speed);
>> public void sleeps(int seconds);
>> }
>>
>> ...in this case to provide potential values for the runs() method.
>>
>> There are other things allowable in interfaces, which I'm not going
>> into here, I want to keep this focused.
>>
>> The problem I have with this approach is that it allows fully
>> UNqualified access to any of the constants names anywhere downwind
>> of the interface implementation.
>>
>> public class MyClass extends
>> SomeOtherClassThatImplementedChildInterface {
>> public void bang()
>> {
>> runs(REASON_SCARED, 5.0);
>> laterReason = REASON_HAPPY;
>> }
>> public int laterReason;
>> }
>>
>> Fully unqualified! (Yuck). This can (AND DOES) routinely cause
>> headaches as people throw time away trying to figure out where
>> things are defined, especially if the interface is implemented near
>> the top of a large hierarchy.
>>
>> Question: Even if java /required/ a qualified access to reach the
>> constants:
>>
>> runs(ChildInterface.REASON_SCARED, 5.0);
>>
>> does it violate the notion of the OO-interface to have the java
>> interface allow constants within it? And if not, is that so either
>> way: constants related to the contract of the class and not related
>> at all?
>>
>> Thanks,
>>
>> Thomas
>>
>>
>
> Thomas,
>
> Any Java thingie (either class or interface) allows itself to be used
> as
> a namespace. This is indeed non-idiomatic java and I think is more a
> side effect of other design decision, but I really like to use it.

Sure. Me too.

> For your question as to where it is defined, if you really want it,
> bring over the mouse cursor and let it hang, a tip will show you the
> value, You can also right click and say "open declaration", it will
> take
> you to the declaration. That's in Eclipse IDE, most IDEs have this
> feature. So it is not like you cannot find your way around because of
> this thing.
>
> Now I've used the namespace provided by interfaces for stuff even more
> complicated than constants. For example, the factories, why should I
> have both the interface and the Factory in the top namespace.
>
> I enjoy putting the factory as a static class inside the interface.

Sure.

I, similarly, have no problem with interface embedded hand-made
compile-time-type-safe enums (prior to jdk1.5) for very similar usages
(typing on the fly here, so forgive me :) ) for parameter definition e.g.:

    public interface TrafficLiteInterface
    {
        public static class TrafficLiteColor
        {
            public static TrafficLiteColor RED = new TrafficLiteColor();
            public static TrafficLiteColor GREEN = new TrafficLiteColor();
            public static TrafficLiteColor BLUE = new TrafficLiteColor();
        }
    }

But I'd personally rather see that as a static inner class (to a class):

    public class TrafficLite
    {
        public static class Color
        {
            public static TrafficLiteColor RED = new TrafficLiteColor();
            public static TrafficLiteColor GREEN = new TrafficLiteColor();
            public static TrafficLiteColor BLUE = new TrafficLiteColor();
        }
    }

    //...a long time ago, in a class far, far away...
    elmStreetLite.changeTo(TrafficLite.Color.RED);

For me, I suppose it simply "feels" as if constants (for whatever reason)
are forms of data, and data belongs in a class. And I like very much that
the qualified access can only be circumvented by that /other/ dumb java
idea:

    import com.tgm.TrafficLite.*;

...but that's a grumble for a different group.

> I happen to have an example handy:
> http://www.c2.com/cgi/wiki?DiningPhilosophersChallenge
>
> I make similar use of a class namespace in a refactoring pattern, I
> posted recently (criticisms encouraged and welcome):
> http://www.c2.com/cgi/wiki?EmulateKeywordAndDefaultParameters
>
> Now the great idea (or it seems to me that way) is that there are
> really
> a lot of auxiliary classes (like factories, method objects, Runnables)
> that are merely mechanism of doing a trick (for example factories
> supplant the lack of virtual constructors, or method objects are
> another trick to supplant the lack of proper functions. They are not
> and should
> not be considered part of the proper object model. As such I want them
> to stay hidden from the main view. When I open the package to see the
> package elvel classes, or when I list the files in the directory I
> only
> want to see names that tell me what's all about (the concepts in the
> domain model), I don't want this view to be polluted with all the
> auxiliaries and implementation details. That's why I hide them in the
> namespace of the class that they serve. It is also possible that I'll
> have class within a class within a class, and not even blink about it.

I'm a very big fan of the clarity that can come from inner classes.

But IMHO It's really a better idea to not stretch the name space of the
constant downwind the entirety of the hierarchy it is part of, which is what
happens the moment implement an interface. Everything below the point of
implementation has unqualified access to it.

The same thing happens when you define a non-private inner class (everything
below it has access to it), but that would be within the hierarchy.
Interface constants and static classes can be dragged into /any/ other class
hierarchy that exists, no matter how disparate.

> In response to your concerns I'd say that there are symbolic names for
> constants that need to fine the best namespaces to stay (it's not only
> about objects, namespaces and visibility are also important). And form
> this perspective, I'd say that the best namespace can be the interface
> that they relate to.

That seems to be the prevailing attitude over the years. I remain worried
about it, hence my quest to see what is considered OO (not java) esthetic.