Interface ou classe abstraite ?

Bonjour à tous,

Je ne sais pas si c'est mieux de poster cette question sur le forum de Conception ou ici, mais comme il est question d'interface et que ce n'est pas applicable à tous les langages, je vais la poser ici.

Je dois écrire un programme qui gère des utilisateurs, et ces utilisateurs peuvent se connecter au système avec une licence. Il existe 3 types de licence.

J'imagine donc ici une classe Utilisateur qui contiendra une (et une seule) licence.

Étant donné qu'il existe trois types de licences, je crois que je dois abstraire et me créer une classe abstraite / interface Licence. Mes trois types de licence hériteront de cette classe abstraite / interface. Je pourrai donc créer une licence d'un type précis pour chaque utilisateur, et du même coup, je n'ai pas à me soucier du type de licence si je dois toutes les mettre dans une collection.

Mon problème à l'heure actuelle est que j'ai du mal à différencier classe abstraite et interface, à part le fait qu'une interface oblige une implémentation de la part des classes qui s'en servent. (Bref, une classe qui implémente une interface n'HÉRITE pas vraiment mais implémente).

J'aimerais juste savoir dans quel(s) cas il est mieux de créer des classes abstraites. Dans ce cas-ci, je ne suis vraiment pas certain.

Merci de votre aide.

ça dépend de ce que contient License (champs, méthodes, propriétés, etc.) et de ce que tu comptes en faire.

Sur un système donné, il y a un nombre limité pour chaque type de licence. Je veux être capable de connaître le nombre restant de licences de chaque type, quand un utilisateur en occupe une. Je veux aussi être capable de regrouper les utilisateurs par type de licence en vue d'affichage à l'utilisateur.

La licence elle-même n'a pas vraiment de méthodes, elle existe tout simplement et elle fait partie d'une collection de nombre limité de licences.

(Eh oui, tout était clair avant que je commence à lire sur les Design Patterns, maintenant je suis vraiment mêlé !) :-(

Une interface ne peut contenir que des méthodes (uniquement leur signature, pas de code), des propriétés, des évènement et des indexeurs.

Donc si tu veux créer une classe avec des champs et des méthodes qui contienent déjà du code et faire dériver d'autres classes de cette classe, utilise une classe abstraite.

Merci pour la réponse rapide :-)

Pour faire plus simple :
Si t'as des variables en commun pour chaque type de licence (exemple : elles ont un nom, une valeur, ce que tu veux...), autant utilise une classe abstraite qui gerera les fonctions de base d'une licence...

Citation:

---

Envoyé par cobolfingaz

Mon problème à l'heure actuelle est que j'ai du mal à différencier classe abstraite et interface, à part le fait qu'une interface oblige une implémentation de la part des classes qui s'en servent. (Bref, une classe qui implémente une interface n'HÉRITE pas vraiment mais implémente).

---

Une interface n'est ni plus ni moins qu'une classe dont toutes les méthodes sont abstraites.

Ainsi, une interface intervient plutôt dans le découplage entre un contrat de service et son (ses) implémentation(s), tandis qu'une classe abstraite permet de factoriser une ou plusieurs méthodes de ses classes dérivées.
Dans certains langages, il n'est pas possible d'étendre plusieurs classes alors que plusieurs interfaces peuvent être implémentées. Dans le cas d'héritages multiples on peut donc par exemple également retrouver l'utilisation d'interfaces.

Un peu plus d'informations sur ce lien : http://www2.lifl.fr/~bogaert/clfc/polyDurif/node40.html