File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes Interfaces Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Interfaces" Watch "Interfaces" New topic
Author

Interfaces

Phil Hopgood
Ranch Hand

Joined: Jul 14, 2008
Posts: 47
Hi All,

An idiot question about interfaces:

If I have the following (please excuse my bad pseudo code):



The eat() method appears in the superclass Animal and in both the interfaces.

I got a bit confused about all these eat() methods.

Am I right in saying that Snarkle overrides the eat() method in Animal and implements it's own eat() method (because it's got to, to meet the interface contracts) and that it doesn't matter that a Pet eats like a pet and that a Human eats like a human because as you are defining how a Snarkle eats you should know how it does that? Is that right?

or does this imply that there should be a new interface called "MythicalCreature" which has a contract for mythical creature behaviour and that Snarkle should just implement that interface alone?

or should Animal not have an eat() method since this seems to be part of a specific animal's behaviour ....... I think, like many analogies, I'm taking this too far but I hope you understand what I'm asking.

Thanks in advance for any help you can give.

Regards,
Phil.

[edit]Add code tags. CR[/edit]
[ July 21, 2008: Message edited by: Campbell Ritchie ]
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36514
    
  16
Originally posted by Phil Hopgood:
An idiot question
Read the heading for "Java in General (beginner). It says "no question too small or simple."

Please use the code button (and use ctrl-c ctrl-v for real code); it makes it much easier to read. I have edited your post, so you can see the improvement.

Write "public abstract" rather than "abstract public." Also you need to specify return types for the methods in the interfaces, presumably void.

