CodeGym/Java Course/Java Core/Inheriting multiple interfaces

Inheriting multiple interfaces

Available

"Hello, Amigo! We've finally come to something truly interesting. Today I'm going to tell you about multiple inheritance. Multiple inheritance is indeed a very fascinating and powerful tool. And if it weren't for several problems, then Java would support multiple inheritance of classes. But it doesn't, so we must be content with multiple inheritance of interfaces. Which is also pretty awesome."

Inheriting multiple interfaces - 1

Imagine you're writing a computer game. And its characters (your objects) must behave in very complex ways: walk about a map, collect items, perform quests, communicate with other characters, kill someone, save someone else. Let's say you've been able to divide up all the objects into 20 categories. This means that, if you're lucky, you'll be able to get by with only 20 classes to define your objects. But here's the catch: how many unique forms of interaction will these objects have? Each type of object can have unique interactions with 20 other types of objects (we're also counting interactions with objects of the same type). In other words, you'll need to write code for 20 x 20 = 400 interactions! And if the number of unique object types is not 20, but 100, then the number of interactions could be 10,000!

"Whoa! Now I understand why programming is such difficult work."

"It's simple. Thanks to lots of abstractions. And with no small thanks to multiple inheritance of interfaces."

We can often simplify object interaction if roles and/or abilities interact rather than the objects themselves. And as we already know, abilities can easily be added to a class when it implements some interface.

When writing a large program, developers usually do this from the very start:

1) Identify all abilities/roles.

2) Define the interaction between these roles.

3) Then simply assign roles to all the classes.

"Maybe an example?"

"Of course. Let's look at roles in the cartoon «Tom and Jerry»."

Java code Description
interface Moveable
{}
— Role/ability to move.
interface Eatable
{}
— Role/ability to be eaten.
interface Eat
{}
— Role/ability to eat someone.
class Tom extends Cat implements Moveable, Eatable, Eat
{}
Tom is a cat that has three roles:
1) He can move
2) He can eat someone
3) He can be eaten by someone (a dog)
class Jerry extends Mouse implements Moveable, Eatable
{}
Jerry is a mouse who has two roles:
1) He can move
2) He can be eaten by someone
class Killer extends Dog implements Moveable, Eat
{}
Killer is a dog with two roles: 1) He can move 2) He can eat someone

Knowing only these three roles (interfaces), you can write a program and describe the correct interaction between these roles. For example, an object will chase (via the Moveable interface) after the «one you can eat» and run away from the «one who can eat you». And all this without knowing about specific objects. If you add more objects (classes) to the program and keep these roles, it will still work beautifully, controlling the behavior of your objects.

Comments (14)
  • Popular
  • New
  • Old
You must be signed in to leave a comment
Abhishek Tripathi
Level 72 , Rewa, India
Expert
13 September 2023, 17:15
Ohk it was a practically explained chapter, but I think there could have been more explanation of the interaction of the of methods.
Tasmoda Android Developer
6 June 2022, 08:58
I see cats got a break this time😂
Aldo Luna Bueno
Level 1 , Peru
1 March 2022, 22:08
This article feels real and practical. Good explanation!
ImDevin
Level 15 , Old Town, United States
31 May 2021, 15:54
it's better to be a Dog! :)
Maciej Florys
Level 17
6 February 2020, 10:33
The dog from Tom & Jerry was Spike! Duh...
Thang Za Thang
Level 18 , Melbourne, Australia
8 July 2020, 04:25
This comment took me to memory lane ---- I googled and the name of Spike's son is Tyke!
Manuel
Level 22 , Vienna, Austria
12 November 2019, 13:27
well explained!
Hashirama
Level 26 , Port-Harcourt, Nigeria
4 February 2019, 12:38
Cool stuff!!!
Tayyab Mubeen
Level 16 , Lahore, Pakistan
2 November 2018, 13:30
this is the best article related to interface....because its very close to practical...!!! nice one...!!!
Fadi AlSaidi
Level 13 , Carrollton, United States
2 March 2019, 17:40
Mr.Mubeen, it seems that you have practical knowledge, if you don't mind help me understand this better. I would create an abstract class to declare mostly characteristics/ attributes. I would create interfaces to declare functions only. This way I would inherit all characters/attributes, and would implement functions as needed. is that the way I should think about this? So for example, FYI: I am using the words "characteristics/ attributes" & "functions" in their letteral meaning if I am designing an Animal Class because my programs/game has lots of Animals. I would design an abstract class that has variables related to the over all animal characters/attributes such as color, weight, life … then I would create interfaces such as eat, make noise, attack, move, run …. does that sound right? or I should still include some functions in my Animal class. Because to me the whole idea of Interfaces is to overload functions. I hope my question makes sense. please feel free to school me
Kotlet
Level 28 , Wroclaw, Poland
27 June 2019, 21:30
Sorry for necroing but maybe someone else is wondering about the same thing. There is a really good explanation in Head First Java book (which is recommended by CodeGym so I guess it is OK to say its name - if you have a chance I would also recommend to look it up, they have really nice graphs which help to understand). Basically it depends. For my understanding in case you brought up it probably would be better to include some functions in your Animal class (or in one of the subclasses). That is because every object you create is in the same inheritance tree (each subclass IS-A(n) Animal). So generally they would inherit those methods (of course depending on their access modifiers) – eat, make noise, attack, move, run (and if some need to be changed, because for example every animal (subclass of Animal) make a different noise, they could override them). Interface would be useful if you would like to implement those methods between classes from different inheritance trees. For example you have a Bird class which extends from Animal class, and Plane class (extends from Machine class). Naturally Plane IS-NOT A(n) Animal and Bird IS-NOT A machine. To link (couple) those classes and give them the same “function” (role/ method) you could implement fly interface. In conclusion – when you have everything within one inheritance tree (classes are strongly connected, they pass the IS-A test), there is probably no need for interface (every subclass is just more specific version of its super class). But when you want to give specific method (“function”) to loosely connected classes or far subclasses (no matter of their inheritance) use interface. If I'm wrong please someone correct me :)
Ntuthuko Xaba
Level 18 , Johannesburg, South Africa
1 April 2020, 22:08
I've been wondering why, one would use abstract classes when it seems interfaces do just a good of a job , and your explanation has been the most sensible so far.
Jonaskinny Java Developer at Sandmedia
26 February 2022, 05:47
abstract classes can have implemented methods, at some point in the API interfaces gained that ability (8 I believe), but not from the beginning.
Jonaskinny Java Developer at Sandmedia
26 February 2022, 05:51
behaviors (methods) that belong to the interface should apply verbs to object implementing them. Abstract classes can capture state of nouns that implement those interfaces. If you follow this, you get 2 things ... 1-Natural breakup of class vs interface 2-Interfaces 'may' be usable outside your project (independent of noun state) if done correctly