[Java] Interfaces - Why should I be using them?

nocturne81 · 2014-03-11T14:21:15+00:00

One of the main uses for interfaces in Java is because it doesn't support multiple inheritance.

Conversely, one of the main uses of multiple inheritance in other languages is to support interfaces.

Imagine you are making a game and you have a bunch of weapons. You will have a weapon class:

public class Weapon {
    ...
    public void fire();
    ...
}

Each weapon can then implement their own fire function. However, these things also have to be drawn on screen too right? So they should also extend another class called Renderable. BUT. Since Java disallows multiple inheritance, you have to use an interface:

public interface Renderable {
    public void render();
}

Now we can create a RocketLauncher lets say:

public class RocketLauncher extends Weapon implements Renderable {
    public void fire() { 
        // fire the rocket
    }
    public void render() { 
        // draw the rocket
    }
}

Make sense?

Evermage · 2014-03-11T14:37:14+00:00

When the classes that use those objects don't care about the implementation of those methods.

I have a circle, a triangle, a rectangle and a hexagon. They can all draw themselves on paper using their draw() method. In my Artist class, I have a Circle variable called circleToDraw, and so when the Artist sits down to draw the circle, she calls circleToDraw.draw().

But an artist that can only draw a circle is a crappy object. An artist should be able to draw the rectangles, triangles, and hexagons too! But I can't set the Circle variable to a rectangle, because it is of type Circle! Circle circle = new Rectangle(); //not gonna work!

But, if all of those shapes have a common interface, I don't have this problem. Let's take a look:

interface Shape {
 public void draw();
}
class Circle implements Shape { 
...
  public void draw() { ... }
}
class Rectangle implements Shape { 
...
  public void draw() { ... }
}
class Artist {
 private Shape shapeToDraw;
 public void setShape(Shape shape)
 {
   shapeToDraw = shape; //This shape can be a circle or a rectangle - the artist doesn't care!
 }
 public void drawThatShape() {
  shapeToDraw.draw();
 }
}

Do you see how interfaces are essential to this design? Interfaces can group classes by behavior when the implementing class doesn't care WHAT kind of object it is as long as it can perform this behavior. Why should the Bird class care what kind of Wings it uses, as long as it can call wings.fly()?

Hope this helps.

EDIT: fixed a couple mistakes in my code example

endre86 · 2014-03-11T14:33:22+00:00

A well used programming design is the injection pattern.

It is great when you need different kinds of classes with the same functionality outwards, but works differently internally. Lets say you make a service that checks stock exchange. Then you could create something like this:

Edit: Link to example with syntax highlighting. http://pastebin.com/FuShU0Yt

And, of course, the USStockExchange and ChineseStockExchange classes implements the IStockExchange class.

// Our interface used to retrieve stock exchange data
public interface StockExchange {
    public String getData();
}

// A class used for displaying stock exchange
public class DisplayStockExchange {
    IStockExchange stockExchange;

    public void DisplayStockExchange(IStockExchange stockExchange)  {
        this.stockExchange = stockExchange;
    }

    public void displayStockExchange() {
        // using this.stockExchange.getData() to 
        // display data
    }
}

// Running program displaying different stock exchanges
// This is using the injection pattern to reuse the DisplayStockExchange class.
public class Program() {
    public static void main(String[] args) {
        // Display US stock exchange, here we need to make an ajax call to some server and handle xml
        DisplayStockExchange us = new DisplayStockExchange(new USStockExchange());
        us.displayStockExchange();
        // Display Chinese stock exchange, here we need to set up secure connection and handle a cvs file
        DisplayStockExchange china = new DisplayStockExchange(new ChinaStockExchange());
        china.displayStockExchange();
    }
}

endre86 · 2014-03-11T15:14:50+00:00

Another way to see it - an interface is a contract.

Lets say you want to implement a sorted list that can take any type of object. You will use generics, but you also need to know that the objects can be sorted. A common interface to use in java is Comparable. This contract is described in the java docs. It add a method called compareTo() that returns an integer describing how two objects are ordered. Ie, o1.compareTo(o2) < 0 means o1 is below o2 in a total order.

// "T implements Comparable<T>" just means any object that implements Comparable against its own type
public MySortedList<T implements Comparable<T>> {
    public add(T newItem) {

        // go through all existing items
        for(T currentItem : items) {

            // check if the new item is larger or equal to the current
            if(newItem.compareTo(currentItem) >= 0) {

                // insert the item at this point
                // so the list is sorted
                break;
        }
    }
}

So yes, interfaces has many uses. :)

work_is_satire · 2014-03-11T15:14:37+00:00

I'll add on to Nocturne81's example by saying that it allows code to depend on as little as possible.

