When to use interfaces from an oop pov

Question

I have been taught many things about how to structure code. For instance, nouns translate to classes (Eg, class Dog, class Banana). Something that objects have translate to variables inside the class. (Eg, a dog has a name so name would be a variable inside the Dog class.) I've also been taught that abstract nouns translate to abstract classes, eg, ChessPiece would be an abstract class and king, pawn etc would inherit from it.

How do interfaces work like this? I never find myself using interfaces and I want to because I heard that you should design towards an interface.

score 2 · Accepted Answer · answered Jul 20 '14 at 08:23

Interfaces "work like this" such that they enforce a contract to be met amongst its implementer. IOW, the interface says = "you shall do this". So, keeping with your example you might think even "lower" by observing that a ChessPiece is actually a GamePiece in that it inherits a certain amount of behavior that all game pieces have. It may be as simple as...

public interface GamePiece {
    void move(int x, int y);
    // more behaviors here
}

And you have your abstract class of ChessPiece...

public abstract class ChessPiece implements GamePiece {

    // could add more shared stuff here
    public abstract void move(int x, int y);
    // other stuff can be implemented if needed
}

which the King would extend...

public class King extends ChessPiece {

    @Override
    public void move(int x, int y) {
        // move as the King does
    }
}

BUT you can also apply that contract to other game pieces as well. Perhaps you want a CandyLand piece...

public class CandyLandPiece implements GamePiece {

    @Override
    public void move(int x, int y) {
        // move as these pieces do
    }       
}

That's very helpful, thanks. I'm kind of getting it. – Ogen Jul 20 '14 at 08:25 — Ogen, Jul 20 '14 at 08:25

Inder · Answer 2 · 2014-07-20T08:22:22.370

1

Think of Interfaces as agreements. A cricket ball and a football for instance can be considered classes. But they follow a common agreement say "Bouncable". Interfaces logically combine classes of different class hierarchies together.

Modified answer as per comment: Bounceable Interface can have a method "bounce". This would in turn imply that all classes that implement Bounceable Interface would definately have to implement "bounce". Logically this sounds correct as well that every Bouncable ball (be it a cricket ball or a football) must be able to bounce.

edited Jul 20 '14 at 08:22

answered Jul 20 '14 at 07:58

Inder

160
9

So what kind of methods would this interface have? – Ogen Jul 20 '14 at 08:03

score 1 · Answer 3 · answered Jul 20 '14 at 08:06

I would generally agree with the first paragraph.

On

How do interfaces work like this? I never find myself using interfaces and I want to because I heard that you should design towards an interface.

You probably haven't dealt with large projects in java.

Interfaces are exactly what they sound - definition of a contract with which two java modules can communicate. Abstract classes are interfaces + definition of functionality.

I use interfaces when I think of communication with external module. It should be able to see and use your interface and (probably) nothing else.

Abstract classes are there to avoid repetition in their subclasses, but, as you know, cannot be instantiated, ergo they lack some functionality to be a complete object of the type.

Maybe you should provide a code snippet that can be discussed here.

Can you give me an example of where you'd use an interface – Ogen Jul 20 '14 at 08:13 — Ogen, Jul 20 '14 at 08:13

score 1 · Answer 4 · answered Jul 20 '14 at 08:42

On the surface, interfaces are very much like classes, except they can't define the methods inside them. It is left upto the implementing class to define the method as they seem fit. Since Java quite sensibly does not allow one class to inherit from multiple classes (multiple inheritance), one class can still implement multiple interfaces to achieve this goal and avoid the pitfalls that come with multiple inheritance. So you could have a method sound within the interface animal, and every class implementing this interface will have to define method sound in their own custom way. Here's an example,

Suppose you have an interface Animal which has a makesSound method.

class Dog implementing Animal will also have to define makeSound(){//bark}

class Cow implementing Animal will also have to define makeSound(){//Moo}

If you are going to be implementing same functionality for all classes, good idea to extend a class and if you want custom functionality with same name for all classes, good idea to go with an interface. Generally, lean towards an interface as it will allow you the option to extend a class to your current class in the future.

When to use interfaces from an oop pov

4 Answers4