Las herencias de clases definen el "qué son" y las de interfaces agrupan clases que definen el "qué hacen".
Cuando agrupas por herencia hay una relación de parentesco, pero con las interfaces agrupas cosas que "hacen cosas similares" como una interfaz "imprimible" que todos tus objetos deberían implementar para poder pasar por la impresora (les estás diciendo de alguna forma que deben cumplir con un "contrato de implementación" para poder ser "imprimibles").
O hacer una interfaz "Pelable" para que la implementen las bananas, las manzanas y tu multiprocesadora. Esta última no es pariente de "frutas", pero puede hacer la misma acción que es "pelar".
Esto se relaciona con el polimorfismo, en el sentido que vas a tener un método de una clase, no sé (ya me estoy divagando mucho), cocinero, que pueda pelar cualquier cosa que le den, mientras estas sean "pelables".
Código PHP:
class Cocinero{
public function pelar($elemento){
$elemento->pelar();
}
}
El "contrato de implementación" se hace cuando haces este "control de tipo":
Código PHP:
class Cocinero{
public function pelar(Pelable $elemento){
$elemento->pelar();
}
}
Entonces solo pueden entrar los objetos que cumplan con la interfaz.
Si lo quieres ver de otra forma, se podría hasta decir que las interfaces son una extensión conceptual de la herencia (por lo que puse al principio).
Y finalmente, y esto es clave en entornos como Java, las interfaces permiten pasar del estilo de diseño "orientado a la implementación" a uno "orientado a la interfaz", donde todas las clases acceden a servicios a través de interfaces que son implementadas por clases concretas. Y al no depender de clases concretas (solo de entidades abstractas) nuestro diseño será más reutilizable que el anterior.
Este último párrafo debería ser un "mantra" de los desarrolladores y repetirlo ni bien nos levantamos y ni bien nos acostamos
