Allez, je me décide à poster !
 
En cours, on est en train d'apprendre la programmation objet en C++.
L'intervenant nous a parlé des classes abstraites et des interfaces, mais il a été assez succint à ce sujet. Et j'avoue que j'ai du mal à cerner la différence entre les deux, vu que ni l'un ni l'autre ne contient de code, ce sont juste des déclarations.
 
Et leur utilité ? L'intervenant nous a expliqué que les interfaces étaient surtout utilisées en Java, mais j'avoue que je vois mal à quoi elles peuvent servir, vu qu'elles ne contiennent aucun code !
 
Pouvez vous m'éclairer ?
Merci

y a pas d'interface en C++. les interfaces sont la solution de Java pour essayer de pallier à son incapacité à gérer l'héritage multiple

D'accord, mais dans l'absolu, ça sert à quoi ? Car même s'il n'y a pas d'interface en C++, il existe les classes abstraites, qui sont, d'après ce que j'ai compris, la même chose.
Quelle est l'utilité de classes qui ne contiennent aucun code, que ce soit en Java ou en C++ ?

à définir un contrat que doit satisfaire la classe que tu implémente : elle doit fournir les services spécifiés par l'interface.  
 
par rapport à l'héritage, une interface/classe abstraite représente une classe insuffisament définie pour être instanciée

Définir un contrat. La classe doit pouvoir faire telle ou telle chose
Un véhicule, que ce soit un camion ou une charette, faut pouvoir accélérer, freiner, tourner.
Si tu fais une interface, (sans code, donc), ben t'as pas besoin de savoir dans quel type de véhicule tu es pour le conduire
 
edit : toasté.

Une classe abstraite peut implémenter plusieurs interfaces...

Ok, je commence a voir le principe.
Si j'ai une classe MonObjet, qui implémente l'interface IMonObjet, je pourrais écrire :
 
IMonObjet obj = new MonObjet();
 
Ainsi, si jamais la classe MonObjet change, à partir du moment où elle implémente l'interface, je n'ai pas à me soucier de son fonctionnement interne à partir du moment où j'appelle les fonctions qui sont déclarées dans l'interface, c'est ça ?
 
Je vois le principe... Effectivement, ça permet d'éviter de réécrire du code.
 
Merci à vous

Elle a tout compris

 
L'héritage multiple est la solution du C++ pour pallier son incapacité à gerer des interfaces.

J'avais pas osé

 
y a des jours vaut mieux etre sourd  

IMonObjet* obj = new MonObjet();
 
Tu ne peux instancier un IMonObjet si c'est une classe abstraite, mais tu le peux avec un pointeur ou une référence.

 
Pas que de Java... de Delphi aussi
(puis les interfaces c'est pratique, en Delphi elles sont garbagecollectorées, contrairement aux objets issus de classes)

 
Ouais enfin c'est pas vraiment un garbage collector en fait
C'est juste un compteur de références, comme pour les AnsiString/WideString.
On ne doit pas se soucier de la désallocation quoi

 
Dans le même temps, se soucier de la désalocation de trucs qui ne s'alloue pas  
 

En Delphi pour utiliser les interfaces, tu les associes à une classe (héritage multiple vu que tu peux en associer plusieurs à une classe), et tu ne dois pas t'occuper de la désallocation des objets issus de cette classe
 
Enfin... il me semble

 
En françait, on appelle cela un lien d'implémentation ou de réalisation.

Fallait oser

 
Benh ça reste des interfaces

Il y a quand même quelque chose qui me tracasse.
Je reprends l'exemple du véhicule. Mettons que j'ai une interface IVoiture, qui déclare 2 fonctions : accelerer() et freiner().
Je créé une classe GolfGTI qui implémente IVoiture. Cette classe implémente donc accelerer() et freiner(), mais aussi brancheLaClim(), qui n'est pas déclarée dans IVoiture.
Si je fais ça :

je ne peux pas utiliser la fonction brancheLaClim(), vu que c'est un onjet IVoiture ?

ben non tu pourras pas.

tu peux mettre un virtual brancheLaClim() {}; dans ta classe IVoiture, histoire de pouvoir utiliser la fonction, sans pour autant qu'elle soit obligatoire dans tous les véhicules dérivés de IVoiture : ceux qui ne redéfinissent pas la fonction, ben ça fera rien quand tu appellera brancheLaClim(). et sinon, quand tu met "IVoiture maVoiture = new GolfGTI();", c'est du C++ ou du java ? parce que si c'est du C++, maVoiture doit être un pointeur... (en java, je connait pas grand chose)

En JAVA, si une fonction est virtuele, il faut l'implémenter dans toutes les sous-classes, même si c'est bidon.
 

Oui, ca semble plus propre que d'insérer du code vide dans l'interface.

Interface même combat : si tu veux implémenter une interface, il faut implémenter toutes les fonctions.

Oui effectivement c'est du C++, désolée pour le pointeur.
Merci pour ta réponse, je vais creuser les fonctions virtuelles.

Moi ça me pose un sérieux problème de conception.
Je mettrais plutot ça dans une 2° interface. A priori, le code qui gère l'accélération et freinage n'a pas à gérer la clim.
Un excellent article sur les interfaces :
http://www.dotnetguru.org/articles [...] eClass.htm
Y'a un peu le même probleme, avec une bidouille qui équivaudrait ici à lancer une exception "Not supported" dans brancheLaClim() des voitures qui n'en n'ont pas.

Pareil de HelloWorld, tu devrais séparer selon les besoins a la rigueur.
 
Par exemple (je fais grace des paramètres  des méthodes )

 
Après tu pourras instancier des voitures ou des voitures avec la clim, voir meme si t'as une classe batiment, un batiment avec la clim
(c l'interet)
 
si jamais tu as seulement des IVehicule* , et que tu veux savoir si c un véhicule avec clim tu dois utiliser un dynamic_cast

t'es bien marrant, c'est pas des interfaces ça. et tu ferais bien de mettre des destructeur virtuel et de faire de l'héritage virtuel également

C'est quoi ces especes d'interfaces qui contiennent du code???

je crois que ses interfaces sont IVehicule et IClimatisation, les autres sont des implémentations

sans déconner ?

je voudrai savoir sil ya compillateur qui envoi le code source d un programe mersi d avance

aucun

 
T'as compris ce qu'il voulait ? je pige pas sa question

un décompilateur

 
Ca n'existe pas..... la compilation est loin d'etre une opération bijective...

Ça dépend, la compilation de HTML en CHM peut facilement se décompiler  

vi, mais ça n'a de compilation que le nom ...