 |
||
| ||
| |||||
| Dernière réponse | |
|---|---|
| Sujet : [JAVA] impement | |
| louisebrooks | je démarre en POO donc le C++ connait pas
merci pour l'exemple des animaux merci aussi pour le débat, même si j'ai pas tout compris, ça m'a servi à voir plus clair dans les implements des fois une confrontation de points de vues est plus éclairante qu'une explication, allez savoi pourquoi ! |
| Aperçu |
|---|
| Vue Rapide de la discussion |
|---|
| louisebrooks | je démarre en POO donc le C++ connait pas
merci pour l'exemple des animaux merci aussi pour le débat, même si j'ai pas tout compris, ça m'a servi à voir plus clair dans les implements des fois une confrontation de points de vues est plus éclairante qu'une explication, allez savoi pourquoi ! |
| n0mad | under>
Le débat Agrégation/Héritage est un débat (à ce que j'en ai lu) qui remonte aux années 80. Le sujet concernait la manière d'implémenter correctemement le concept de généralisation. Une école pronait l'héritage et l'autre l'agregation. En fait de compte, ils ont décidé d'utiliser les 2 selon les besoins :) <Grosse parenthèse hors topic> En fait c'est quasiment 2 philosophies différentes du monde : Exemple simpliste: * une Ferrari EST une voiture : Ferrari derive de voiture * une Ferrari A les fonctionnalités d'une voiture : Ferrari agrège un objet Voiture Comme on le voit, la différence entre agregation et heritage peut être très tenue, surtout qu'au final, tout est codé en agrégation (en mémoire, c'est des structures qui s'emboitent). Je me suis interessé à ça à un moment. Ca m'a permis de comprendre que mon chef de projet etait de l'école agrégation (borné) alors que moi je suis "plutôt heritage non pratiquant" :) et qu'evidemment on était pas souvent d'accord, mais ceci est une autre histoire... |
| under | nomad> ouais ca depend des habitudes..moi c le contraire le C++ m'emmerde a cause de son heritage multiple...ce sont deux ecoles...chacun la sienne...mais bon je sui spas d'accord quand tu dis que le C++est de l'objet vraiment abouti c faux !! meme le java n'est pas de l'objet abouti, pour moi de l'objet abouti..ce serait un langage ou TOUT serait objet...et ca ca existe pas encore....Mais pour moi le java est plus proche de l'objet pur, parce que le concept d'interface t'oblige a faire des classes qui soient vraiment bien faites, qui correspondent vraiment à la conception de l'objet de depart defini par l'interface..pour moi c ce qui manque en C++ (bon ca devient polu trop un probleme si le programmeur programme bien dans une vision "objet" mais sinon c vite le fouilli..
Bon tu me diras, en java c possible de faire un fouilli aussi...c sur, mais bon...la c plus un probleme de programmation objet c un probleme d'analyse... enfin voila mon point de vue :hello: et au fait, c koi ce debat Heritage /Agregation? c sur de l'UML? |
| n0mad | under> le probleme avec le C++, c'est qu'on peut tout faire, y compris les conneries :) Mais si tu as une bonne conception en amont, tu peux y aller comme un bourrin sur l'héritage virtuel & multiple.
Perso j'aime bien le C++ car c'est de l'objet vraiment abouti. C'est un langage où on peut s'affranchir des contraintes matérielles et permet d'avoir une vision réellement algébrique du monde à simuler (je fais beaucoup de programmation sur les simulations / évolution de systèmes). J'aime pas Java (même si j'en ai fait pendant 1 an au boulot sous Visual Age) car l'héritage multiple me manque vraiment ou alors ça oblige à faire 1 interface & 1 classe implémenté à chaque fois (comme dans les Swing par exemple quand une classe implemente une interface et agrège l'implémentation de l'interface) En fait, ça me rappelle le débat Heritage/Agrégation et le traité d'Orlando pour ceux qui connaissent :) |
| wpk | under> le c++ c'est aussi un tres bon language, seulement il n'y a pas les gardes fous de java. La notion d'interface justement eh bien en c++ il faut l'implementer soi-meme et etre suffisament integre :) pour s'interdire toute derive par rapport au modele objet. C'est rarement le cas. Tu trouveras toujours 10milliards de bonnes excuses pour faire des "saloperies contre-nature" ;). En resume le java est fait pour les hommes, le C++ pour les dieux :hap: . Oula je sens que je m'egare un poil ;) ... |
| under |
|
| BENB | under > Ce qui est chiant avec les implementation d'interface c'est que tu sois obligee de definir toutes les methodes de l'interface. C'est la le vrai avantage de l'heritage multiple, mais je reconnais qu'il ne faut pas en abuser... et en particulier il faudrait jamais avoir besion de l'heritage virtuel, mais la on devie, puisque la question etait sur Java... |
| under |
|
| BENB | Certains utilisent en C++ ce qu'il appellent des interfaces concretes, c'est a dire dont certaines methodes ont une implementation disont par defaut. Quand on les realise on n'est alors pas oblige d'implementer toute l'interface.
Pour ma part je trouve que l'heritage multiple (C++) est plus riche que l'implementation d'interface (Java). Mais il pose aussi beaucoup plus de Problemes quand les classes heritees ne sont pas des classes abstraites sans attributs... |
| kadreg |
|
| n0mad |
|
| under |
|
| under | en fait une interface est une class abstraite ou toutes les methodes sont abstraites.
ps : tu peux aussi t'en servir pour specifier des constantes. c meme bien util pour ca, pour mettre toutes les constantes d'une appli. |
| kadreg |
|
| wpk | nomad >en fait, une interface NE SERT PAS A FAIRE LA MEME CHOSE QUE L'HERITAGE MULTIPLE c'est deux notions completement differentes.
Dans l'heritage multiple, tu herite d'un comportement et d'attributs de la classe mere (a moins bien sur d'heriter toujours de classes abstraites sans attributs auquel cas ta classe c'est une interface) Les interfaces, il faut les voire comme un contrat passe entre le developpeur de l'objet et le developpeur qui va utiliser l'objet. Implementer une interface c'est donc s'engager a respecter ce contrat. L'interface joue donc seulement un role de canevas pour l'objet qui l'implemente. Pourqoui sinon on aurait change le mot clef extends pour implements? |
| under | on va faire simple : tu as une classe chat, une classe chien, une classe oiseau et une interface animaux ! bon tu veux dire que un chat,un chien , un oiseau, sont des animaux. Mais tu ne veux pas definir un animal justre en tant qu'animal...donc tu met animal en interface... et les classe chien,chat,oiseau, vont implémenter animal. donc chaque fois que tu vas definir une methode dans l'interface animal, tu devras la definir dans la classe chien,chat,oiseau. exemple : public class Chien implements animal { public Chien() { .... } public void crier() { System.out.println ("ouaf" ); } } public class Chat implements animal { public Chat() { .... } public void crier() { System.out.println ("miaou" ); } } public class Oiseau implements animal { public Oiseau() { .... } public void crier() { System.out.println ("meuh" ); // ouiiiiiii un oiseau ca fait meuh !! } } donc pour l'instant ton interface animal va juste devoir definir une methode vide crier() !! et pis voila...donc comme ca tu specifiera le fait qu'un animal doit savoir crier pour etre un animal t'as vu l'exmeple de malade un peu !!!! |
| lamatrice | .....eeeeeeeeeeeeeeeeeeeeh....hum!..........hum!
ça commence à rentrer mais un exemple claire serai mieux (si vous avez le temps) |
| n0mad | Implement est utilisé pour les interfaces. C'est la seule manière de contourner le fait que Java ne fasse pas le multi-héritage vu qu'une sous-classe ne peut dériver que d'un seule classe mais de plusieurs interfaces.
Tu définis une interface de la même manière qu'une classe sauf qu'il n'y a aucune implémentation (c'est une classe abstraite en fait, il n'y a que les prototypes des methodes). Cette implémentation se fera plus tard dans la sous-classe qui implémente l'interface (d'où le 'implement'). Pour eviter le copier-coller de code lors d'un multiheritage, on peut fournir des implementations d'interfaces destinées à être agrégées dans les sous-classes qui implémente l'interface (voir les exemples des Swing avec les listeners) |
| BENB | Conceptuellement il y a les classes et les interfaces. Une interface est une classe dont les methodes ne sont pas implementee, et qui n'a pas d'attribut.
Lorsque tu definit une nouvelle classe elle derive d'une autre classe, et elle peut implementer plusieurs interfaces, c'est a dire en definir les methodes... Une interface sert a specifier une classe ou une famille de classe independement de la maniere de les implementer. exemple tu peut definir une interface d'objet graphique, interface GraphElement { public Draw(...); public Move(...); } /* Oui c'est une syntaxe simplifiee */ Mais nulle part on dit comment GraphElement se dessine, ce sont les classes qui implementent GraphElement qui definissent cela. A l'utilisation, tu n'a que a connaitre GraphElement, et si tu fais un module qui utilise des objets implementant l'interface GraphElement, ce module pourra utiliser des objets definis ailleurs independement de facon toute naturelle. l'interface est une chose reelement importante en conception objet... |
| lamatrice | j'ai un peu de mal à comprendre le concept implement :
c'est une importation des squelette methodes uniquement sans paramètre ou quoi ? je suis un peu dans le flou et malgrès des docu différentes : il prennent tous le même exemple que je pige pas vraiement. si qqun peux passer une petite explication ça sera bien pour ma lenterne. |
