-2

I've been trying to learn Java and trying to really understand it and how it works. I was able to understood what an interface was (or so I think). I've also seen some examples with them... BUT I haven't been able to understand how some interfaces have methods that you implement, and they already come with some kind of functionality... aren't you supposed to write that functionality every time you implement that method?

To give some kind of example, there's LibGDX, a very well-known library for game developing in Java. Your application class has to implement a interface that has methods like "render()". When you write your application you put all the stuff related to rendering in the "render()" method... but how does it knows what to do with that, if it's just an interface which only defines the name and return type of render()?

Sorry for my english, and thank you.

EDIT: Thanks for your answers, yes I am kind of new in this... so well I get confused, you've been really helpful!.

  • 1
    What more do you need to call a method than a method signature? – Boris the Spider Jul 29 '14 at 22:56
  • What's the "it" in "how does it knows what to do with that"? Can you give a specific reason it wouldn't know what to do? There are a large number of possible answers, depending on what "it" is and why you think it shouldn't be able to do what it does. – user2357112 Jul 29 '14 at 22:58
  • W[hat](http://stackoverflow.com/questions/444245/how-will-i-know-when-to-create-an-interface?rq=1) do you really know about how lib[rar](http://docs.oracle.com/javase/tutorial/java/concepts/interface.html)ies work? – Unihedron Jul 29 '14 at 22:59
  • It(LibGDX) doesn't know. It just calls an object that implements that interface. You have to create a class that implements the interface, and the code to do what you need to do in its render() method. – nos Jul 29 '14 at 23:07
  • Follow a Java wiki book or some Oracle Java tutorials before you start game programming. – bhathiya-perera Jul 29 '14 at 23:09
  • Thanks for the answers! Just to clarify. What I mean is how do they refer to that render() method, and for example write all the OpenGL stuff that goes on when the render method is called, they surely don't do it in the interface cause there you only define the method, don't you?. Again, I'm kind of new to this, and I shouldn't be getting into libGDX but the interfaces were something I never really understood, apart from It's basic definition. – DarkBoulevard Jul 29 '14 at 23:28
  • Check out the answer I left you, it contains a good link reference to help you understand interfaces alongside my answer – Juxhin Jul 29 '14 at 23:29
  • Hey, realised you haven't checked an answer yet. It's good practice around here to select an answer once you get your desired result in regards to your question. Goodluck! – Juxhin Aug 04 '14 at 21:25

4 Answers4

1

Using your example, when your class implements an interface, the framework knows an instance of your class has a render() method, so the framework can call it when it needs to.

The framework doesn't need to know (or care) what class the instance is, and especially what super classes it may be inherited from. Nor does it care what the method does.

Further, referring to objects in the most abstract way is best practice, and in java an interface is the most abstract type (because it puts no restriction on class hierarchy) - see Liskov substitution principle for more on this concept.

This arrangement gives great flexibility to how you may implement your code.

Bohemian
  • 412,405
  • 93
  • 575
  • 722
1

Interfaces can definitely be challenging concept to understand. Sometimes you need to know in advance that some method will exist on a given type. LIke in your case the LibGDX has a render method. The LibGDX at some point needs to call a render method but LibGDX doesn't know how that method is implemented, it just knows that it needs to call render. So, they say please implement this interface and tell us how to render. Then when we get around to calling the render() we will make sure that it gets called at the right time and invokes your code.

Perhaps this could be said another way. Sometimes when you use other software they do lots of work for you. At some point though you have to find a way to hook into the service that they provide. By implementing that interface you provide an implementation for the render() and they are nice enough to call it for you at the right time so that the rendering can take place.

Interfaces allow for polymorphism. Essentially, the LibGDX can call the render() on anything that implements their interface. Because you have implemented their interface their code know knows that a render() must exist on the class. The reason that this is polymorphic is because many different codebases will implement the interface and provide their own custom implementation of render and again LibGDX will happily invoke their method and run their implementation of that method.

Hope that helps!

user2122031
  • 581
  • 5
  • 11
1

Interfaces


Think of an interface as a collection of abstract methods. So this special class may be implemented inside my other classes. So that it inherits it's methods.

Think of it as a child class signing a contract with this parent class and promising that it will follow the same behavior as the interface. OTHERWISE, it'll have to declare itself as an abstract class(That's a whole other question to tackle).

In Java we are not allowed to extend multiple classes(as opposed to C#) in order to keep things simple. We are however, allowed to implement as many interfaces as we need.

To give you an example, what do Apples, Oranges, Blueberries have in common? They are all fruit, thus to 'force' them to have the same characteristics I create a Fruit interface, like so:

interface Fruit {
   public void name();
   public void colour();
}

And then implement them in my Apple class:

public class Apple implements Fruit{
  public void name(){
    System.out.println("Apple");
  }

  public void colour(){
    System.out.println("Red");
  }
}

So that Apple.java is forced to use the name() and colour() method and thus we will never come across an Apple object which doesn't have both name and colour!


Hope to have cleared it up


Also, I do recommend checking - Tutorials Point

As they post rather clear tutorials. For future reference, I highly recommend you search on StackOverflow for answers prior to posting your question as it will lead to alot of negative votes!

Juxhin
  • 5,068
  • 8
  • 29
  • 55
0

It doesn't. An interface is simply a contract. To Java, this means that if a concrete Object exists which implements that interface, it will have implementations of the methods defined in the contract.

A simple example should help demonstrate:

ExampleInterface.java

public interface ExampleInterface {
    int operation(int a, int b);
}

ExampleAddition.java - implements the interface using addition as the operation.

public class ExampleAddition implements ExampleInterface {
    @Override
    public int operation(int a, int b) {
        return a+b;
    }
}

ExampleSubtraction.java - implements the interface using subtraction as the operation.

public class ExampleSubtraction implements ExampleInterface {
    @Override
    public int operation(int a, int b) {
        return a-b;
    }
}

ExampleMain.java - Contains anonymous inner class which uses multiplication as the operation.

public class ExampleMain {
    public static void main(String[] args) {
        ExampleInterface first = new ExampleAddition();
        ExampleInterface second = new ExampleSubtraction();
        ExampleInterface third = new ExampleInterface() {
            @Override
            public int operation(int a, int b) {
                return a*b;
            }
        };

        System.out.println(first.operation(10,5));
        System.out.println(second.operation(10,5));
        System.out.println(third.operation(10,5));
    }
}

So what's the point of all this? Well the point is that all interface implementations are interchangeable, and you can use whichever you fancy. Now clearly in this example it's not particularly useful. It's more useful if you have for instance a data access object, and you want to use different technologies to access your data layer. You might want to have a hibernate implementation in production, and plain old JDBC implementation for local development, and a Mockito version for testing. This can all be done, because they share a common interface, they are effectively drop-in replacements for each other. In libGDX however I suspect there will only ever be one implementation, but it still must comply to the same contract. This let's them write a game loop that works independently of your concrete implementation.

Mikkel Løkke
  • 3,710
  • 23
  • 37