Re: Java "interface" vs. OO interface

• Previous message: Myles: "Re: Programming Language Productivity: The Stupidity of Programmers"
• In reply to: Thomas G. Marshall: "Java "interface" vs. OO interface"
• Next in thread: Thomas G. Marshall: "Re: Java "interface" vs. OO interface"
• Reply: Thomas G. Marshall: "Re: Java "interface" vs. OO interface"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Thu, 13 Nov 2003 12:11:08 -0800

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.

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.

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.

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.

Best,
Costin

• Previous message: Myles: "Re: Programming Language Productivity: The Stupidity of Programmers"
• In reply to: Thomas G. Marshall: "Java "interface" vs. OO interface"
• Next in thread: Thomas G. Marshall: "Re: Java "interface" vs. OO interface"
• Reply: Thomas G. Marshall: "Re: Java "interface" vs. OO interface"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]