Two Laptop Bag*
The moose likes Beginning Java and the fly likes How do Interfaces reveal Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "How do Interfaces reveal "interfaces?"" Watch "How do Interfaces reveal "interfaces?"" New topic
Author

How do Interfaces reveal "interfaces?"

justin mcsporran
Greenhorn

Joined: May 12, 2003
Posts: 15
A bit of a *retentive question, but here goes:
In a basic Java text I'm reading, it says that one of the uses of Interfaces is to "Reveal an object's programming interface without revealing the actual body of the class (useful when shipping a package of classes to other developers.)."
My question is: How is the "programming interface" revealed by an Interface?
If I'm handed a bunch of class files (no src code) without associated javadocs or a decompiler, I can't imagine what tool/technique would tell me what methods these classes would have (irrespective of whether they're Interfaces or concrete classes).
Have I missed (or not yet learned) something that would reveal these methods, or am I confusing the semantics in the quoted text?
Thanks,
Justin
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi Justin,
Welcome to JavaRanch.
My question is: How is the "programming interface" revealed by an Interface?
I think what the author is getting at here is that all methods of an interface are public and therefore accessible, so in a way an interface "reveals" the methods of a concrete object. In other words, if you know all the methods avaialable in the interface, then you know how to interact with any class that implements the interface.
If I'm handed a bunch of class files (no src code) without associated javadocs or a decompiler, I can't imagine what tool/technique would tell me what methods these classes would have (irrespective of whether they're Interfaces or concrete classes).

You should demand the javadocs. You can "reveal" everything in a class programatically with reflection or by using javap to decompile the class files, but that couldn't be the intent of whoever provided you with the class files in the first place.


Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Donald R. Cossitt
buckaroo
Ranch Hand

Joined: Jan 31, 2003
Posts: 401
On the other hand, if one attempted to compile a class implementing those interfaces, the compiler would give you a detailed laundry list of methods and their params immediately after telling you yourClass should be abstract. A real tough way to find out but then, if all you had were class files and no other info... :roll:


doco
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
On the other hand, if one attempted to compile a class implementing those interfaces, the compiler would give you a detailed laundry list of methods and their params immediately after telling you yourClass should be abstract. A real tough way to find out but then, if all you had were class files and no other info...
Good point Doco. Has that ever happened to you?
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Justin, your confusion is understandable, and I don't know if I agree at all with the statement in the book.
They seem to suggest that when you ship a package to other developers, being able to ship the source of an interface implemented by your classes is a Good Thing[tm], as you won't have to ship the source to the class itself. I can't see any reason for this. As Michael says, you should demand the javadocs for API documentation.
The main use for interfaces has to do with implementation, not with documentation: it allows you to develop against an API without knowing anything about the classes that happen to implement it. This has advantages both for the package you ship and the developers that use the package API:
  • The developers are discouraged to make assumptions about the specific classes you use to implement stuff. In other words, it encourages a more loosely coupled design. This gives you much more freedom in the implementation of your package: if the functionality you're implementing needs it, you can use totally different classes which don't even share a common parent class (apart from java.lang.Object of course) and your client developers won't even know the difference. Or perhaps your package evolves and you're refactoring its internals, completely turning the structure upside down: as long as the interface is implemented correctly, clients won't know the difference.
  • Conversely, if your code uses interfaces rather than classes internally then you don't care where the implementations come from. Client developers can write their own implementation. The Java Collections API is full of great examples; for instance, Collections.sort(List) works with any implementation of the List interface, not just with the implementations from the Collections framework itself (ArrayList, LinkedList, Vector).
  • Does that help?
    - Peter
    justin mcsporran
    Greenhorn

    Joined: May 12, 2003
    Posts: 15
    Once again, the high calibre of posters and moderators here is proved. Many thanks for all your helpful words. The fog is beginning to lift.
    - Justin
    Thomas Paul
    mister krabs
    Ranch Hand

    Joined: May 05, 2000
    Posts: 13974
    Peter, what about when you are working with RMI or EJB? Don't you (as the client-side developer) get an interface which reveals the programming interface wihout revealing anything about the implementing class?
    I think the authors did mangle the statement a bit. JDBC is a good example, I think, of what I think the authors are trying to say. I don't even need to know the name of the class that implements Connection, for example, in order to use the class because I use the implementation exposed by the Connection interface.


    Associate Instructor - Hofstra University
    Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
    Peter den Haan
    author
    Ranch Hand

    Joined: Apr 20, 2000
    Posts: 3252
    Originally posted by Thomas Paul:
    Peter, what about when you are working with RMI or EJB? Don't you (as the client-side developer) get an interface which reveals the programming interface wihout revealing anything about the implementing class?
    Sure? How does that affect what I said above?
    The same is necessarily true for anything else that uses proxies to insert a layer (of management, transport or whatever) on top of your objects. In my eyes, this has nothing to do with "shipping a package of classes to other developers" and everything with interfaces allowing a more loosely-coupled design that allows such insertions.
    I did perhaps misread the authors' statement though.
    - Peter
    [ May 21, 2003: Message edited by: Peter den Haan ]
    Thomas Paul
    mister krabs
    Ranch Hand

    Joined: May 05, 2000
    Posts: 13974
    Originally posted by Peter den Haan:
    I did perhaps misread the authors' statement though.

    The more I look at the statement the more I agrre that the authors screwed it up.
    "Reveal an object's programming interface without revealing the actual body of the class."
    Well no, actually. That sounds more like a definition of encapsulation.
     
    Consider Paul's rocket mass heater.
     
    subject: How do Interfaces reveal "interfaces?"