1

I read a lot about interfaces in java. I know you can achieve polymorphism and other great stuff (function pointers..etc). I have theoretical knowledge but pratical a little or even none. I have been using a lot of already made interfaces like "Runnable" or lots of "Listeners". But still I don't understand them 100%. If someone will answer following question maybe I will get a better understanding:

So recently I'm learning about LibGdx and I've come across Interface called "Disposable". It has one method called "dispose()" and documentation for this method says;

Releases all resources of this object.

So I assume this interface is declared like this:

public interface Disposable { 

public void dispose();

}

And I have a class which implements this interface.

public class Main implements Disposable {

@Override
    public void dispose() {
        // TODO Auto-generated method stub

    }
 }

The question: How can this method do something when called if it's empty? It cannot dispose anything ..

I could have my own method in this class who would dispose objects. Why we need interface for this?

This is just an example. I've come across for a lot of similar interfaces.

I really can't understand Interfaces like this one.

Cœur
  • 37,241
  • 25
  • 195
  • 267
rootpanthera
  • 2,731
  • 10
  • 33
  • 65

6 Answers6

1

Possible reasons for your use case:

  1. You might later change the implementation of the class and actually need to dispose something. Client code should not have to change.
  2. This class might be part of a large array or collection of various things, many of which do need to be disposed. Allows more uniform code.
  3. All client code should need to do is call dispose. This is useful in a garbage collector pattern, so that you can do garbageCollector.collect(disposable). This would make sense if the interface were a part of some GarbageCollector package.
  4. Sometimes language features make use of implemented methods. try-with-resources does - it only needs close and requires a AutoCloseable, see here for comparison.
Community
  • 1
  • 1
djechlin
  • 59,258
  • 35
  • 162
  • 290
1

The reason is that if you have another object's method that takes a type Disposable, it is expecting (indeed requiring) that the method specified by the interface exists. Likely because it will call that method somewhere.

In this way, you can have multiple classes that implement Disposable (each in their own way), and then you can pass instances of that class by their Disposable interface, which will expose whatever methods the interface specifies. And the class getting the instance of Disposable can depend on that method being there.

Greg Jennings
  • 1,611
  • 16
  • 25
1

Often Libraries provide interfaces so you can extend the interface rather than changing internal code. this will keep the compatibility of code which is using the library.

Providing empty implementation is up to developer , but in the interface documentation they provide what should be the actual implementation of the concrete class which implements the interface.

Muhannad A.Alhariri
  • 3,702
  • 4
  • 30
  • 46
0

The problem is, you may have many different types of of objects all of whom want to be disposed. Now, you could write yourself a nice series of if-else statements, trying to determine if the given Object is an instance of some other type of object so you can determine how it should be disposed (and what methods it would take to trigger it) or you could, as you have here, define a common interface that all objects wishing to be disposed at some time can use.

This means you can then refer to each of this different objects based on this single common interface allowing them to all appear as instances Disposable, this is the cornerstone of polymorphism.

This means with nothing more than a list of Disposable objects, you can quickly and easily call the dispose method of each. The caller doesn't care how this is implemented, only that when it is called, the required contract is carried out...

MadProgrammer
  • 343,457
  • 22
  • 230
  • 366
0
There is a term in Java "Coding to Interfaces".

Check the link:
http://stackoverflow.com/questions/1970806/coding-to-interfaces

Coding to an interface rather than to implementation. This makes your software/application easier to extend. In other words, your code will work with all the interface’s subclasses, even ones that have not been created yet.
Anytime if you are writing code that interacts with subclasses, you have two choices either; your code directly interacts with subclasses or interacts with interface. Like this situation, you should always favor/prefer to coding to an interface, not the implementation.
To use the interface one can simply call the methods on an instance of the concrete class.

One would call the methods on a reference of the type interface, which happens to use the concrete class as implementation:

List<String> l = new ArrayList<String>();
l.add("foo");
l.add("bar");
If you decided to switch to another List implementation, the client code works without change:

List<String> l = new LinkedList<String>();
This is especially useful for hiding implementation details, auto generating proxies, etc.

Advantages

App/Software is easier to extend
Adds Flexibility to your App.
Helps to maintain the loose coupling of code.
Sambhav
  • 217
  • 2
  • 16
0

Interface is just like prototype for your class. It's purpose is to provide a structure to your class.

If your class is implementing any interface, that means that class must declare all the property (i.e. method) defined in interface. It can be thought of as adjective to your class.

Like if you have two classes i.e. Eagle and Parrot. Then you should create an interface named canFly. Now the Eagle and Parrot can fly but the way they are flying can be different. That's why the interface doesn't have the declaration.

Ankita P.
  • 478
  • 10
  • 21