An Abstract Class may and may not have abstract methods but an interface has unimplemented methods only. So what is the difference and advantage of using an interface if my abstract class has all of its methods marked as abstract?
-
An abstract method still contains code; an interface simply defines a method "signature" but cannot include actual code, so an interface cannot contain abstract methods – Mark Baker May 25 '16 at 12:48
3 Answers
Interfaces and Abstraction
The real power of use can be revealed in huge APIs with massive amount of classes that follow a well-thought flexible structure for future coding. Whether it may happen or not - you never know whether a code will be extended. Interfaces are merely used for semantic reasons. Imagine, you extend a deprecated version of an API and have the job to edit/alter/implement/update/improve/extend/modify the code to bring it up to date, whatever the reason is. You'd end up being frustrated if you did not think forward.
Small APIs can be made without the interfaces and that's where most people think interfaces were unnecessary. But then they lose their flexibility as soon as they become larger. They provide you a contract with classes which reminds you what is needed and to keep the overview. Interfaces must have public methods, if you have protected or private ones, just return them in a public method of a class with interface implemented..
Like you already explained, interfaces demand particular methods to be implemented, abstract classes don't demand it since you most likely extend them anyway. Methods can be re-defined and abstract methods MUST be defined in child classes. Methods mentioned in an interface only tells you that classes that have a contract with an interface must have these defined. It could be multiple interfaces, you don't inherit from them like you would do it with abstract classes.
Think like this way
The logic in it is to predict the future in what you are planning to build. Be it in architecture, infrastructure or mass production in factories. Just like the way you sort items like bookmarks, books, images in a folder. Because you know it would take longer to find a particular image if you didn't sort it. The semantic purpose of abstraction and interface is similar, especially in huge APIs.
- An interface reperesents a frame of possibilities and requirements.
- An abstraction preserves conceptual information that is relevant in a derived context.
I'll show you a typical structure for a start of an API with simplified contents wherein interfaces and abstract classes have a real point of usage for future extension.
/* Considering, this project will be widely expanded up to huge complexity.
This is a flexible base structure, for developers working in team. Imagine
there could be lots more variation of styles for certain purposes. */
// OOP STRUCT
// You might want to define multiple interfaces to separate the project
interface iString {
// These methods MUST be defined or else the developer receives an error
public function getContent();
public function description($desc);
}
/* Devs might want to add an additional method later on.
Traits are useful for quick use. (optional) */
trait desc {
private $desc;
public function description($desc) {
return $this->desc;
}
}
/* This is the base class for the content which requires a declaration
of methods being described in the interface */
class contents implements iString {
use desc; // use the method defined in a trait
private $str;
public function __construct($str) {
$this->str = $str;
}
public function getContent() {
return $this->str;
}
}
/* Or devs often consider abstract classes as the real base of the whole project/app.
Abstract classes allow the use of methods that can be modified/declared for further use in derived classes.
Interfaces can't do that */
abstract class stylize {
private $str;
// This typehint below makes sure that this value is assigned on interface
public function __construct(iString $str) {
$this->str = $str;
}
public function style() {
return $this->str->getContent();
}
abstract public function getContent();
}
// EXTENDED CLASSES
class bold extends stylize {
// Extended classes have to define abstract methods inherited from an abstract class. Non-abstract methods are not needed.
public function getContent() {
return "<strong>".parent::style()."</strong>";
}
}
class underline extends stylize {
public function getContent() {
return "<u>".parent::style()."</u>";
}
}
class upperCase extends stylize {
public function getContent() {
return strtoupper(parent::style());
}
}
// PROCEDUAL OUTPUT
// A tiny shortcut
$e = function($desc,$str) { echo $desc.": ".$str->getContent()."<br>"; };
// Content being used
$content = new contents('Hello World.');
$e("Normal",$content);
// Content being styled
$bold = new bold($content);
$underline = new underline($content);
$upper = new upperCase($content);
// Renders content with styles
$e("Bold",$bold);
$e("Underline",$underline);
$e("Uppercase",$upper);
Conclusion
Applying styles of text contents as an example is probably not appealing enough. But apart from this, it remains the same - if it does what it should do, then it's done. Like as if I would build an expandable eMail configuration API as a module for a CMS. This structure has a semantic process in proper coding.
Tipps
I'd suggest you to keep learning in small projects with this pattern, even if you think interfaces are not worth it. Keep doing this until you have it inside. My own personal advice for you:
If you think you have no idea where to start and what project to try it on, then try real world examples just follow this logic:
Vehicles (abstract class) -> Ferrari (extended class) -> Truck (extended class) both have wheels (property) both must be able to drive (method) they perform a 1mile match race on a street (abstract method) one is a slowpoke (extended property) one is red one is blue (extended property) and later a 3rd one comes and its a train (extended class) who's going to win (some method) Instantiate all vehicles and maintain privileges over interface and abstraction. ...something like this...
Usually, classes containing huge bodies are supposed to be separated in single files + include these + define a namespace. Else wall of code would make you or someone else tired. Use Eclipse, best app for maintaining OOP.
Also, if it fits for your project, use phUML if you have Linux Ubuntu. It generates a graphical diagram for your current build if you have a lot of relating classes.
phUML is an API in PHP based on UML. It is an open-source project which generates any visual schemes for almost any popular programming language. I use it a lot, not just for PHP. Simply clone it at Github or download from dasunhegoda.com and follow installation guide there.
This could interest you also: Typehinting on Interfaces

