Bienvenue sur OpenClassrooms !

En poursuivant votre navigation, vous acceptez l'utilisation de OK

cookies. En savoir plus

Accueil Cours Apprenez programmer en Java Les classes abstraites et les interfaces

Apprenez programmer en Java

40 heures
Difficile Licence

Les classes abstraites et les interfaces

Nous voil de retour avec deux fondements du langage Java. Je vais essayer de faire simple : derrire ces
deux notions se cache la manire dont Java vous permet de structurer votre programme.

Grce aux chapitres prcdents, vous vous rendez compte que vos programmes Java regorgeront de
classes, avec de l'hritage, des dpendances, de la composition Afin de bien structurer vos
programmes (on parle d'architecture logicielle), vous allez vous creuser les mninges pour savoir o
ranger des comportements d'objets :

dans la classe mre ?

dans la classe fille ?

Comment obtenir une structure assez souple pour pallier les problmes de programmation les plus
courants ?
La rponse est dans ce chapitre.

Les classes abstraites

Une classe abstraite est quasiment identique une classe normale. Oui, identique aux classes que vous
avez maintenant l'habitude de coder. Cela dit, elle a tout de mme une particularit : vous ne pouvez pas
l'instancier ! Vous avez bien lu. Imaginons que nous ayons une classe A dclare abstraite. Voici un
code qui ne compilera pas :
java
Pour bien en comprendre l'utilit, il vous faut un exemple de situation (de programme, en fait) qui le
requiert. Imaginez que vous tes en train de raliser un programme qui gre diffrents types d'animaux
(oui, je sais : l'exemple est bte, mais il a le mrite d'tre simple comprendre).

Dans ce programme, vous aurez des loups, des chiens, des chats, des lions et des tigres. Mais vous n'allez
tout de mme pas faire toutes vos classes btement : il va de soi que tous ces animaux ont des points
communs ! Et qui dit points communs dit hritage. Que pouvons-nous dfinir de commun tous ces
animaux ? Le fait qu'ils aient une couleur, un poids, un cri, une faon de se dplacer, qu'ils mangent et
boivent quelque chose.

Nous pouvons donc crer une classe mre : appelons-la Animal . Avec ce que nous avons dgag de
commun, nous pouvons lui dfinir des attributs et des mthodes. La figure suivante reprsente nos
classes.

Classe Animal

Nous avons bien notre classe mre Animal et nos animaux qui en hritent. prsent, laissez-moi vous
poser une question. Vu que notre classe Animal est public , qu'est cens faire un objet Animal ?
Quel est son poids, sa couleur, que mange-t-il ? Je sais, cela fait plus qu'une question.

Si nous avons un morceau de code qui ressemble ceci :

java
Personnellement, je ne sais pas ce que mange un objet Animal . Vous conviendrez que toutes les
classes ne sont pas bonnes tre instancies !

C'est l qu'entrent en jeu nos classes abstraites. En fait, ces classes servent dfinir une superclasse : par
l, vous pouvez comprendre qu'elles servent essentiellement crer un nouveau type d'objets. Voyons
maintenant comment crer une telle classe.

Une classe Animal trs abstraite

En fait, il existe une rgle pour qu'une classe soit considre comme abstraite. Elle doit tre dclare
avec le mot cl abstract . Voici un exemple illustrant mes dires :
java

Une telle classe peut contenir la mme chose qu'une classe normale. Ses enfants pourront utiliser tous
ses lments dclars (attributs et mthodes dclars public ou protected , nous sommes
d'accord). Cependant, ce type de classe permet de dfinir des mthodes abstraites qui prsentent une
particularit: elle n'ont pas de corps ! En voici un exemple :
java

Vous voyez pourquoi on dit mthode abstraite : difficile de voir ce que cette mthode sait faire.

Retenez bien qu'une mthode abstraite n'est compose que de l'en-tte de la mthode suivie
d'un point-virgule ; .

Il faut que vous sachiez qu'une mthode abstraite ne peut exister que dans une classe abstraite. Si, dans
une classe, vous avez une mthode dclare abstraite, vous devez dclarer cette classe comme tant
abstraite.

Voyons quoi cela peut servir. Vous avez vu les avantages de l'hritage et du polymorphisme. Eh bien
nos classes enfants hriteront aussi des mthodes abstraites, mais tant donn que celles-ci n'ont pas
de corps, nos classes enfants seront obliges de redfinir ces mthodes ! Elles prsentent donc des
mthodes polymorphes, ce qui implique que la covariance des variables pointe nouveau le bout de son
nez :
java
 Attends ! Tu nous as dit qu'on ne pouvait pas instancier de classe abstraite !

Et je maintiens mes dires : nous n'avons pas instanci notre classe abstraite. Nous avons instanci un
objet Loup que nous avons mis dans un objet de type Animal (il en va de mme pour l'instanciation
de la classe Chien ). Vous devez vous rappeler que l'instance se cre avec le mot cl new . En aucun
cas, le fait de dclarer une variable d'un type de classe donn ici, Animal n'est une instanciation !
Ici, nous instancions un Loup et un Chien .

Vous pouvez aussi utiliser une variable de type Object comme rfrence un objet Loup , un objet
Chien etc. Vous saviez dj que ce code fonctionne :
java

En revanche, ceci pose problme :

java

Eh oui ! Nous essayons de mettre une rfrence de type Object dans une rfrence de type Loup :
pour avertir la JVM que la rfrence que vous voulez affecter votre objet de type Loup est un Loup ,
vous devez utiliser le transtypage ! Revoyons notre code :
java

Vous pouvez bien videmment instancier directement un objet Loup , un objet Chien , etc.

Pour le moment, nous n'avons de code dans aucune classe ! Les exemples que je vous ai fournis
ne font rien du tout, mais ils fonctionneront lorsque nous aurons ajout des morceaux de code
nos classes.
toffons notre exemple
Nous allons donc ajouter des morceaux de code nos classes. Tout d'abord, tablissons un bilan de ce
que nous savons :

Nos objets seront probablement tous de couleur et de poids diffrents. Nos classes auront donc le
droit de modifier ceux-ci.
Ici, nous partons du principe que tous nos animaux mangent de la viande. La mthode
manger() sera donc dfinie dans la classe Animal .
Idem pour la mthode boire() . Ils boiront tous de l'eau (je vous voyais venir).
Ils ne crieront pas et ne se dplaceront pas de la mme manire. Nous emploierons donc des
mthodes polymorphes et dclarerons les mthodes deplacement() et crier() abstraites
dans la classe Animal .

La figure suivante reprsente le diagramme des classes de nos futurs objets. Ce diagramme permet de
voir si une classe est abstraite : son nom est alors en italique.

Hirarchie de nos classes

Nous voyons bien que notre classe Animal est dclare abstraite et que nos classes filles hritent de
celle-ci. De plus, nos classes filles ne redfinissent que deux mthodes sur quatre, on en conclut donc
que ces deux mthodes doivent tre abstraites. Nous ajouterons deux constructeurs nos classes filles :
un par dfaut et un autre comprenant les deux paramtres d'initialisation. cela, nous ajouterons aussi
les accesseurs d'usage. Mais dites donc nous pouvons amliorer un peu cette architecture, sans pour
autant rentrer dans les dtails !

Vu les animaux prsents, nous aurions pu faire une sous-classe Carnivore , ou encore
AnimalDomestique et AnimalSauvage Ici, nous allons nous contenter de faire deux sous-
classes : Canin et Felin , qui hriteront d' Animal et dont nos objets eux-mmes hriteront !
Nous allons redfinir la mthode deplacement() dans cette classe, car nous allons partir du principe
que les flins se dplacent d'une certaine faon et les canins d'une autre. Avec cet exemple, nous
rviserons le polymorphisme. La figure suivante correspond notre diagramme mis jour (vous avez
remarqu ? J'ai ajout une mthode toString() ).

Nouvelle architecture des classes

Voici les codes Java correspondants.

Animal.java
java
Felin.java
java

Canin.java
java

Chien.java
java

Loup.java
java
Lion.java
java

Tigre.java
java

Chat.java
java
 Dis donc ! Une classe abstraite ne doit-elle pas comporter une mthode abstraite ?

Je n'ai jamais dit a ! Une classe dclare abstraite n'est pas instanciable , mais rien ne l'oblige
comprendre des mthodes abstraites. En revanche, une classe contenant une mthode abstraite doit
tre dclare abstraite ! Je vous invite maintenant faire des tests :
java

Le jeu d'essai de ce code correspond la figure suivante.

Test d'une classe abstraite

Dans la mthode toString() de la classe Animal , j'ai utilis la mthode getClass() qui
je vous le donne en mille se trouve dans la classe Object . Celle-ci retourne
class<nomdelaclasse> .
Dans cet exemple, nous pouvons constater que nous avons un objet Loup :

l'appel de la mthode boire() : l'objet appelle la mthode de la classe Animal .

l'appel de la mthode manger() : idem.
l'appel de la mthode toString() : idem.
l'appel de la mthode deplacement() : c'est la mthode de la classe Canin qui est
invoque ici.
l'appel de la mthode crier() : c'est la mthode de la classe Loup qui est appele.

Remplacez le type de rfrence (ici, Loup ) par Animal , essayez avec des objets Chien , etc. Vous
verrez que tout fonctionne.

Les interfaces

L'un des atouts majeurs pour ne pas dire l'atout majeur de la programmation oriente objet est la
rutilisabilit de vos objets. Il est trs commode d'utiliser un objet (voire une architecture) que nous
avons dj cr pour une nouvelle application.

Admettons que l'architecture que nous avons dveloppe dans les chapitres prcdents forme une
bonne base. Que se passerait-il si un autre dveloppeur vous demandait d'utiliser vos objets dans un
autre type d'application ? Ici, nous ne nous sommes occups que de l'aspect gnrique des animaux que
nous avons crs. Cependant, la personne qui vous a contact, elle, dveloppe une application pour un
chenil.

La contrainte principale, c'est que vos chiens devront apprendre faire de nouvelles choses telles que :

faire le beau ;
faire des clins ;
faire une lchouille .

Je ne vois pas le problme Tu n'as qu' ajouter ces mthodes dans la classe Animal !

Ouh l ! Vous vous rendez compte que vous obtiendrez des lions qui auront la possibilit de faire le beau
? Dans ce cas, on n'a qu' mettre ces mthodes dans la classe Chien , mais j'y vois deux problmes :

1. vous allez devoir mettre en place une convention de nommage entre le programmeur qui va
utiliser vos objets et vous. Vous ne pourrez pas utiliser la mthode faireCalin() , alors que le
programmeur oui ;
2. si vous faites cela, adieu au polymorphisme ! Vous ne pourrez pas appeler vos objets par le biais
d'un supertype. Pour pouvoir accder ces mthodes, vous devrez obligatoirement passer par
une rfrence un objet Chien . Pas terrible, tout a !
 Tu nous as dit que pour utiliser au mieux le polymorphisme, nous devions dfinir les mthodes
au plus haut niveau de la hirarchie. Alors du coup, il faut redfinir un supertype pour pouvoir
utiliser le polymorphisme !

Oui, et je vous rappelle que l'hritage multiple est interdit en Java. Et quand je dis interdit, je veux dire
que Java ne le gre pas ! Il faudrait pouvoir dvelopper un nouveau supertype et s'en servir dans nos
classes Chien . Eh bien nous pouvons faire cela avec des interfaces.

En fait, les interfaces permettent de crer un nouveau supertype; on peut mme en ajouter autant que
l'on le veut dans une seule classe ! Quant l'utilisation de nos objets, la convention est toute trouve.
Pourquoi ? Parce qu'une interface n'est rien d'autre qu'une classe 100 % abstraite ! Allez : venons-en aux
faits !

Votre premire interface

Pour dfinir une interface, au lieu d'crire :
java

il vous suffit de faire :

java

Voil : vous venez d'apprendre dclarer une interface. Vu qu'une interface est une classe 100 %
abstraite, il ne vous reste qu' y ajouter des mthodes abstraites, mais sans le mot cl abstract .

Voici des exemples d'interfaces :

java

java

Et pour faire en sorte qu'une classe utilise une interface, il suffit d'utiliser le mot cl implements . Ce
qui nous donnerait :
java
C'est tout. On dit que la classe X implmente l'interface I. Comme je vous le disais, vous pouvez
implmenter plusieurs interfaces, et voil comment a se passe :
java

Par contre, lorsque vous implmentez une interface, vous devez obligatoirement redfinir les mthodes
de l'interface ! Ainsi, le polymorphisme vous permet de faire ceci :
java

Implmentation de l'interface Rintintin

Voil o nous en sommes :

nous voulons que nos chiens puissent tre amicaux ;

nous voulons dfinir un supertype pour utiliser le polymorphisme ;
nous voulons pouvoir continuer utiliser nos objets comme avant.

Comme le titre de cette sous-section le stipule, nous allons crer l'interface Rintintin pour ensuite
l'implmenter dans notre objet Chien .
Sous Eclipse, vous pouvez faire File>New>Interface , ou simplement cliquer sur la flche noire
ct du C pour la cration de classe, et choisir interface , comme la figure suivante. Voici son
code :
java

Cration d'une nouvelle interface

prsent, il ne nous reste plus qu' implmenter l'interface dans notre classe Chien :
java
 L'ordre des dclarations est primordial. Vous devez mettre l'expression d'hritage avant
l'expression d'implmentation, sinon votre code ne compilera pas.

Voici un code que vous pouvez utiliser pour tester le polymorphisme de notre implmentation :
java

Objectif atteint ! Nous sommes parvenus dfinir deux superclasses afin de les utiliser comme
supertypes et de jouir pleinement du polymorphisme.

Dans la suite de ce chapitre, nous verrons qu'il existe une faon trs intressante d'utiliser les interfaces
grce une technique de programmation appele pattern strategy . Sa lecture n'est pas
indispensable, mais cela vous permettra de dcouvrir travers un cas concret comment on peut faire
voluer au mieux un programme Java.

Le pattern strategy

Nous allons partir du principe que vous avez un code qui fonctionne, c'est--dire un ensemble de classes
lies par l'hritage, par exemple. Nous allons voir ici que, en dpit de la puissance de l'hritage, celui-ci
atteint ses limites lorsque vous tes amens modifier la hirarchie de vos classes afin de rpondre
une demande (de votre chef, d'un client etc.).
Le fait de toucher votre hirarchie peut amener des erreurs indsirables, voire des absurdits : tout cela
parce que vous allez changer une structure qui fonctionne cause de contraintes que l'on vous impose.
Pour remdier ce problme, il existe un concept simple (il s'agit mme d'un des fondements de la
programmation oriente objet) : l'encapsulation !

Nous allons parler de cette solution en utilisant un design pattern (ou modle de conception en
franais). Un design pattern est un patron de conception, une faon de construire une hirarchie des
classes permettant de rpondre un problme. Nous aborderons le pattern strategy, qui va nous
permettre de remdier la limite de l'hritage. En effet, mme si l'hritage offre beaucoup de
possibilits, il a ses limites.

Posons le problme
Mettez-vous dans la peau de dveloppeurs jeunes et ambitieux d'une toute nouvelle socit qui cre des
jeux vido. Le dernier titre en date, Z-Army , un jeu de guerre trs raliste, a t un succs international
! Votre patron est content et vous aussi. Vous vous tes bass sur une architecture vraiment simple afin
de crer et utiliser des personnages, comme le montre la figure suivante.

Hirarchie des classes

Les guerriers savent se battre tandis que les mdecins soignent les blesss sur le champ de bataille. Et
c'est maintenant que commencent les ennuis !

Votre patron vous a confi le projet Z-Army 2 : The return of the revenge , et vous vous dites : Yes !
Mon architecture fonctionne merveille, je la garde. Un mois plus tard, votre patron vous convoque
dans son bureau et vous dit : Nous avons fait une tude de march, et il semblerait que les joueurs
aimeraient se battre aussi avec les mdecins ! Vous trouvez l'ide sduisante et avez dj pens une
solution : dplacer la mthode combattre() dans la superclasse Personnage , afin de la redfinir
dans la classe Medecin et jouir du polymorphisme ! La figure suivante schmatise le tout.
 Dplacement de la mthode combattre()

la seconde tude de march, votre patron vous annonce que vous allez devoir crer des civils, des
snipers, des chirurgiens etc. Toute une panoplie de personnages spcialiss dans leur domaine, comme
le montre la figure suivante.

Nouveaux personnages spcialiss

Le code source de ces classes

Personnage.java
java
Guerrier.java
java

Medecin.java
java

Civil.java
java

Chirurgien.java
java
Sniper.java
java

ce stade, vous devriez remarquer que :

le code contenu dans la mthode seDeplacer() est dupliqu dans toutes les classes ; il est
identique dans toutes celles cites ci-dessus ;
le code de la mthode combattre() des classes Chirurgien et Civil est lui aussi
dupliqu !

La duplication de code est une chose qui peut gnrer des problmes dans le futur. Je m'explique.

Pour le moment, votre chef ne vous a demand que de crer quelques classes supplmentaires. Qu'en
serait-il si beaucoup de classes avaient ce mme code dupliqu ? Il ne manquerait plus que votre chef
vous demande de modifier nouveau la faon de se dplacer de ces objets, et vous courrez le risque
d'oublier d'en modifier un. Et voil les incohrences qui pointeront le bout de leur nez !

No problemo ! Tu vas voir ! Il suffit de mettre un comportement par dfaut pour le dplacement
et pour le combat dans la superclasse Personnage .

Effectivement, votre ide se tient. Donc, cela nous donne ce qui suit :

Personnage.java
java
Guerrier.java
java

Medecin.java
java

Civil.java
java

Chirurgien.java
java

Sniper.java
java

Voici une classe contenant un petit programme afin de tester nos classes :
java
Le rsultat correspond la figure suivante.

Rsultat du code

Apparemment, ce code vous donne ce que vous voulez ! Mais une chose me chiffonne : vous ne pouvez
pas utiliser les classes Medecin et Chirurgien de faon polymorphe, vu que la mthode
soigner() leur est propre ! On pourrait dfinir un comportement par dfaut (ne pas soigner) dans la
superclasse Personnage et le tour serait jou.
java
Au mme moment, votre chef rentre dans votre bureau et vous dit : Nous avons bien rflchi, et il serait
de bon ton que nos guerriers puissent administrer les premiers soins. ce moment prcis, vous vous
dlectez de votre capacit d'anticipation ! Vous savez que, maintenant, il vous suffit de redfinir la
mthode soigner() dans la classe concerne, et tout le monde sera content !

Seulement voil ! Votre chef n'avait pas fini son speech : Au fait, il faudrait affecter un comportement
nos personnages en fonction de leurs armes, leurs habits, leurs trousses de soin Enfin, vous voyez ! Les
comportements figs pour des personnages de jeux, de nos jours, c'est un peu ringard !

Vous commencez voir ce dont il retourne : vous devrez apporter des modifications votre code, encore
et encore. Bon : pour des programmeurs, cela est le train-train quotidien, j'en conviens. Cependant, si
nous suivons les consignes de notre chef et que nous continuons sur notre lance, les choses vont se
compliquer.

Un problme supplmentaire
Attelons-nous appliquer les modifications dans notre programme. Selon les directives de notre chef,
nous devons grer des comportements diffrents selon les accessoires de nos personnages : il faut
utiliser des variables d'instance pour appliquer l'un ou l'autre comportement.

Afin de simplifier l'exemple, nous n'allons utiliser que des objets String .

La figure suivante correspond au diagramme des classes de notre programme.

Modification de nos classes

Vous avez remarqu que nos personnages possderont des accessoires. Selon ceux-ci, nos personnages
feront des choses diffrentes. Voici les recommandations de notre chef bien-aim :
 le guerrier peut utiliser un couteau, un pistolet ou un fusil de sniper ;
le sniper peut utiliser son fusil de sniper ainsi qu'un fusil pompe ;
le mdecin a une trousse simple pour soigner, mais peut utiliser un pistolet ;
le chirurgien a une grosse trousse mdicale, mais ne peut pas utiliser d'arme ;
le civil, quant lui, peut utiliser un couteau seulement quand il en a un ;
tous les personnages hormis le chirurgien peuvent avoir des baskets pour courir;

Il va nous falloir des mutateurs (inutile de mettre les mthodes de renvoi ( getXXX ), nous ne nous
servirons que des mutateurs !) pour ces variables, insrons-les dans la superclasse ! Bon ! Les
modifications sont faites, les caprices de notre cher et tendre chef sont satisfaits ? Voyons cela tout de
suite.

Personnage.java
java

Guerrier.java
java
Sniper.java
java

Civil.java
java

Medecin.java
java
Chirurgien.java
java

Voici un programme de test :

java

Le rsultat de ce test se trouve la figure suivante.

 Rsultat du test d'accessoires

Vous constatez avec merveillement que votre code fonctionne trs bien. Les actions par dfaut sont
respectes, les affectations d'actions aussi. Tout est parfait !

Vraiment ? Vous tes srs de cela ? Pourtant, je vois du code dupliqu dans certaines classes ! En plus,
nous n'arrtons pas de modifier nos classes. Dans le premier opus de Z-Army , celles-ci fonctionnaient
pourtant trs bien ! Qu'est-ce qui ne va pas ?

L-dessus, votre patron rentre dans votre bureau pour vous dire : Les actions de vos personnages
doivent tre utilisables la vole et, en fait, les personnages peuvent trs bien apprendre au fil du jeu.
Les changements s'accumulent, votre code devient de moins en moins lisible et rutilisable, bref c'est
l'enfer sur Terre.

Faisons un point de la situation :

du code dupliqu s'insinue dans votre code ;

 chaque modification du comportement de vos personnages, vous tes obligs de retoucher le
code source de la (ou des) classe(s) concerne(s) ;
votre code perd en rutilisabilit et du coup, il n'est pas extensible du tout !

Une solution simple et robuste : le pattern strategy

Aprs toutes ces motions, vous allez enfin disposer d'une solution ce problme de modification du
code source ! Si vous vous souvenez de ce que j'ai dit, un des fondements de la programmation oriente
objet est l'encapsulation.

Le pattern strategy est bas sur ce principe simple. Bon, vous avez compris que le pattern strategy
consiste crer des objets avec des donnes, des mthodes (voire les deux) : c'est justement ce qui
change dans votre programme !

Le principe de base de ce pattern est le suivant : isolez ce qui varie dans votre programme et
encapsulez-le !

Dj, quels sont les lments qui ne cessent de varier dans notre programme ?

La mthode combattre() .
La mthode seDeplacer() .
La mthode soigner() .

Ce qui serait vraiment grandiose, ce serait d'avoir la possibilit de ne modifier que les
comportements et non les objets qui ont ces comportements ! Non ?

L, je vous arrte un moment : vous venez de fournir la solution. Vous avez dit : ce qui serait vraiment
grandiose, ce serait d'avoir la possibilit de ne modifier que les comportements et non les objets qui ont
ces comportements .

Lorsque je vous ai prsent les diagrammes UML, je vous ai fourni une astuce pour bien diffrencier les
liens entre les objets. Dans notre cas, nos classes hritant de Personnage hritent aussi de ses
comportements et, par consquent, on peut dire que nos classes filles sont des Personnage .

Les comportements de la classe mre semblent ne pas tre au bon endroit dans la hirarchie. Vous ne
savez plus quoi en faire et vous vous demandez s'ils ont vraiment leur place dans cette classe ? Il vous
suffit de sortir ces comportements de la classe mre, de crer une classe abstraite ou une interface
symbolisant ce comportement et d'ordonner votre classe Personnage d'avoir ces comportements.
Le nouveau diagramme des classes se trouve sur la figure suivante.
 Nouveau diagramme des classes

Vous apercevez une nouvelle entit sur ce diagramme, l'interface, facilement reconnaissable, ainsi
qu'une nouvelle flche symbolisant l'implmentation d'interface entre une classe concrte et une
interface. N'oubliez pas que votre code doit tre souple et robuste et que mme si ce chapitre vous
montre les limites de l'hritage le polymorphisme est inhrent l'hritage (ainsi qu'aux
implmentations d'interfaces).

Il faut vous rendre compte qu'utiliser une interface de cette manire revient crer un supertype de
variable ; du coup, nous pourrons utiliser les classes hritant de ces interfaces de faon polymorphe sans
nous soucier de savoir la classe dont sont issus nos objets ! Dans notre cas, notre classe Personnage
comprendra des objets de type EspritCombatif , Soin et Deplacement !

Avant de nous lancer dans le codage de nos nouvelles classes, vous devez observer que leur nombre a
considrablement augment depuis le dbut. Afin de pouvoir gagner en clart, nous allons grer nos
diffrentes classes avec diffrents packages .

Comme nous l'avons remarqu tout au long de ce chapitre, les comportements de nos personnages sont
trop pars pour tre dfinis dans notre superclasse Personnage . Vous l'avez dit vous-mmes : il
faudrait que l'on ne puisse modifier que les comportements et non les classes hritant de notre
superclasse !
Les interfaces nous servent crer un supertype d'objet ; grce elles, nous utiliserons des objets de
type :

EspritCombatif qui prsentent une mthode combat() ;

Soin qui prsentent une mthode soigne() ;
Deplacement qui prsentent une mthode deplace() .

Dans notre classe Personnage , nous avons ajout une instance de chaque type de comportement,
vous avez d les remarquer : il y a ces attributs dans notre schma ! Nous allons dvelopper un
comportement par dfaut pour chacun d'entre eux et affecter cet objet dans notre superclasse. Les
classes filles, elles, comprendront des instances diffrentes correspondant leurs besoins.

Du coup, que fait-on des mthodes de la superclasse Personnage ?

Nous les gardons, mais plutt que de redfinir ces dernires, la superclasse va invoquer la mthode de
comportement de chaque objet. Ainsi, nous n'avons plus redfinir ou modifier nos classes ! La seule
chose qu'il nous reste faire, c'est d'affecter une instance de comportement nos objets. Vous
comprendrez mieux avec un exemple. Voici quelques implmentations de comportements.

Implmentations de l'interface EspritCombatif

java

java

java

Implmentations de l'interface Deplacement

java

java
Implmentations de l'interface Soin
java

java

java

La figure suivante reprsente ce que vous devriez avoir dans votre nouveau package.
 Package des comportements

Maintenant que nous avons dfini des objets de comportements, nous allons pouvoir remanier notre
classe Personnage . Ajoutons les variables d'instance, les mutateurs et les constructeurs permettant
d'initialiser nos objets :
java
Que de changements depuis le dbut ! Maintenant, nous n'utilisons plus de mthodes dfinies dans
notre hirarchie de classes, mais des implmentations concrtes d'interfaces ! Les mthodes que nos
objets appellent utilisent chacune un objet de comportement. Nous pouvons donc dfinir des guerriers,
des civils, des mdecins tous personnalisables, puisqu'il suffit de modifier l'instance de leur
comportement pour que ceux-ci changent instantanment. La preuve par l'exemple.

Je ne vais pas vous donner les codes de toutes les classes. En voici seulement quelques-unes.

Guerrier.java
java

Civil.java
java

Medecin.java
java
Maintenant, voici un exemple d'utilisation :
java

Le rsultat de ce code nous donne la figure suivante.

Test du pattern strategy

Vous pouvez voir que nos personnages ont tous un comportement par dfaut qui leur convient bien !
Nous avons spcifi, dans le cas o cela s'avre ncessaire, le comportement par dfaut d'un
personnage dans son constructeur par dfaut :

le guerrier se bat avec un pistolet ;

le mdecin soigne.
Voyons maintenant comment indiquer nos personnages de faire autre chose. Eh oui, la faon dont
nous avons arrang tout cela va nous permettre de changer dynamiquement le comportement de
chaque Personnage . Que diriez-vous de faire faire une petite opration chirurgicale notre objet
Guerrier ?

Pour ce faire, vous pouvez redfinir son comportement de soin avec son mutateur prsent dans la
superclasse en lui passant une implmentation correspondante !
java

En testant ce code, vous constaterez que le comportement de soin de notre objet a chang
dynamiquement sans que nous ayons besoin de changer la moindre ligne de son code source ! Le plus
beau dans le fait de travailler comme cela, c'est qu'il est tout fait possible d'instancier des objets
Guerrier avec des comportements diffrents.

Une classe est dfinie comme abstraite avec le mot cl abstract .

Les classes abstraites sont utiliser lorsqu'une classe mre ne doit pas tre instancie.
Une classe abstraite ne peut donc pas tre instancie.
Une classe abstraite n'est pas oblige de contenir de mthode abstraite.
Si une classe contient une mthode abstraite, cette classe doit alors tre dclare abstraite.
Une mthode abstraite n'a pas de corps.
Une interface est une classe 100 % abstraite.
Aucune mthode d'une interface n'a de corps.
Une interface sert dfinir un supertype et utiliser le polymorphisme.
Une interface s'implmente dans une classe en utilisant le mot cl implements .
Vous pouvez implmenter autant d'interfaces que vous voulez dans vos classes.
Vous devez redfinir toutes les mthodes de l'interface (ou des interfaces) dans votre classe.
Le pattern strategy vous permet de rendre une hirarchie de classes plus souple.
Prfrez encapsuler des comportements plutt que de les mettre d'office dans l'objet concern.

J'ai termin ce chapitre et je passe au suivant

Les packages Les exceptions

 Le professeur
Cyrille Herby
Spcialiste en dveloppement Java et curieux insatiable dinformatique et de programmation web.
Actuellement auditeur en scurit.

Dcouvrez aussi ce cours en...

Premium
eBook Livre papier PDF

OpenClassrooms Professionnels En plus

Qui sommes-nous ? Affiliation Crer un cours
Fonctionnement de nos coursPartenaires CourseLab
Recrutement For Business Conditions Gnrales d'Utilisation
Nous contacter Suivez-nous
Le blog OpenClassrooms

English Espaol