Discussion :

[Laurent Dardenne]

Bonjour,
j'ai une question simple :
quand choisi-t-on d'utiliser une classe ou une interface en modélisation ?

J'ai trouvé sur DVP de nombreuses infos sur les interfaces mais autant la définition du concept de classe semble claire pour tous autant sur les interfaces le concept est plutôt flou, enfin à mon avis.

Merci.

[slim]

C'est dans le développement des applis réseaux. L'interface est mise sur le client et son implementation sur le serveur.
Si tu crees une classe tu dois mettre l'implementation avec. Sinon, sur l'interface, figurent que les entetes des methodes.

[Laurent Dardenne]

C'est dans le développement des applis réseaux.

Je ne suis certain que cela soit spécifique à ce besoin.
Merci pour ta réponse mais ma question demeure.

[MatRem]

Cette notion est lié au polymorphisme.

On choisit d'utiliser une interface quand on veut obliger à utiliser pour les classes derivées une certaine structure.
On ne connait pas le comportement qu'auront les instances.

Avec une classe on connait le comportement par defaut.
Les classes dérivées ne sont pas obligées de le specialiser.

Enfin tu as aussi la notion d'interface/classe abstraite.
L'une ne possede pas de donnees membres l'autre peut.
Tout les methodes de l'interface sont abstraites, par forcément pour la classe abstraite.


exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
classe Animal{
   void parler(); //Comportement par défaut: afficher "bonjour"
}
classe Vache -> Animal{
  //On n'est as obligé de redefinir le comportement de parler. Ici ce n'est pas optimal, aucun animal n'a le même cri.
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
interface Animal{
   abstraite void parler(); //On oblige a definir un comportement
}
classe Vache -> Animal{
  void parler(); //affichage de "Mheueue"
}

[MangeurVasqué]

Une interface est un contrat. Lorsqu'un objet client d'une interface collabore avec celle-ci, il ne connait pas son type réel mais il sait comment le "manipuler" (quels messages il peut lui envoyer).

Le but des interfaces est de diminuer le couplage entre deux classes. L'interface permet de ne présenter au client "que ce qui l'intéresse".
Une analogie : si tu veux conduire une voiture, ce qui t'intéresse c'est de démarrer, accélérer, freiner... Si tu es mécano, tu voudras certainement faire une vidange, équilibrer les roues... Ces 2 "groupes de comportement" peuvent définir respectivement une interface TableauDeBord et une autre AccesMaintenance (ce nom ne me satisfait pas trop, si vous avez une meilleure idée), qui sont deux visions partielles d'un véhicule.

Un autre aspect est la protection des variations. un objet client d'une interface peut collaborer avec n'importe quel type d'objet pourvu qu'il réalise l'interface. Si on reprend les voitures, tu apprends à conduire (tu connais TableauDeBord) sur une 205. Si du jour au lendemain on te donne à la place une Clio, tu pouras l'utiliser de la même manière.

La différence avec une classe abstraite est que le découplage est plus important. Par exemple (toujours les voitures) TableauDeBord te permet de jouer à Daytona USA alors que c'est un JeuVideo et pas un Vehicule

[Nip]

Pour aller dans le meme sens que MangeurVasqué si on prend la definition d'une interface en UML c'est un ensemble d'operations qui specifie le contrat ou service d'une classe.
C'est un concept tres proche du concept d'interface en Java ou .Net.

Apres quand l'utiliser en modelisation a la place des classes? Et bien je dirais que c'est surtout dans le cadre de la modelisation d'une appli ou l'on veut un decouplage maximal et une grande flexibilite; ce sont des composants dont les variations de code n’ont pas d’impact sur les classes utilisatrices, du coup si on utilise une interface a la place d'une classe, on peut modifier l'implementation sous jacente sans retoucher la ou les classes utilisatrices, l'interface fait office d'ecran.




Dans cet exemple, le changement d'implementation classeBase_1 vers classeBase_2 ou bien la modification de classeBase_1 est transparent: pas de modif a apporter a la classe utilisatrice. L'interface est la pour assurer cette flexibilite.
De la meme maniere si tu crees un composant (classeBase) destine a etre utilise par une autre appli et que tu veux faire evoluer ton composant (en le passant a une nouvelle version par exemple) alors il ne sera pas necessaire de recompiler la classe utilisatrice pour utiliser ce nouveau composant, l'interface faisant la transition.

En bref en utilisant une interface en UML tu definis une grande evolutivite de ton application avec un impact mineur sur les composants lies ou annexes, que ce soit la couche de presentation, la couche de services ou autre.

[Laurent Dardenne]

Merci pour ces infos, j'ai besoin de qq précisions sur le sens de qq termes utilisés :

(quels messages il peut lui envoyer).

Dans ce contexte considéres-tu l'appel d'une méthode comme un message(ex: méthode FaitqqChose )?

Le but des interfaces est de diminuer le couplage entre deux classes.

J'ai oublié la notion de couplage elle est liée à la notion de dépendance d'une classe par à rapport à une autre ?

Un autre aspect est la protection des variations.

Tu peux préciser le sens de variation je ne suis pas certain qu'il faille prendre ce terme dans son sens premier.

[Laurent Dardenne]

merci Nip, je vais réfléchir sur l'exemple que tu m'a donné, je vais essayé de construire le contraire, ie la modélisation qui limiterais l'évolution du composant.

[Hephaistos007]

Merci pour ces infos, j'ai besoin de qq précisions sur le sens de qq termes utilisés :

Dans ce contexte considéres-tu l'appel d'une méthode comme un message(ex: méthode FaitqqChose )?

Oui, les objets communiquent par envoi de message. Cela correspond aux appels de méthodes.

Par ailleurs, je confirme bien évidemment la notion de contrat que véhicule une interface, ainsi que la séparation nette des services et de leur implantation.

Par ailleurs, pour choisir rapidement s'il faut utiliser une interface ou non, je rajouterai la notion de capacité. C'est un moyen simple pour y penser.On retrouve bien cela dans les interfaces de l'API Java standard :

• Possède la capacité d'être imprimé : interface printable
• Possède la capacité d'être serialisé : interface serializable
• Possède la capacité d'être trié : interface sortable
• Possède la capacité d'être comparé : interface comparable
• etc...

Le suffixe "able" dénote bien une notion de capacité. J'ai d'ailleurs pris l'habitude de respecter ce nommage dans mes projets. Ex :

• Possède la capacité d'être exporté: interface exportable

[ego]

Histoire de mettre mon grain de sel...

Outre le fait que tu peux changer l'implémentation d'une interface utilisée par un client pour des raisons "fonctionnelles et/ou techniques" (genre passer d'un DAOOracle à un DAOMySQL), l'intérêt des interfaces est de d'abord réfléchir au contrat que l'on veut remplir.
Une fois ce contrat défini, le client du contrat peut aller faire son développement dans son coin et le développeur du dit contrat, celui qui va implémenter l'interface, peut lui aussi aller développer dans son coin. Ces 2 développeurs savent qu'ils pourront se rencontrer quand chacun aura fini son boulot et que le "raccord des prises" devrait se passer correctement.
Entre temps, le client du contrat pourra utiliser une implémentation bidon de l'interface, on parle alors de bouchon ou encore de mocked object chez les english, pour réaliser ses tests = faire semblant d'appeler l'implémentation de l'interface/contrat qui n'est pas encore finie.

Tu trouveras avec le framework SPRING une très très bonne aide pour utiliser ce principe de conception par interface.

[MangeurVasqué]

J'ai oublié la notion de couplage elle est liée à la notion de dépendance d'une classe par à rapport à une autre ?

Oui, c'est ça. Le degré de dépendance entre deux classes.

Tu peux préciser le sens de variation je ne suis pas certain qu'il faille prendre ce terme dans son sens premier.

Considère 2 sous-systèmes/composants/classes... qui collaborent. La protection des variations représente les moyens que tu va mettre en oeuvre afin que la modification d'un des sous-systèmes impacte le moins possible le second.
C'est ce que tu appelles "sens premier" ?

[Laurent Dardenne]

C'est ce que tu appelles "sens premier" ?

+- mais comme tu emplois le terme impacter, je comprend mieux.

Je vais laisser décanter tout ça (c'est pour un tuto sur les interfaces sous Delphi). Dans le livre "le guide de l'utilisateur UML" (chez Eyrolles) j'ai lu le chapitre consacré au interface mais avec vos explications je comprend mieux leur utilisation.

Je vous remercie pour votre aide .