Plongé actuellement dans le passionant ouvrage qu'est Design patterns. Catalogue des modèles de conception réutilisables (merci Francis pour le conseil ;)), je constate que la base de chaque pattern consiste en un ensemble de classes abstraites ou d'interfaces, alors que peu de programmeurs non-habitués les utilisent réellement à leur plein potentiel. C'est pourquoi j'essaie modestement dans cet article de démontrer la réelle puissance apportée par ces outils. 
Beaucoup de programmeurs non habitués à la POO ne se servent que trés peu des interfaces, ou des classes virtuelles (quand elles sont disponibles dans le langage utilisé). Cet article se propose de cerner l'utilité de tels outils dans la programmation orientée objet.
Les codes exemples sont partagés entre du PHP5 et de l'Actionscript. En effet, alors que le premier offre la possibilité de faire des classes abstraites, l'autre est à mon sens plus lisible et permet un typage fort des types simples ! 
Définitions
Signature d'un fonction/méthode : Il s'agit de la "structure" d'une méthode. En gros, cela correspond aux arguments qu'elle prend en entrée, ainsi que leurs types, et le type de la valeur retournée.
Méthode abstraite (ou virtuelle) : Il s'agit d'une méthode qui ne contient pas d'implémentation. Une telle méthode oblige les classes qui vont hériter de la classe la contenant à implémenter une méthode dont la signature sera exactement la même.
Classe abstraite : Il s'agit d'une classe possédant au moins une méthode abstraite. Une classe abstraite n'est pas instanciable, du fait que l'ensemble de ses fonctionnalités n'est pas implémenté. Une classe abstraite permet de définir certaines implémentations par défaut, et à fournir la signature des méthodes non implémentées.
Pour l'Actionscript 2, Francis Bourre propose un pattern destiné à émuler les classes abstraites : http://www.tweenpix.net/archives/000316.html
Interface : L'interface est un ensemble de méthodes qui devront être implémentées dans les classes qui utilisent cette interface. Elle ressemble trés fortement à une classe abstraite qui ne contiendrait que des méthodes abstraites, et ne contient donc que des signatures de méthodes.
Différence entre classe abstraite et interface
Tout d'abord, la classe abstraite est utilisée par le biais de l'héritage. Il s'agit donc d'une relation de type "est un". Les classes qui hériteront d'une classe abstraite auront donc toutes un lien étroit concernant leur type. De plus, la plupart des langages n'autorisant plus l'héritage multiple, une classe ne peut souvent hériter que d'une seule classe, abstraite ou non. Il s'agit donc pour une classe abstraite de définir un "super type", dont d'autres types concrets pourront dériver.
Par exemple, on peut considérer que tous les véhicules à moteur se remplissent de la même manière : il suffit de mettre du carburant dans le réservoir. Tous les véhicules à moteur peuvent également être démarrés, mais chacun est démarré d'une manière qui lui est spécifique. Ainsi, il serait possible de créer une classe abstraite qui implémente le remplissage du réservoir, mais qui oblige chacune de ses sous-classes à implémenter la méthode de démarrage.
// Classe abstraite de véhicule a moteur
L'interface elle, spécifie quelles vont être les possibilités d'une classe, sans en fournir la moindre implémentation. Elle est donc garante des méthodes d'accés à un objet dont la classe implémente cette interface. On peut dire que l'implémentation d'une interface est une relation de type "possède les fonctionnalités de". D'ailleurs, les interfaces ont souvent des noms synonymes de "capable de" (en plus du 'I' qui commence généralement leur nom) : IDragable, IViewable, etc...
Par exemple, si l'on veut qu'un objet puisse être affiché, il est possible de créer une interface qui obligera la classe dont est issu l'objet d'implémenter une méthode display() ... Pour un objet qui doit pouvoir être déplacé par drag&drop, une interface pourra définir quelles sont les méthodes qui serviront à la manipuler pour cette tâche précise.
// Le replissage du reservoir possède une implémentation
// Par défaut
abstract class Vehicle {
private var $_maxFuel;
private var $_currentFuel;
// Méthode concrète
protected function fill($quantite) {
// Code pour remplir le réservoir
}
// Methode abstraite
// Les sous-classes devront l'implémenter
abstract public function start();
}
// Voiture
// Heritant de VahiculeAMoteur, on est obligé d'implémenter démarrer
// Si on ne le fait pas, une erreur va survenir
class Car extends Vehicle {
// Surcharge de la méthode abstraite
public function start() {
// Code pour démarrer la voiture
}
}// Interface définissant le comportement d'un objet
Utilisation
Les interfaces et classe abstraites n'ont un véritable sens que si elles sont associées à un langage typé fortement, ou du moins qui permet d'imposer un type d'objet dans les signatures de méthodes (comme le "type hint" de PHP5). En effet, plus qu'un "carcan" imposé au développeur de classes, elles sont surtout utiles aux classes clientes, qui vont avoir besoin d'être assurée d'un certain comportement des objets qu'elles vont utiliser.
En fait, pour pousser les choses plus loin, je dirait presque que pour une souplesse d'utilisation optimale, il ne faudrait utiliser que les interfaces et classes abstraites avec le typage fort. Il arrive souvent qu'un client ait besoin d'une implémentation précise, mais de toutes façons, le typage fort n'empêche pas une instance de sous-classe d'être utilisée, parfois avec une implémentation totalement différente.
Ainsi, quand une méthode va afficher un objet, elle n'a pas forcément besoin de savoir de quel type est cet objet, mais uniquement de savoir si l'objet est "affichable" ! Donc, si le fait d'être affichable revient à implémenter une interface qui demande à ce qu'une méthode display() soit présente, on utilisera cette interface pour le typage fort. Et l'objet passé à la méthode peut être de n'importe quel type, on est alors sûr qu'il disposera d'une méthode display(), dont la signature est définie par l'interface.
Prenons comme exemple une carte géographique. Cette carte est affichée en grand dans une fenêtre, et un ascenseur doit la déplacer. Pour cela, le déplacement de l'ascenseur recevra en paramètre l'objet qui représente la carte. Mais pour pouvoir la déplacer, il faut être certain que cette carte possède les méthodes qui vont nous permettre de la positionner. Il faut alors créer une interface imposant des méthodes d'accés. Ainsi, toute instance d'un classe qui implémente cette interface pourra être déplacée par l'ascenceur :
// que l'on peut déplacer à la souris
// Toute classe implémentant cette interface devra
// implémenter deux méthodes startDrag et stopDrag
interface IDragable {
public function startDrag():Void;
public function stopDrag():Void;
}
// Un curseur sur une jauge doit pouvoir
// être déplacé à la souris
class Cursor implements IDragable {
public function startDrag() {
// Code de début de déplacement
}
public function stopDrag() {
// Code de fin de déplacement
}
}// Interface de déplacement
interface IMovable {
// Positionnement de l'objet
public function moveToCoord(x:Number, y:Number);
// Déplacement de l'objet
public function moveByOffset(dx:Number, dy:Number);
}
// Classe d'une carte géographique
class Map implements IMovable {
// Clip correspondant à l'affichage de la carte
private var _targetMC:MovieClip;
// Methode de positionnement
public function moveToCoord(x:Number, y:Number) {
this._targetMC._x = x;
this._targetMC._y = y;
}
// Methode de déplacement
public function moveByOffset(dx:Number, dy:Number) {
this._targetMC._x += dx;
this._targetMC._y += dy;
}
}
// Scroller
class Scroller {
function moveObject(obj:IMovable) {
obj.moveByOffset(10,50);
}
}
Ainsi, la classe Scroller devient appliquable à n'importe quel objet qui possède les méthodes nécessaires à son déplacement. Il peut tout aussi biuen s'agir d'un dessin ou d'un texte. Ces classes n'ont rien à voir entre elles, mais leur comportement est unifié par l'utilisation de l'interface.
Conclusion
Comme vous pouvez le constater, les interfaces et classes abstraites offrent un moyen d'assouplir votre code, le rendant ainsi plus évolutif. Le fait d'utiliser un comportement et non plus une classe dans ses typages forts permet de généraliser une instruction à un ensemble bien plus large d'objets.
Alors que les interfaces sont souvent utilisées uniquement comme structure de classes lorsqu'on les connait peu, les associer au typage fort en font un outil trés puissant !
Connaître les 
Les spécifications du format SWF
v7 donnent l'implémentation de l'instruction extends en ActionScript
2:
Considérons que quelqu'un veut aller d'un point A à un opint
B. Considérons également qu'un mur est situé entre ces deux points. Cette
situation est illustrée par l'image ci-contre, où le point A (départ) est
affiché en vert, le point B (arrivée) est en rouge, et où les cases en bleu
représentent le mur.
A cette
étape, vous devriez avoir quelquechose comme l'image ci-contre. Sur ce schéma,
la carré vert foncé au centre est notre case de départ. Elle est entourée de
bleu clair pour signifier que la case a bien été ajoutée à notre "liste
fermée". Toutes les cases adjacentes sont maintenant dans la "liste ouverte" de
case à vérifier, et sont entourées de vert clair. Chacune d'elle possède une
"pointeur" vers son parent, qui n'est autre que la case de départ.
Le coût F est
calculé en ajoutant G et H. Vous pouvez constater le résultat sur le schéma
ci-contre. Les coûts F, G et H sont notés dans chaque case. Comme indiqué, F
est situé en haut à gauche, G en bas à gauche et H en bas à droite.
Bon, voyons
maintenant comment cela fonctionne. Sur nos 9 cases initiales, nous en avons 8
qui font partie de la "liste ouverte" aprés que la case de départ ait été
envoyée vers la "liste fermée". De ces 8 cases, celle ayant le coût F le plus
faible est celle qui se situe immédiatement à droite de la case de départ, avec
un coût F de 40. Donc, nous choisissons cette case comme étant la prochaine.
Elle est entourée en bleu dans l'illustration ci-contre.
Choisissons
la case située juste en dessous et à droite de la case de départ, comme
illustré dans le schéma ci-contre.
Nous allons
répeter ce processus jusqu'à ce que la case d'arrivée soit ajoutée à la "liste
fermée", ce qui nous donne quelque chose comme le schéma ci-contre.
Ce concept est trés important, car c'est lui qui garantit l'encapsulation de vos données, ainsi que leur intégrité, surtout lors de développements en travail collaboratif, ou chacun peut-être amené à utiliser les classes d'un autre.