Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Hello,
Just finished watching the OOP Bootcamp Interfaces chapter for the 3rd time. I don't seem to get it, what is it good for that Abstract Class can't do? except that you can only extend one abstract class (which is quite stupid if you ask me). Say the logger example he used, first of, why do i need to have the actually class require a logger class at the construct, say every single classes i have require a logger, would i have to attach a logger class to each any single one of them? why it would be wrong to make the logger static? I can't understand any of it..Interfaces just seem pointless to me, as i don't need a contract between my classes. but this seem to be a really main thing in OOP, what can i do?
You could just look at them as 'enforced documentation' - ie, if you want to swap out this bit of code, here's what you need to implement.
But you don't need to use them if you don't want too - plenty of other OO languages don't have them at all.
So, the primary difference between Abstract classes and Interfaces is that Abstract classes can provide default functionality for their methods, that may be overridden. Interfaces simply define the blueprint, what methods must exist -- but not how they must function.
Sure, you could probably ignore interfaces altogether and just do everything with abstracts.. but abstracts could also be implementations of interfaces too. In that way you could have something like an 'animal' interface that defines methods that any animal must implement. You could have abstracts for different kinds of animal (dog, cat, etc) that implement your animal interface, and then your concrete classes that extend your animal type abstracts.
An interface is just a 'contract' that lists the methods any class that implements it must provide. This allows you to code to interfaces rather than concrete classes, decoupling code (a good thing). It may sound like a lot of extra work, but I've found that it really helps me to think more clearly regarding project architecture. I'm now using interfaces as much as possible, for documentation, maintainability, and my own sanity, a way to manage complexity.
For me interfaces are like a high-level map of a project, they tell me quickly what I need to know about what each class does, and how they work together - without looking at one line of real code. I don't want to count on memory to understand my own code six months from now.
Jeffrey has a great series on SOLID principles which will make the advantages in coding more clear: https://laracasts.com/series/solid-principles-in-php
As others mention, you don't need interfaces, but the idea of a contract helps to keep you focused on exactly what each class really needs from it's dependencies. Of course, it also makes sense to use abstract classes to implement code common to their extended concrete classes. As a bonus, IDEs like PhpStorm automatically provide editor cues and prompts to enforce correct implementation of interfaces and abstract parent class methods.
BTW, in the same way you extend your abstract classes, you can also layer interfaces, creating primitive ones (corresponding to your abstract classes), and more specific ones (with the additional methods that your concrete classes of that type provide). In this way any class that depends on interfaces can be sure to receive the expected functionality, however primitive or specific, with no additional baggage required.
Please or to participate in this conversation.