Bonjour,
J'aimerais comprendre comment fonctionne et à quoi servent les interfaces et les classes abstraites, j'ai beaucoup cherché sur internet, trouvé des vidéos youtube sur le sujet (souvent en anglais),
et malheureusement aujourd'hui, je ne comprends toujours pas...

Pourquoi des classes abstraite ?
Pourquoi des interfaces ?
Les différences ?

Si vous avez des exemples sous la main...

Merci d'avance.

T'expliquez comme ça ne servirait absolument a rien

C'est surtout en pratiquant que tu comprend l'interet

Essaye d'apprendre le C++ ou le Java, le début n'est pas bien compliqué et c'est que comme ça que tu comprendras. (Utlise les tutos d'openclassromm par exemple)

Une classe abstraite est une classe qui contient au moins une fonction virtuelle pure.
C'est bien ça ?

Le 03 août 2016 à 12:56:12 Gaetano-GX a écrit :
Une classe abstraite est une classe qui contient au moins une fonction virtuelle pure.
C'est bien ça ?

Alors la... je sais juste que c'est une classe qui ne peux pas être instancier.
C'est quoi une "fonction virtuelle pure" ?

(Utlise les tutos d'openclassromm par exemple)

(Concernant le C++, openclassroom est à éviter à tout prix)
Une classe abstraite est une classe que l'on ne peut instancier, donc qui contient au moins une fonction virtuelle pure. (Tu dois aussi mettre un destructeur pur sinon ça va merder au runtime, mais pas au compiletime)
T'aurais pu googler

Le 03 août 2016 à 14:01:46 JeanPeuplu29 a écrit :

Le 03 août 2016 à 12:56:12 Gaetano-GX a écrit :
Une classe abstraite est une classe qui contient au moins une fonction virtuelle pure.
C'est bien ça ?

Alors la... je sais juste que c'est une classe qui ne peux pas être instancier.
C'est quoi une "fonction virtuelle pure" ?

un fonction du genre void foo() = 0

Le 03 août 2016 à 14:17:59 Apjue a écrit :

(Utlise les tutos d'openclassromm par exemple)

(Concernant le C++, openclassroom est à éviter à tout prix)
Une classe abstraite est une classe que l'on ne peut instancier, donc qui contient au moins une fonction virtuelle pure. (Tu dois aussi mettre un destructeur pur sinon ça va merder au runtime, mais pas au compiletime)
T'aurais pu googler

J'ai googlé, j'ai youtubé, j'ai cherché, mais je ne comprends toujours pas l’intérêt d'une tel classe....

Tout ça me paraît abstrait.

Imagine que tu as deux classes. Une classe Pigeon et une classe Chien. On est d'accord que les deux animaux ici présent peuvent "crier". Mais c'est pas les seuls à crier dans le règne des animaux. On a les hiboux, les chats, les babouins, tous avec un crie différent et qui produise un son différent.

Au lieu de faire une fonction pour chacun, on peut faire une classe de base dite Animaux. Elle contiendra la méthode virtuel pure crier. Ainsi, chaque classe fille de Animaux se devra d'implémenter sa méthode crier pour produire le bon son. J'ai bien dit devra et non pas pourra.

C'est l'avantage 1er. Ensuite, imagine que tu veux faire une loop pour entendre tes animaux crier dans tes écouteur apres tout ce temps de travail. Tu peux faire :

Animaux* chat = new Chat();
Animaux* chien = new Chien();

vector<Animaux*> mesAnimaux; 
mesAnimaux.push_back(chat);
mesAnimaux.push_back(chien);

for(Animaux animaux : mesAnimaux)
         animaux->crier();

Voici l'avantage numéro deux. A chaque fois que Animaux va appeler la méthode crier, il va appeler la méthode de la classe Chat ou Chien ou la classe fille au lieu de celle de Animaux (qui est vide car virtuel pure). C'est le polymorphisme.

Du coup tu entendra tes cries préférés dans tes écouteurs. Applique cette exemple à ce que tu veux, c'est le principe de base.

Tcho tcho.

for(Animaux animaux : mesAnimaux)
         animaux->crier();

Animaux&, ou encore plus simple: auto&. Ton exemple fait une copie

Vaut mieux éviter autant que possible le mot clef auto, ça rend le code moins clair.

Le 03 août 2016 à 15:28:58 Apjue a écrit :

for(Animaux animaux : mesAnimaux)
         animaux->crier();

Animaux&, ou encore plus simple: auto&. Ton exemple fait une copie

Si tu veux vraiment être picky sur du pseudo code, ce devrait être Animaux* vu que se sont des pointeurs mais bon...

Le 03 août 2016 à 15:41:45 lokilok a écrit :
Vaut mieux éviter autant que possible le mot clef auto, ça rend le code moins clair.

std::vector<MaStruct>::iterator it = monVec.find(...);

vs.

auto it = monVec.find(...);

Je prend le 2e direct.

Le 03 août 2016 à 15:50:43 1234_bou a écrit :

Le 03 août 2016 à 15:28:58 Apjue a écrit :

for(Animaux animaux : mesAnimaux)
         animaux->crier();

Animaux&, ou encore plus simple: auto&. Ton exemple fait une copie

Si tu veux vraiment être picky sur du pseudo code, ce devrait être Animaux* vu que se sont des pointeurs mais bon...

Oops

Le 03 août 2016 à 16:30:06 Apjue a écrit :

Le 03 août 2016 à 15:41:45 lokilok a écrit :
Vaut mieux éviter autant que possible le mot clef auto, ça rend le code moins clair.

std::vector<MaStruct>::iterator it = monVec.find(...);

vs.

auto it = monVec.find(...);

Je prend le 2e direct.

Perso je prends le premier sans hésiter, c'est plus clair, si pour une raison quelconque t'as besoin de chercher tous les itérateurs de vecteur de MaStruct dans ton programme un simple ctrl+f pourra suffire, alors qu'avec un auto c'est pas possible.

J'utilise auto dans les new ou dans les cast, ça ne nuit pas à la lisibilité du code :

auto foo = new Base;
auto foo2 = dynamic_cast<Derived *>(foo);

Bonjour,
Excusez moi les gars, mais pas tous le monde dev en C++ haha ^^,
Donc si j'ai bien compris, une classe abstraite est utile quand plusieurs objets peuvent avoir les mêmes méthodes, permet d'éviter les répétitions de cette même méthode dans plusieurs classe différentes ?

Le 03 août 2016 à 19:12:01 JeanPeuplu29 a écrit :
Bonjour,
Excusez moi les gars, mais pas tous le monde dev en C++ haha ^^,
Donc si j'ai bien compris, une classe abstraite est utile quand plusieurs objets peuvent avoir les mêmes méthodes, permet d'éviter les répétitions de cette même méthode dans plusieurs classe différentes ?

Je pense que tu as toute compris. Regarde plus le polymorphisme que les classes abstraite sur internet, ca aide beaucoup. C'est un grand mot pour dire partager les fonctions et attribut d'une classe.

Le 03 août 2016 à 19:12:01 JeanPeuplu29 a écrit :
Bonjour,
Excusez moi les gars, mais pas tous le monde dev en C++ haha ^^,
Donc si j'ai bien compris, une classe abstraite est utile quand plusieurs objets peuvent avoir les mêmes méthodes, permet d'éviter les répétitions de cette même méthode dans plusieurs classe différentes ?

Oui... et non. Le but d'une classe abstraite, c'est de dire "cette classe, qui regroupe des propriétés et méthodes propres à plusieurs classes qui vont en hériter, ne peut être instanciée en tant que telle".

Pour reprendre l'exemple très parlant d'au-dessus avec les classes Chien et Chat qui héritent de la classe abstraite Animal, l'intérêt de déclarer Animal comme classe abstraite, c'est d'empêcher de faire un new Animal(), qui n'aurait aucun sens, puisqu'un animal doit avoir un type, un genre, etc...

...le truc, c'est que tu peux très bien coder ton système avec des classes "normale", et avoir ta classe Animal non-abstraite : ça fonctionnerait très bien. Mais à la lecture du code, ça ne serait pas logique, ni "élégant", l'utilisation des concepts comme l'abstraction, le polymorphisme, la portée des membres rend ton code plus lisible et compréhensible, que tu travailles seul, ou en équipe.

Le 03 août 2016 à 12:56:12 Gaetano-GX a écrit :
Une classe abstraite est une classe qui contient au moins une fonction virtuelle pure.
C'est bien ça ?

En C++ oui puisqu'il n'y a aucune synthaxe permettant de définir une classe abstraite, genre 'virtual class MaClass =0...'.
On est obligé de rendre une méthode purement virtuelle pour que le compilateur pète si tu veux instantier la classe en question.

En php, java et c# tu peux mettre le mot clef absract dès la définition de classe sans pour autant avoir de méthode abstraite.

C++ c'est vraiment le début de la poo, c'est très libre, une classe peut hériter de plusieurs autres, alors que tu ne peux pas avec les 3 cités plus hauts, on est obligé d'utiliser des interfaces qui font office de 'classes parentes', malgré qu'on ne puisse pas y déclarer de propriétés, ça permet de mieux arranger son code dès le départ.