Dynamic-Mess.com


"The world is a dynamic mess of jiggling things..."

Différence entre une classe abstraite et une interface

Article posté le 30-12-2013 dans la catégorie Développement

La classe abstraite

Comme vous avez pu le lire ici, une classe abstraite est une classe non instanciable, qui contient déja du code, et tout particulièrement des méthodes non implémentées(que la classe qui en héritera devra implémenter), ou des méthodes déja implémentées (factorisation de code, facilité de maintenance).

L'interface

L'interface est assez proche de la classe abstraite, mais aucune méthode n'est implémentée dedans. Il y a juste la déclaration (la signature) des méthodes. Ainsi, une classe qui implémente (on ne dit pas hériter) une interface, devra obligatoirement implémenter les méthodes. Ainsi, l'interface est une sorte de contrat : on présente les noms des méthodes (et ainsi souvent leur objectif) sans se soucier de la méthode dont elles seront implémentées.

L'une ou l'autre?

On peut donc dire qu'une interface est une classe totalement abstraite. Son rôle est donc de décrire un comportement pour notre objet instancié. Attention cependant, une interface ne doivent pas être confondue avec la notion d'héritage : l'héritage représente une évolution, un sous élément, par exemple "SUV" est une évolution de la classe "Voiture". Admettons qu'une classe 'Attaquant' soit une évolution de la classe "joueur de foot", 'Attaquant' et 'Suv' n'ont pas a avoir (logiquement) de classe mère de qui hériter. Par contre, une classe voiture et une classe joueur de foot peuvent tous deux bouger, ont peut donc imaginer une interface commune aux deux, d'autant plus que l'on peut coupler héritage (1 seul) avec interfaces (plusieurs).

Dépendances

Il est à noter que lorsque vous développez un module qui ne contiendrait que des classes abstraites, il faut faire en sorte que celui-ci n'ait pas de dépendances, et que ces soit les autres modules qui dépendant donc de lui. A l'inverse, un module qui utilisera des classes abstraites devra donc dépendre d'un module, mais aucun autre ne devra dépendre de lui.


Cet article vous a plu? Découvrez d'autres articles


Tweet
comments powered by Disqus