Your interfaces can specify methods with the same signature, and you can implement several interfaces with methods with the same signature, as long as these two conditions are fulfilled:
  • They have the same return type.
  • They have the same intention for their functionality.
  • I am not sure exactly how strict those two rules are; you would have to try and see what compiles, and also read the Java Language Specification (not for the fainthearted).
    I think the compiler will happily compile Snarkle, with or without the MythicalCreature interface. Whether you can have a creature which is half Human and half Pet, and extends the Animal class. . . That is a design problem, and I wouldn't let one of those out in real life, but if it's just an exercise to see what happens and you know it's conceptually odd . . .




    why not?

    Phil Hopgood
    Ranch Hand

    Joined: Jul 14, 2008
    Posts: 47
    Thanks for that Campbell.

    I'll use code tags from now on.

    Yeah this was an "I wonder what happens if" exercise .... my mind shooting off in an odd direction ...... should have noticed about the return types and the "public abstract" thing .... I'll get there in the end!

    ... and, no, I'm not intending to have a Snarkle as a pet or a life partner!

    Phil.
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 36514
        
      16
    Originally posted by Phil Hopgood:
    Thanks for that Campbell.
    ... and, no, I'm not intending to have a Snarkle as a pet or a life partner!

    Phil.
  • 1: You're welcome.
  • 2: "life partner" The mind boggles
  • Rob Spoor
    Sheriff

    Joined: Oct 27, 2005
    Posts: 19544
        
      16

    Originally posted by Phil Hopgood:
    (because it's got to, to meet the interface contracts)

    Actually it doesn't need to implement eat - it already inherits a valid implementation from Animal. By implementing an interface it is required that the method is present - either by implementing it or by inheriting it.

    As for the duplicate eat methods: it needs only one implementation since both signatures match. There will only be a problem if one of them says you need to do something, and the second says you can't do that thing. In other words, if they contradict each other.

    If for instance, Human.eat specifies that the object should use a knife and fork, and Pet.eat specifies that only claws and teeth can be used, you will have to violate either contract.


    SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
    How To Ask Questions How To Answer Questions
    Phil Hopgood
    Ranch Hand

    Joined: Jul 14, 2008
    Posts: 47
    Thanks for that Rob.

    However it has left me a little confused.

    It makes sense to me that if a class implements an interface and one of the methods required by the interface contract is inherited from a superclass then the contract is fulfilled, so I'm ok with that ..... I'll try it out in a moment.

    What confuses me is what you were saying about conflict and violating the contracts when the same method is required by two different interfaces, viz: the eat() method in the Human and Pet interfaces. As far as I am aware (and I hope you'll correct me if I get this wrong) an interface merely states the method signatures that are required for any class that cares to implement it. The interface says nothing about the functionality of that implementation and has no executable method code. So Human.eat() has no meaning, is that right?

    Obviously my example is somewhat contrived and was concocted to help me visualize what happens when you have the same method signatures in a pseudo multiple inheritance situation. If you were really trying to create a Snarkle and it's eating habits were a cross between Human and Pet then you might want to create a "MythicalCreature" interface I guess. That's why, in my original post, I wondered if, when you get a situation like this, it was inappropriate to use Human AND Pet and that it implied that you need a new, different interface.

    Thanks once again Rob, hope you can help me untangle my understanding here,

    Regards,
    Phil.
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 36514
        
      16
    I seem to have beaten Rob to it.

    The name interface was chosen because each class presents a "public interface" to the outside world. That public interface consists of the methods and any public fields. Well, let's get rid of public fields, because they are not consistent with information hiding. So we have the public methods. Your Animal class would present a public face to the world which looks like this:The easiest way to find what the public face of a class is, go to the command line and run "javadoc Animal.java". This creates html files which when opened look like those in the Sun API, only smaller.
    Now, if you have an interface like this . . .. . . you can run javadoc on that too, and you get the same result. You have a simple interface with one method, just like the java.lang.Comparable<T> interface (only you don't need the <T> generic formal parameter). Now go and compare the length of your javadoc html and the Comparable. What's the difference? It is in the documentation comments. You can work out what they say by reading the html, or you can find a document called src.zip in your Java installation folder. Unzip src.zip, and navigate to java.lang.Comparable (go to the java folder, then lang folder), and you can read the original.

    When you say that a class implements Comparable, you are adding the Comparable interface to its public interface, which means you need to find something which corresponds to the method in Comparable. Comparable has only one method, but there are other interfaces with many methods (eg this one with about 186).

    It means that when you read "implements FooInterface" on an API document, that you can go to the FooInterface definition and work out which methods you can rely on finding in the class, and also what each of them is supposed to do. You could argue that your "eat" methods in Animal, Pet and Human all do something similar, and anyway we have decided we don't care at the moment.
    If you say "implements Pet" the compiler will look for a method with the same signature as in Pet. If you say "implements Human" the compiler will look for a method with the same signature as in Human. If you say "extends Animal" the eat method from Animal is copied into Snarkle, unless you override it. You could say Snarkle implements Hungry as well.

    By the way: If using Java 5 or Java 6 preface your overridden methods with "@Override" which helps catch obscure spelling errors at compile-time.

    Look at the Collection interface, and its add(E) method. You see its description is rather vague. That is intentional, in order that other interfaces, eg Set and List which both extend Collection, can re-describe add differently.
    ****************************************************************************
    I said the Comparable interface explains exactly what is supposed to happen when you implement it. What about this interface?Notice the similarity to the java.lang.Comparable<T> interface, and the subtle difference. Now tell me how you are going to code this class Does that explain the problem of different interfaces?
    Phil Hopgood
    Ranch Hand

    Joined: Jul 14, 2008
    Posts: 47
    Oh man ........ I think I've got it but I'll have to think about that to be sure!

    Thanks for your response, Campbell, I'll get back to you.

    Regards,
    Phil.
    Phil Hopgood
    Ranch Hand

    Joined: Jul 14, 2008
    Posts: 47
    OK, I've thought about it.

    I guess what you're saying is it's not good enough to just whack a couple of interfaces onto the Snarkle class and hope that the eat() method inherited from Animal and the eat() methods required to fulfill the contracts for the Human, Pet and Hungry interfaces are in some way mutually compatible.

    You need to understand how each eat() method was intended to work and how it relates to what you want it to do in the Snarkle class. That the contract with an interface is not just the method signatures but the intended functionality..... if a Snarkle eats with his/her teeth and claws then this would violate the "spirit" of the Human eat() method because this requires that you eat with a knife and fork but it might meet the requirements of the Pet interface, say. Is that what you mean?

    But am I correct in saying that all the compiler will check is that an eat() method with the correct arguments and return type exists in Snarkle? I'm assuming that it's up to the programmer to ensure that his/her implementation does what was intended in the interface, that it's a matter of convention/trust. Is that right?

    Sorry to be so dense and thanks.
    Regards,
    Phil.
    Joanne Neal
    Rancher

    Joined: Aug 05, 2005
    Posts: 3169
        
      10
    Originally posted by Phil Hopgood:
    But am I correct in saying that all the compiler will check is that an eat() method with the correct arguments and return type exists in Snarkle? I'm assuming that it's up to the programmer to ensure that his/her implementation does what was intended in the interface, that it's a matter of convention/trust. Is that right?


    That's right. To look at an existing example. The Map interface has a put method defined in it which allows you to add a key/value pair to the Map. It's an optional method, but part of the contract for that method (see the Javadoc) is
    If the map previously contained a mapping for the key, the old value is replaced by the specified value.
    Suppose that you create a class that implements the Map interface and supports the put() method. Obviously the signature of the method will be correct (otherwise it wouldn't compile), but suppose that your method, instead of replacing an existing value with a new value, simply ignored the new value and kept the old one. Your class will compile without problem, but it will not fully comply with the contract of the Map interface and if someone used your class they would get unexpected results.
    [ July 22, 2008: Message edited by: Joanne Neal ]

    Joanne
    Phil Hopgood
    Ranch Hand

    Joined: Jul 14, 2008
    Posts: 47
    Thanks Joanne and the rest of you guys, I think I've got it now.
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 36514
        
      16
    Originally posted by Phil Hopgood:
    Thanks Joanne and the rest of you guys, I think I've got it now.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Interfaces
     
    Similar Threads
    need of abstract class/interfaces?
    Inheritance and Polymorphism
    interface & abstract class code question
    Advantages of overloading abstract methods