Accueil
 Sommaire
 1  Objectifs de ce cours de modélisation orientée objet
 2  Généralités sur la modélisation orienté objet et sur UML
 3  Analyse, vues cas d'utilisation et processus
 4  Analyse et conception, aspects statiques de la vue logique
 4.1  Diagrammes communs à l'analyse et à la conception
 4.2  Diagramme de classes
 4.3  Diagramme d'objets
 QCM
 4.4  Concepts avancés du diagramme de classes
 4.4.1  Navigabilité
 4.4.2  Classe d'association
 4.4.3  Composition: agrégation forte
 4.4.4  Classe abstraite
 4.4.5  Interface
 4.4.6  Classe paramétrée / générique
 4.4.7  Exemple de diagramme de classes avancé
 5  Analyse et conception, aspects dynamiques de la vue logique
 6  Conception, aspects langage et technique
 7  Conception, vues développement et physique
 8  Conclusion
 9  Bibliographie

 Contacts

W3C validator

Département INF  
 Conception et programmation orientées objet


4.4.5 Interface
  • Une interface n’est pas une classe, c’est une liste d’opérations
  • Une interface, comme une classe abstraite, ne peut pas servir à créer un objet
  • Une interface exprime un savoir-faire, un contrat à respecter par les classes qui « réalisent » cette interface

Figures/interface

    précédent     suivant 


Une interface permet de décrire le comportement d’une classe, c’est-à-dire un savoir-faire sous la forme d’une liste de déclarations d’opérations sans leur définition. Une interface ne peut donner lieu à aucune instance. Toutes les opérations d’une interface sont abstraites. Ainsi, une interface est équivalente à une classe abstraite, avec la particularité supplémentaire qu’une interface ne possède pas d’attribut15. Une classe peut déclarer qu’elle « réalise » une interface, c’est-à-dire qu’elle définit un corps à toutes les opérations abstraites de l’interface. Une telle classe peut ensuite être utilisée partout où un objet respectant le contrat de l’interface est attendu. Si une classe ne réalise pas toutes les opérations abstraites de l’interface, alors cette classe est abstraite. Une classe enfant de cette dernière classe peut compléter la concrétisation en définissant les dernières opérations abstraites ; la classe enfant devient alors concrète.

Le lien de réalisation qui est aussi (de manière non adéquate) appelé lien d’implantation entre une classe abstraite et une classe concrète est modélisé similairement au lien d’héritage, la différence étant le trait qui est en pointillé. Il est possible de spécifier des hiérarchies d’interfaces, ainsi que des hiérarchies impliquant des interfaces, des classes abstraites et des classes concrètes. Bien sûr, dans de telles hiérarchies, une interface ne peut pas hériter d’une classe, qu’elle soit abstraite ou concrète ; c’est toujours l’inverse, c’est-à-dire une classe abstraite ou concrète réalisant le contrat d’une interface, qui peut être dessinée.

Voici dans le diagramme qui suit une autre notation UML de l’interface. Dans la suite, nous utilisons de préférence la première forme.

Figures/interface_autre_representation

Enfin, le schéma suivant montre l’utilisation d’une interface. Une Personne et un Polygone réalisent les opérations déclarées dans l’interface Déplaçable.

Figures/interface_utilisation

D. Conan, C. Taconet, C. Bac, Télécom SudParis, CSC 4002, Octobre 2014

15.Cependant, dans certains langages de programmation orientés objet comme Java, les interfaces peuvent contenir des attributs qui sont alors des constantes.