Table of Contents:
The lead-up
Deadly Diamond of Death
How interfaces solve the diamond problem?
The idea behind interfaces
The practic...
For further actions, you may consider blocking this person and/or reporting abuse
Without really reading the article, for me an abstract class is used to group members common to daughter classes; you cannot instantiate it.
An interface cannot also be instantiated, but implements a specific behavior, a kind of contract to a class.
By analogy, let's say you have three classes (Car, Motorcycle and Airplane). One of these three vehicles can take off and land. We could implement to the Avion class an IFlyable interface ('I' for Interface, '-able' for 'able to ... fly', by naming convention) with two methods (takeOff() and land()). Since an interface is a kind of contract, even if there are methods you don't use, you still have to implement them in the class.
In Java, for example:
You're right. Your explanation on interfaces and abstract classes both seem to be on point.
However, I would encourage you to share an example where you would personally use an abstract class.
Examples with sample classes help one understand how a thing works. But they may not give enough idea about why or when you should use the thing.
Like, suppose you're working on a small project, maybe building a game.
Under what conditions would you consider creating an abstract class? And why?
Same with interface.
I'll even tell you, write an article on it. It'll be helpful to everyone 😉
Btw, Oracle has some awesome documentation on abstract classes too 👀
1/2
Ok. To illustrate the use of an abstract class, we will start from an Animal class (openclassrooms.com/fr/courses/2683... abstract-classes-and-interfaces-# / id / r-2181451).
An abstract class designates a concept in its simplest form. So an Animal has a weight and a color of fur. Generally, an Animal Eats, Cries, Drinks and Moves. Each of these methods has no body because the abstract class is used to define the actions that these Animals have IN COMMON.
What is the dog's cry? He barks.
Cat ? He meows.
Lion ? He roars.
....
2/2
So, each class (Lion, Cat, ...) will be redefined the methods of the abstract class. This highlights the notion of polymorphism: the overload of method applied to inheritance.
All these animals have their own cry, eat their own food, ...
Pay attention to the syntax: if you want to create a Lion, it's an Animal:
Animal jungleKing = new Lion ("Simba");
The abstract class therefore makes it possible to implement members common to more specialized classes (going down in the hierarchy of the classes) and to define all or part of the methods.
You can create a consistent hierarchy even if you only know part of the system.
I hope I have explained well. You can translate the link from OpenClassrooms and read the full course.
I read the full course using Google Translate. The translation wasn't perfect. But it worked I guess.
I found it to be a great read.
You explained well. But, I feel you missed the most important point of abstract classes.
This line is important.
If all the methods in the abstract class are abstract, I see no point in such an abstract class. Since, it is essentially an interface then.
When you write a class that extends another normal class, you can either override the methods from the base class. Or you can leave them untouched.
You'd want to create an abstract class when you know that,
there are some methods in the base class that will definitely be overridden in the derived classes.
eg.
cry()- Dog, Cat and Lion each have a different crythere will be some methods that won't be overridden in any of the derived classes.
eg.
walk()- Dog, Cat and Lion each walk the same way.Whether the
walkmethod is actually overridden in the derived class or not, doesn't matter.But, an abstract class lets me provide the definition of
walkmethod that I believe will be common in all the derived classes. Basically, it lets me provide a default for thewalkmethod.And, at the same time, it lets me enforce that the derived classes implement the
crymethod.If you already understand this, then great!
But if you didn't, I hope I was clear enough.
Again, I'm more interested in a practical example where you've actually created an abstract class while writing software. So, whenever you do that, I'd be happy to hear about it :)
Yeah, i forgot the principle to define default methods with abstract keyword. Your explanation seems better than mine. Thanks !
Yeah, JavaDoc explains better than me abstract classes
Your teacher was bad. That's the problem here. An interface is a contract, that is all. This multiple inheritance answer is the type of thing a bedded in C++ dev would answer to why Java has interfaces.
Interfaces are a contract that I will adhere to so that:
a. I can substitute the implementation for another without changing the class which uses it. Therefore we can wire programs together with -for example- DI or Tests.
b. Third parties know the contract and can write functionality for it
Omg. That is so to-the-point. I love it!
I hope though that if my teacher is reading this, she doesn't realise she's being called out on. Might hurt her 🙊
Really enjoyed reading this! Nice job describing the problem. I was also one of those "why would I ever need an interface when I have a class" untill I started working and realizing the conveniences of interfaces. Now I wanna check your other articles :D
Thanks man! :)
Sadly though, I don't write that often. So, you won't find much :(
But, I intend to fix that. Thinking of committing to publishing an article every month. Let's see.
It was very helpful and up to the point.!
Glad to hear that! 🙌
Really good read. I never really understood the real purpose of interfaces but this cleared it up 😁👍🏽. I like your writing style. Keep it up!
Hey man thanks! That meant a lot! ♥️
So glad to know that it was helpful :)
Great read. Love the analogies. But I'm a javascript developer and there is no support for interfaces in javascript currently. How would I create a contract for other developers to follow?
That's a nice question!
You're right. JavaScript is not strongly an object-oriented language and it does not have interfaces. And AFAIK, there's no real way of creating a contract like that in JavaScript.
Also, JavaScript is not statically-typed. So, even if you had interfaces, you could only check for the existence of functions. And not for their return-types or their parameters.
You may use TypeScript though. It supports interfaces, type-checking and works with existing JS code.