Une interface définit des services et la documentation de chaque méthode de l'interface doit être précise avec qu'un développeur souhaitant développé l'interface respecte scrupuleusement la description de ce que doit faire la méthode.
Un bon exemple est l'interface java.util.Collection
Une classe abstraite n'a pas pour role de définit des services mais données une base à de futur implémentation.
Le code d'un framework doit s'appuyer sur des services, donc des interfaces alors que la classe abstraite doit etre vu comme un socle commun en vue d'implémentation d'une interface. Selon la nature des implémentation le socle commun poura etre différents.
L'utilisation des interfaces se revèle indispensable quand il s'agit de modéliser un processs métier avec divers acteurs. Le "workflow" utilisera des interfaces mais la réelle implémentation des services dépendra de l'acteur final.
Un exemple pris comme ca: vendre un billet de concert suit tjs le meme processus métier: rechercher un spectacle pour des dates, obtenir les prix, saisir les informations du client, confirmer l'achat, envoyer les billets et la facture. Derrière il peut y avoir plusieurs acteurs qui ont chacun leur système et l'implementation de chacun des méthodes dépendra du système final. Met pour l'application au plus haut niveau, cela restera le même processus métier.
[^] # Re: interface systématique ?
Posté par Olivier MARTIN . En réponse au journal Interfaces Orientées Objet PHP. Évalué à 4.
Un bon exemple est l'interface java.util.Collection
Une classe abstraite n'a pas pour role de définit des services mais données une base à de futur implémentation.
Le code d'un framework doit s'appuyer sur des services, donc des interfaces alors que la classe abstraite doit etre vu comme un socle commun en vue d'implémentation d'une interface. Selon la nature des implémentation le socle commun poura etre différents.
L'utilisation des interfaces se revèle indispensable quand il s'agit de modéliser un processs métier avec divers acteurs. Le "workflow" utilisera des interfaces mais la réelle implémentation des services dépendra de l'acteur final.
Un exemple pris comme ca: vendre un billet de concert suit tjs le meme processus métier: rechercher un spectacle pour des dates, obtenir les prix, saisir les informations du client, confirmer l'achat, envoyer les billets et la facture. Derrière il peut y avoir plusieurs acteurs qui ont chacun leur système et l'implementation de chacun des méthodes dépendra du système final. Met pour l'application au plus haut niveau, cela restera le même processus métier.