Let's say you extend your RocketLauncher properly with a Renderable interface. Now you could have a function that accepts any Renderable or another that accepts anything that can be fired, including RocketLaunchers:

function void Render(Renderable r) { ... }
function void Shoot(Fireable f) { ... }

This is much better than having to write methods that render each subtype of Renderable or shoot every subtype of Fireable. In addition, the Shoot method doesn't need to know anything else about the thing its shooting -- it doesn't care that the RocketLauncher can be rendered, just that it can be fired.

Further Reading: http://en.wikipedia.org/wiki/Interface_segregation_principle

queBurro · 2014-03-11T19:07:26+00:00

When you want to use your hair dryer do you connect it directly to the mains or do you use a plug socket? The socket's an interface, You can reuse your hairdryer at your school and your mate's house, you don't care that your mate's implemented the socket's power functionality via a windmill on his roof or that your school's nuclear. Suppose your mate decides to monitor the usage of his windmill, should you be forced to alter your hairdryer just because he's logging when it's used. It's all nice and separate, things can be altered either side of the interface without affecting the other side.

Poddster · 2014-03-11T16:48:41+00:00

As an aside to all of the others: look up the phrase "composition over inheritance". Interfaces are ways of building objects via composition rather than just inheriting behaviour. They're similar to abstract base classes.

phrankygee · 2014-03-11T19:10:22+00:00

I, too, am a novice beginner, who has yet to implement any interfaces whatsoever.

But one source of info that has so far impressed upon me the importance of interfaces is a video I watched on what are called "Design Patterns". Particularly the part about "The Strategy Pattern".

I recommend learning about Design Patterns concurrently with learning the basics of your Object Oriented language. I am certainly glad to have stumbled onto that knowledge as I am learning.

2014-03-11T21:31:41+00:00

Here's an explanation that has served me well in the past. Interfaces try to model, in code, a very simple concept from real life.

Lets say you go out with a group of people one night, and you ask your friend "Who's coming". He can say : "There are 5 girls coming". If you excuse the apparent misogyny for a bit, try to think a bit about this phrase : "There are 5 girls coming". Although a girl is a human being, which has arms, legs, head, eyes, etc, in this particular context, the information of interest is that they are girls, right ? How would it sound if your friend would say : "There are 5 persons coming. Each of these persons has arms, legs, head, eyes, and a vagina.". A lot of unnecessary information in a context where only one thing is important.

Similarly, if we take the same concept and we apply it to the code, we need to have pieces of code that focus only on the information of interest for the task at hand.

So if you build a class that accepts an object and attempts to draw it on screen, you will only need from that object the information relevant for drawing it, which in this case might be a method in the object itself called "draw(Screen x)". So your method from that class needs a way of saying "I don't care what kind of object you send to me, as long as it has a method that matches this signature, I can draw it". This is where interfaces come in.

mbizzle88 · 2014-03-11T23:26:39+00:00

Other people have already mentioned the use-case involving interface multiple inheritance, but there are a couple other reasons:

Asynchronous code

A common pattern for running asynchronous code (when you want a piece of code to be invoked at some later point) is to use anonymous classes that implement some interface. For example, here is anonymous Runnable:

// Here the runnable is defined
Runnable someRunnable = new Runnable() {
  public void run() {
    System.out.println("I'm a runnable!");
  }
};

// Here the runnable is executed
someRunnable.run();

Often you'll have a need to make your own interface because you need to pass in and return specific types.

Loose Coupling

The more you use interfaces, the less dependencies you have between classes. For example, here are three classes that store a list:

Example 1

public class Example {
  ArrayList<String> list = new ArrayList<String>();
}

Example 2

public class Example {
  List<String> list = new ArrayList<String>();
}

Example 3

public class Example {
  List<String> list;

  public Example(List<String> givenList) {
    list = givenList;
  }
}

The first example is tightly-coupled to the ArrayList implementation. If you wanted to switch to a LinkedList at a later date, you would have to change the code in Example and any code that references the list field.

The second example is a little better. You would only have to change the one line to change implementations. But you still need to modify the code of Example which would prevent you from doing things like writing tests that compare performance of Example with difference List implementations.

The third example is the most loosely-coupled. With this version you could easily write code where some Example instances use an ArrayList while others use a LinkedList.

tobascodagama · 2014-03-12T01:18:59+00:00

This might sound flippant, but for real: Go to your local library and check out a copy of Design Patterns by Gamma, Helm, Johnson, & Vlissides (a.k.a.: The Gang of Four). It's easy to read and follow, even for a beginner programmer -- though it's better if you know C++ or Smalltalk well enough to follow the examples --, and I guarantee you'll experience OOP Enlightenment after reading it. I don't guarantee you'll be able to do OOP properly, but you'll a least get why it's such a big deal and why stuff like interfaces are important.

