Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
[POO] Classes abstraites ou interfaces
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
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).
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.
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.
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
Ah bon ?Envoyé par berceker united
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 ?
Je parlais des interfaces en PHP pas des spécificités des interfaces pour tel ou tel language. En php, qu'il soit là ou pas ça ne change rien si l'application est en production.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 ?
Dans une boite dans laquelle j'ai travaillé en Off, l'application en production avait les interfaces qui sont automatiquement retiré. Ils existe seulement en mode développement. Pour des raisons d'optimisation car la partie métier est sur une librairie php. Et avec une appli qui tourne sur 128 classes ça se fait vite sentire. L'équipe avait une personne dédier qu'au interfaces mitonné au petit oignons.
C'est vrai, et c'est là qu'on atteint la limite des langages de script par rapport aux langages compilés.
S'il est vrai que ça peut tirer les perfs vers le bas, il est rare qu'un particulier ait une appli de plus d'une centaine de classes. Il est aussi rare qu'il applique des design patterns, donc mon exemple était juste pour prendre un contrepied.
Il y a néammoins un point en faveur du typage fort et donc des interfaces en php5, car nous pouvons maintenant typer les paramètres de fonctions, ce qui permet d'éviter les erreurs d'appel.
Et enfin, je dirais que si tu privilégies les perfs à la maintenance et à la modularité, il ne faut alors pas utiliser la POO du tout. Le développement procédural est encore plus rapide.
Bien sûr je suis encore l'avocat du diable...
Dans le cas ou je me trouvais, nous avions beaucoup trop d'interface à mon goût mais comme les développeurs était pas réunient géographiquement. Il fallait mettre de forte contrainte d'où le nombre d'interface. Après au niveau de la mise un script à balayé les appelles des interfaces.C'est vrai, et c'est là qu'on atteint la limite des langages de script par rapport aux langages compilés.
S'il est vrai que ça peut tirer les perfs vers le bas, il est rare qu'un particulier ait une appli de plus d'une centaine de classes. Il est aussi rare qu'il applique des design patterns, donc mon exemple était juste pour prendre un contrepied.
Il y a néammoins un point en faveur du typage fort et donc des interfaces en php5, car nous pouvons maintenant typer les paramètres de fonctions, ce qui permet d'éviter les erreurs d'appel.
Et enfin, je dirais que si tu privilégies les perfs à la maintenance et à la modularité, il ne faut alors pas utiliser la POO du tout. Le développement procédural est encore plus rapide.
Bien sûr je suis encore l'avocat du diable...
Répondre avec citation
Partager