Assume that you have been hired to create a pet shop application. We have created and used the Animal e class as abstract and created a concrete subclass of HouseCat. But, a HouseCat also has certain behaviors associated with all pets (such as play() and beFriendly()). Similarly, if we created a concrete subclass of Dog, it would also have the pet behaviors. So, ideally we want to write public class HouseCat extends Animal, Pet.
This concept is called multiple inheritance and can be very dangerous. What if both Animal and Pet had a method with the same name, or data members with the same name but different values. How would the HouseCat class know where to inherit the information from? Luckily, Java does not allow multiple inheritance.
Instead, we would make the Pet class an interface (public interface Pet{}). An interface is a class that has no data members and all methods are abstract (not implemented). So, our HouseCat class would now be written as public class HouseCat extends Animal implements Pet. This means that the HouseCat inherits all methods and data from Animal and inherits necessary methods from Pet. When a class implement and interface, it must implement all methods of the interface. Also, it is possible to implement more than one interface at a time public class HouseCat extends Animal implements Pet, Friend.
Knowing when to use an interface, when to use an abstract class and when to use inheritance can be tricky. Here are some guidelines to help:
Make a class that doesn't extend anything when your class doesn't pass the IS-A test for any other type.
Make a subclass only when you need to make a more specific version of an existing class and need to override or add new behaviors.
Make an abstract class when you want to define a template for a group of subclasses, and you have at least some implementation code that all subclasses could use.
Make the class abstract when you want to guarantee that nobody can make objects of that type.
Make an interface when you want to define a role that other classes can play, regardless of where those classes are in the inheritance tree.
Examples:
Write a grading program: Student class
Write a geometry program for working with quadrilaterals: Quadrilateral class and subclasses
Write a payroll program: Abstract Employee class and concrete subclasses
Write a code to be used to convert a variety of object types to strings: Printable interface to be implemented
Another popular interface is Comparable. This is used to compare two objects. Since each pair of objects is compared in different ways, it would be impossible to write code for this. Also, it needs no data types. So, we implement the Comparable interface to send back values of positive, 0 or negative.
Let's be honest, what is the point. We're not inheriting anything from an interface except for more work. So, why?
See the magic of the interface is similar to that of the abstract class. While you can't instantiate objects of an interface or abstract class, you can declare objects of them or downcast to them. This means that multiple types of objects, that implement an interface, can come out of a data structure, be downcast to that interface type, and any method contained in that interface can be called on them and they will act accordingly.
Think back to our employee types (Manager, Sales and Secretary). While inheriting from the abstract class employee the contract of implementing the abstract pay method, they could implement an interface called Payable. That payable interface could also be applied to some bills that come in during the month. I can store a list of the employees and the bills (all money going out of the company) in one data structure, downcast everything as type Payable and call the required pay method. This works because every class that implements Payable would have to implement the pay method. It's guaranteed to be there!!!!