Discussion :

[Kapha]

Bonjour,je suis débutant en POO et je me demandé dans quel cas de figure faut il privilégier les classes abstraites au interfaces et vice versa?
Pour l'instant je serais tenté d'utiliser seulement des interfaces car on peut en implémenter plusieurs pour une même classe.
Merci de me faire partager votre expérience

[Benjimo]

Personnelement j'utilise une classe abstraite quand cela a une signification et que des données seront ensuite communes aux classes filles. (ex: Classe abstraite Polygone. Derivée en classe Quadrilatere , Triangle etc...).

J'utiliserais plutôt une interface pour permettre à une classe d'hériter d'autres méthodes qui n'étaient pas dans sa classe mère et qu'elle partage avec une ou plusieurs autres classes. (de l'heritage multiple en quelque sorte).

[s.n.a.f.u]

Il n'y a pas de règles, tout dépend de ton architecture.

Ceci dit, je trouve qu'il faut préférer la composition à l'héritage, aussi mon conseil sera très simple : utilise les classes abstraites (héritage) quand tu ne peux pas le faire par interface (composition).

Renseignes-toi sur les fameux design patterns, et tu aura sûrement une vision plus claire de la différence d'utilisation.

[Yoshio]

Il y a quand même des différences notables entre une classe abstraite et une interface.

Une classe abstraite sert de classe de base à des classes plus spécialisées comme l'a dit Benjimo avec son exemple. Une classe abstraite ne sera jamais instanciée. Un classe abstraite contient des méthodes implémentées qui sont communes à d'autres classes filles.

Une interface n'a pas du tout ce but. Une interface sert uniquement à définir les prototypes de méthode (donc pas de code dans cette classe, juste les prototypes de fonction) qui devront obligatoirement être redéfinie dans les classe qui implémente cette interface.

[berceker united]

Je completerais ce que dit Yoshio, qu'une interface est une sortie de classe certifier conforme.
Je vais prendre l'exemple d'une entreprise qui veut être certifié ISO. Ce qui veut dire qu'elle à une methode de fonctionnement répondant à des règles qui permette d'améliorer ses performances. Donc il demande à une entreprise exterieur de regarder ses methode de travail, l'audit. Si c'est bon, la boite est certifié ISO. Dans le cas contraire elle demande de s'améliorer.

Pour les Interfaces, c'est un peut pret la même chose. Dans cette classe il y a un certain nombre de chose de définies. Si vous voulez être sur que votre classe normal soit conforme vous le faite relié à une interface. Ainsi, s'il y a un os il va de suite vous taper sur les doigts.

C'est pour cela qu'une Interface doit être définie à l'avance avec le plus grand recule. Ainsi, vous ne risquez pas d'oublier des choses dans les classes. En soit une Interface ne sert strictement à rien pour l'application mais juste à aider le developpeur

[s.n.a.f.u]

En soit une Interface ne sert strictement à rien pour l'application mais juste à aider le developpeur

Ah bon ?

Prenons le pattern Strategy, un des plus utilisé et pourtant parmi les plus simples. Il est basé sur la puissance des interfaces pour des langages fortement typés tels que Java ou C#.

Il permet de déclarer une variable de type interface, qui peut représenter un objet dont le type implémente cette interface. La classe de la varibale peut même changer pendant le runtime du moment qu'elle implémente l'interface.
Je ne trouve pas que cela ne sert à rien... Non ?