an abstract class provides a foundation of the "house" you're building, with some basic appliances, you just provide "furniture"
an interface is just like a blueprint you have to follow, each time you build the house you have to provide your own appliances
stupid analogy cuz im in the middle of finding a new place lol. basically abstract classes provide some functionality with them and can have abstract and non abstract methods
A real world example would be a "user" class, that extends an abstract "table gateway" class that implements an "iterator" interface ( the iterator interface could be removed without changing run-time functionality in PHP, but is good design practice because if makes it so you can't forget methods that would break higher level code later down the road )
If you recognize that a class you're building implements iterator, and some other design patterns you can tell your class to implement several interfaces. Basically in PHP the only thing this is good for is making a contract to make sure each method each interface needs is implemented, and as I pointed out using the instanceof operator, which as a general rule of thumb in my opinion should only be used for exception handling, not general application logic
You can also tyepcast objects as they're passed as paramaters, which is a good thing in My opinion
Code: Select all
interface imy {} // starting interfaces with an "i" avoids confusion when using them
class myA implements imy {}
class myB implements imy {}
class myC implements iNOTmy {}
function loadObj( imy $obj ) // this method only accepts classes that inplement "imy"
loadObj( $a ) // ok
loadObj( $b ) //ok
loadObj( $c ) // exception
kind like of an insanity check for the developers, really
in a good encapsulated design you won't ever see or worry about the interfaces within ( all the apartments I'm shopping for have a foundation and appliances, I just extend them with my furniture. It is abstract because it already comes with a door I can open and close, the blueprint the construction workers used is the "interface", it tells them it needs doors and windows, and they "implemented" them ).
Then it can get more complicated, our basic window interface suffices today but lets say tomorrow the client wants a fancy window that slides side to side instead of up and down, and uses hurricane shutters since we live in Florida. A new interface would be written and the application would not build until every piece of code was adjusted to use the new interface.
This is good design practice because you shouldn't go back and re-write that original window, it still does it's job quite well and there's no need to bloat that window down for all the other apartments units ( "classes" in this complex ( "application" )
ok end of apartments metaphors