- 4,122
- 2
- 25
- 35
-
the `abstract public function getContent();` in stylize class is redundant (not necessary) because of iString interface's `public function getContent();`. This drives me to question, what is the difference between normal class that implements interfaces and abstract class that has abstract methods? – Rivo Aug 21 '18 at 00:57
-
Nono, it's because I'm showing both examples in one code here One concrete class with interface and an abstract class with abstract method. Difference is the use case here as you are able to re-define/add methods in an abstract class which you can't do it in interfaces as explained in the comment. I fixed it some to make it more clear. – Thielicious Aug 21 '18 at 15:48
An Abstract Class allows for "partial implementation" (see the template method pattern), but in this case, if all methods are abstract, you don't see that benefit. One other thing you can do is include fields, you're not just limited to methods.
Remember, there's a conceptual difference between an "abstract method" and the contract defined by an interface. An abstract method has to be overridden by a subclass which is done through inheritence implementation. Any polymorphic calls (downcasting) will require one superclass per class or it would hit the diamond inheritance problem. This kind of inheritence based tree structure is typical of OO design.
As a contrast, an interface provides a signature of a contract to fulfil. You can fulfil many interface's needs as long as you retain the signature as there is no question of going back up the class hierarchy to find other implementations. Interfaces don't really rely on polymorphism to do this, it's based on a contract.
The other thing of note is you may have "protected" abstract methods, it makes no sense to do such a thing in an interface (in fact it's illegal to do so).

- 6,343
- 16
- 19
-
Thanks for the answer, so main benefit in this situation is we are overcoming "diamond problem" or "deadly diamond problem". Please correct me if m wrong. – Nidhi Gupta May 25 '16 at 13:40
If an abstract class
has all of its methods defined as abstract
then you have to define its body in any subclasses and it displays similar behavior as interface
.
Benefit :
Using interface
instead of abstract
class, you can implement
more than one interfaces
while using abstract
class you can only extend one
class at a time.
EDIT
Another difference I found about this is abstract
class can have constructor
while interface
can't have.
REF: What is the use of constructor in abstract class in php
-
Thanks for the reply. I said the same benefit but interviewer wasn't convinced. – Nidhi Gupta May 25 '16 at 13:25
-
You were need to be very sure of this things with examples in interview, and may they were checking your confidence. – Ali May 25 '16 at 13:29
-
he said that's fine, but what difference its making. I need specific difference why should I implement interface in such scenario. – Nidhi Gupta May 25 '16 at 13:35
-
In such cases there is no perfect answer to say. This is the choice of developer, If you think that in future you may need non abstract methods then you should go for `abstract` class else you should go for the `interface`. – Ali May 25 '16 at 13:44
-
From this page http://php.net/manual/en/language.oop5.interfaces.php, Interfaces can have `constructor` too. – Wael Boutglay Aug 09 '18 at 00:07