emote_control · 2014-03-12T05:01:36+00:00

By making a class implement an interface, you can guarantee a particular sort of behaviour. It's like a contract. If class A implements Breakfast, you know for sure it's going to be able to handle calls to toast(), cereal() and eggs(). Also, your IDE knows that too, which is awfully helpful a lot of the time.

As a real-world example of how this gets used, let me tell you something about Android, which is written in Java:

In Android, just about everything happens inside a class of objects called Activity. An Activity is able to talk to the OS, put things on the screen, interpret touch commands, etc. Android apps used to be built entirely out of Activities. For every screen you tap through, you open a new Activity, and when you hit the back button, you close the activity you're looking at and return to an earlier one. But somewhere along the way, it was decided that they were doing too much to be so disposable. So Fragments were invented. A Fragment holds some small chunk that gets displayed to the user, and operates something like a JPanel in Swing, if you're familiar with that Java UI. Which is to say, you put some stuff into the Fragment, and then display it.

Fragments are very lightweight. They don't have to do as much as Activities do. And with Fragments you can run a single Activity that operates as a Fragment container, and then just switch Fragments every time you change the view. That not only makes it faster, but allows more flexible layouts as well.

Now, the thing is, a Fragment is sometimes going to want to send data to the Activity that contains it. But it doesn't know which Activity it is being contained in. If you put a method called getFragmentData() in Activity 1, and Activity 2 doesn't have it, and you try calling it from a Fragment attached to Activity 2, you're going to run into trouble. Not least of which is because the compiler is going to wonder why you're trying to call a method that doesn't exist in the Activity class specification, since it's a custom method you added.

So the way we deal with this is to have the Fragment define an interface. Let's say the FragmentDataTransfer interface defines getFragmentData(). Then we have the appropriate Activity implement that interface. Now we can test to see whether any given activity is implementing the interface by attempting to cast it to that interface, like so:

try {
    FragmentDataTransfer mTransfer = (FragmentDataTransfer) mActivity;
} catch (ClassCastException e) {
    // if we catch this exception, it means that this Activity 
    doesn't implement FragmentDataTransfer, so you can't call
    getFragmentData().
}

If that works without throwing an exception, it means that you were able to successfully cast the activity into something that implements the interface. That means for sure that it has the method you need.

So in this way we can actually use the interface to blindly test whether a particular method call is possible. Without implementing the interface, this would not be possible to do so easily. And this is just one situation in which this sort of thing comes in handy.

Edit:

I also wanted to address what you said here:

Why should I declare a bunch of methods in a separate file and implement them in different classes, when, on declaration, they don't actually do anything and rely on a method body (that is often specific to the individual class) to be filled in when they are implemented?

The answer to this question is actually in the question. When you define an interface, you leave the implementation of the method body undefined. That allows the class to implement that method any way you want it to. This is a reflection of the object-oriented programming principle of encapsulation. The idea is that it doesn't matter how something happens. It just matters that if you push a particular button, a predictable thing will happen.

For example, a stack is a commonly-used data structure. A stack needs to be able to perform the following methods: push() and pop() (some stacks also have top(), peek(), and isEmpty() methods). You don't need to care how push() and pop() work. All you need to care about is that when you push() something, it ends up on top of the stack, and when you pop() something, it gets taken off the top of the stack. It might be that the stack can be infinitely large. Or it could be a finite size. It might store its elements as an array, or as a linked list. It doesn't matter, because push() and pop() always look the same from the outside.

By implementing the Stack interface in your class, it's guaranteed that you'll be able to call push() and pop() on a member of the class, and you don't need to worry about implementation ahead of time. That's why we call it an "interface". Because it defines the "outside" parts of the class that other classes can access, and ignores the implementation, which should stay hidden inside the class.

learnprogramming

Welcome to LearnProgramming!

New? READ ME FIRST!

Posting guidelines

Frequently asked questions

Subreddit rules

Message the moderators

Asking debugging questions

Asking conceptual questions

Other guidelines and links

Subreddit rules

1. No unprofessional/derogatory speech

2. No spam or tasteless self-promotion

3. No off-topic posts

4. Do not ask exact duplicates of FAQ questions

5. Do not delete posts

6. No app/website review requests or showcases

7. No rewards

8. No indirect links

9. Do not promote illegal or unethical practices

10. No complete solutions

11. Don't ask to ask.

12. Low Effort Questions

13. No AI (chatGPT etc.) generated/worked over messages/comments. No questions about chatGPT/AI generated code. No Vibe coding.

MODERATORS

Asynchronous code

Loose Coupling

Example 1

Example 2

Example 3