¿Mmm... será por eso que repito constantemente que lo más importante, más que saber en profundidad la sintaxis de un lenguaje, es tener claro los conceptos?
Tu ya conoces la sintaxis, pero no sabes para qué se usa... lee sobre conceptos de POO, que se aplican con cualquier lenguaje OO.
¿Si yo te dije, claramente, para qué sirve la herencia... no te parece que las interfaces extienden de alguna forma su funcionalidad?
Las interfaces se usan para crear el "famoso" concepto de "contrato de implementación". Si tu tienes una clase:
Código PHP:
class Impresora{
public function imprimir(ObjetoImprimible $o){
$o->imprimir();
}
}
Estás diciendo que tu impresora solo puede trabajar con objetos que
"cumplan con un contrato", es decir, que cumplan con las especificaciones de la interfaz
ObjetoImprimible. Si implementan la interfaz, están obligados a implementar todos los métodos que ahí aparecen, y si lo hacen, la clase
Impresora sabe que puede trabajar con ese objeto, pues ese objeto tiene todo lo que se requiere.
Que es lo opuesto a decir:
Código PHP:
class Impresora{
public function imprimir($o){
$o->imprimir();
}
}
Donde deberás cruzar los dedos para que quien use esa clase le esté pasando objetos que tengan un método
imprimir, porque de lo contrario, tu clase no funcionará.
Con interfaces bien aplicadas robusteces tu diseño.
Ahora, siguiendo con el ejemplo, creamos el contrato:
Código PHP:
interface ObjetoImprimible{
public function imprimir();
}
Ahora, todo quién quiera imprimir deberá implementar esta interfaz, o conceptualmente,
"cumplir con el contrato establecido para poder usar la impresora".
Código PHP:
class Libro implements ObjetoImprimible{
public function imprimir(){
echo "soy un libro";
}
}
Otro objeto que quiere ser impreso:
Código PHP:
class Foto implements ObjetoImprimible{
public function imprimir(){
echo "soy una foto";
}
}
Forma de probarlo:
Código PHP:
// Funciona
Impresora::imprimir(new Libro());
Impresora::imprimir(new Foto());
// No funciona
Impresora::imprimir(new Curriculum());
¿Se entiende? bueno,
sobre estos conceptos "aparentemente tan tontos" están basadas arquitecturas completas... como Java.
Busca material sobre
el principio "Open/Closed" (Abierto/Cerrado). La primera vez que lo conocí se me cayó una lágrima de la emoción, me sentí iluminado, y dije... ahora veo la matrix
El principio dice, algo así:
"nuestros diseños deben ser cerrados al cambio y abiertos a la extensión".
Traducido sería: el diseño que incluye nuestra Impresora y sus clientes, una vez concluida su implementación, no debería cambiar, porque si lo hace, podría generar un efecto en cadena sobre todas las clases que la usan. Pero se puede extender al permitir seguir agregando clases clientes con solo implementar la interfaz y sin tener que cambiar el código de implementación de la clase Impresora.
Lo que se busca con todo esto es hacer buenos diseños OO para disminuir los costos de mantenimiento, que no debas tocar clases que luego generen impactos en cadena.
Finalmente, muchos principios de diseño te sugieren que
no dependas de implementaciones concretas, solo de implementaciones abstractas, y eso solo lo puedes hacer usando interfaces.
Para luego concluir en
otro principio, el de "inversión de dependencias", que dice que:
"los clientes tienden a ser propietarios de las interfaces y aquellos que ofrecen los servicios las implementan".
En un principio se tiende a pensar que un paquete o capa (utilidades) tiene las clases que implementan servicios (Impresora) y las interfaces de las mismas (ObjetoImprimible), y existirá otro paquete (dominio) que contendrá las clases que serán clientes del primer paquete (dominio -> utilidades).
Pero el principio te dice que es lo opuesto, que las interfaces deberían estar en el paquete cliente, porque así inviertes las dependencias entre ellos, generando que dependa el paquete más concreto del más abstracto, por lo cual genera que sea más fácil reutilizar un diseño de esta forma.
Finalmente, la sintaxis es simple, pero si no tienes los conceptos claros no verás todo el resto.
PD: Yo estoy en pañales y sigo probando e investigando todos los días. Lo que te cuento es moneda común en ambientes más arquitectónicos como J2EE... nosotros somos unos niños en pañales.
Pero podemos intentar aprender de las experiencias de otros.