Classe abstraite et interface de java

Bonjour,

Je me permet de remonter ce poste... Car je suis, disons le, assez choqué par l'intervention de "Marco la baraque"!

Je reprend vos termes..
***
En effet, dans ce cas, on augmente le risque de bugs en voulant rendre générique du code similaire (certes si tu as 50 fois la même méthode, c'est qu'il y a un problème dans ta conception), et on crée des classes abstraites qui n'ont absolument aucun intérêt ni technique ni fonctionnel, car elles servent juste à centraliser du code.
***
Je donne un exemple simple d'implémentation, juste technique, de centralisation de code avec classes Abstraites...
J'ai besoin de définir des objets pour un projet personnel comme tel : Les données ci dessous sont à titre d'exemple...

Objet A : variables : String name, String phoneNumber
Objet B : variables : String name, String insuranceNumber
Objet C : variables : String name, ImageIcon image, String productId
Objet D variables : String name, ImageIcon image, String comment

Cas avec factorisation via classes Abstraites ca donne :
Toutes les classes ci dessous ont juste les getter et setter pour les variables qu'elles portent en public
Abstract class AbstractBeanWithName : String name
Abstract class AbstractBeanWithImage extends AbstractBeanWithName : ImageIcon image
BeanWithPhoneNumber extends AbstractBeanWithName
BeanWithInsuranceNumber extends AbstractBeanWithName
BeanWithProductIdNumber extends AbstractBeanWithImage
BeanWithCommentNumber extends AbstractBeanWithImage

- Les variables ont le même nom partout, uniformité...
- Si je veux savoir quels objets ont une image, je recherche les références à AbstractBeanWithImage (gain de temps énorme)
- Gain de place énorme.. si on connait son architecture, on sait de suite quelles variables sont héritées
- Maintenabilité parfaite..., besoin d'une vérification de saisie sur une variable... je peux la mettre au niveau du setter, exemple bidon mais probant, une seule méthode à retoucher
-- j'ai besoin un jour d'un objet avec juste un nom, je retire Abstract de ma classe AbstractBeanWithName qui devient BeanWithName... , même chose si un jour besoin d'un objet avec nom et image... AbstractBeanWithImage devient BeanWithImage
- Si un traitement est particulier à l'un des objets... par exemple le nom sur BeanWithPhoneNumber et qu'il existe déjà un traitement sur ce setter que tous les autres objets utilisent, l'override du setter est possible... Cas super rare si la spec est bien faite au départ... l'analyse, mais une seule méthode à créer...

Cas sans facto :

Object A : variables : String name, String phoneNumber
Object B : variables : String name, String insuranceNumber
Object C : variables : String name, ImageIcon image, String productId
Object D variables : String name, ImageIcon image, String comment

- Les variables peuvent finir avec des noms différents.. ex : nom, name, data_name (ce qui arrive souvent, si peu de factorisation du code... et ca devient totalement illisible)
- Je dois ouvrir toutes les classes pour savoir lesquelles portent une image... puisque chaque classe pouvant être codée par des dev différents, les noms des variables peuvent changer...
- Classe 4 fois plus grande que dans l'autre cas... donc scrolling... et il faut ouvrir tout pour savoir qui porte quel type de variable, méthodes, même si identique (name) (image)
- Maintenabilité faible, si une modification est à reporter partout, cas de la vérification de saisie sur un setter, je dois parcourir toutes les classes et faire un copier collé bête et méchant (perte de temps, risque d'oubli, sans compter le noms des méthodes et des variables qui peuvent changer) setNom, setName etc....
-- j'ai besoin un jour d'un objet avec juste un nom, je rajoute une classe... risque de changer de nom de variable... etc etc , même chose si un jour besoin d'un objet avec nom et image...
- Si un traitement est particulier à l'un des objets... je l'implémente dans son coin

Bref, d'expérience, sur les projets non factorisés... sans aller dans l'extrême que j'ai exposé... Qui reste cependant totalement valable et probant, puisque là, c'était juste une factorisation purement technique... On obtient :

- Des classes codées par des devs différents, qui font la même chose... car manque de connaissance de l'architecture du projet
- Des variables à l'utilité identique... String nom, qui changent name, nom, data_name, illisible, impossible à facilement retrouver dans le code, à part tout parcourir
- Problème de performance, car certaines méthodes ayant le même but, la même fonction, vont changer de nom, d'algorithme, impossible à retrouver... parfois on fait une correction dans un coin et oh zut, un abrutis à fait la même chose avec un autre nom, seulement, je dois me taper 40 lignes de code, pour bien vérifier que c'est la même

La factorisation est l'a-panache de la perfection en programmation...
Gain de temps, Maintenabilité, lisibilité --> GML lol

***
Pour moi la notion d'héritage est bien plus riche que ça : on doit avant tout hériter d'un type, puis ensuite on hérite (et éventuellement défini ou redéfini) de ses méthodes. C'est d'ailleurs ce que tu expliques dans ton exemple avec les formes : tes objets étendent ta classe abstraite car ils sont similaire d'un point de vue comportement (un carré ou un rectangle c'est une figure 2D, donc elles étendent ta classe Figure2D), et non pas uniquement pour factoriser le code.
***

Vrai et Faux...
Vrai, si vous instanciez Figure2D... uniquement! et donc que celle ci ait une raison de l'être!
Faux, dans le sens ou... une classe abstraite trouve son utilité quand vous avez des objets dont l'implémentation de certaines méthodes différent... dessiner() comme l'a si bien exposé "misterETS", mais que des méthodes et/ou variables sont communes static ou pas...
Si Figure2D, n'est qu'un agrégat de méthodes et variables communes aux objet à dessiner en 2d, mais que chacun d'eux se dessine différemment, Figure2D n'a aucune raison d'être instanciée en temps que tel, puisqu'elle ne porte que la description de la méthode dessiner... Figure2D ne dessinant rien en soit même, on la met en Abstract... Logique des plus basique!

CQFD : Une classe abstraite est donc par nature une classe permettant de factoriser du code et de permettre tout de même une divergence de comportement de ses enfants... C'est donc un outil très puissant, mais qu'il faut savoir manier... Ce qui est encore appuyé par le fait que les variables définies dans une classe abstraite peuvent être public, protected, private en opposition à une interface dont les variables ne peuvent être que public...
Ainsi que par le pattern Template...
Une classe abstraite est aussi et comme son nom l'indique, utile pour abstraire un code client des spécificités des classes filles de cette classe abstraite...
Si une méthode reçoit en argument une classe concrète (instanciable) dans un code "client", toute modification des particularités de cette classe seront à prendre en compte dans le code "client", ainsi que si il y a ajout d'une classe concrète de la même famille...
Si maintenant celle ci reçoit en argument la Classe abstraite mère d'une famille de classes concrètes... le code client s'abstrait de leur particularités, sera plus facilement maintenable et la modification, création de classes concrètes de cette même famille (héritant la même classe abstraite passé ici en argument) ne demandera retouche du code client, que si, il y a ajout de nouvelle fonctionnalités (méthodes) utiles... dans son cas ;) (Pattern Abstract Factory)

****
Si tu veux uniquement factoriser du code, tu peux utiliser un design pattern Wrapper, ce sera d'autant plus propre que tu ne "perdra" pas ton héritage (dans de nombreux langages objets l'héritage multiple n'existe pas, et étendre une classe abstraite uniquement pour factoriser du code fera que ta classe ne pourra plus étendre de classe par la suite, ce qui peut être gênant si tu souhaites étendre un type et un comportement par la suite).
****

Le design pattern Wrapper est très proche de l'adapter et au final est plus proche de la spécialisation que de l'héritage, donc à l'opposer fondamentalement de la factorisation de code...
De plus, je rappel que les classes abstraites peuvent hériter d'autre classes.... Votre explication ne fait que malheureusement souligner votre manque de connaissances en la matière et risque justement d'induire en erreur des développeurs et de provoquer une faible maintenabilité, ainsi qu'un nombre de classes exponentielles... par rapport au besoin!

En espérant éclaircir le sujet pour les futurs lecteurs, a bon entendeur ;)

je veux un programme en java avec une classe abstraite

olfa on passe pas les commandes par ici, et puis on dit "svp" ^^

Les classes sont abstraites quand elles ne sont pas directement instantiables.
Par exemple si tu représentes le règne animal, la classe Animal sera abstraite, de même que ses classes filles Mammifère, Oiseau, Reptile...
En effet il y certaines caractéristiques qui ne sont pas connues et qui ne peuvent pas être implémentées (par exemple le nombre de pattes qui varie selon l'espèce)
Par contre des classes finales comme Chat, Aigle, Serpent... pourront être totalement implémentées puis éventuellement spécifiées (ChatPersan, AigleRoyal, Vipere...)

Merci beaucoup pour la réponse.

Vu que je suis débutante en programmation java, j'aimerai avoir une idée pour concevoir et implémenter une petite application java afin de m'entraîner sur java OO.
Merci

En Java, classes et interfaces sont deux choses distinctes. Même si les concepts sont similaires, on ne peut pas utiliser une interface à la place d'une classe abstraite ni inversement !

Salut à tous,

Si j'ai bien compris, en java, une Interface sert à s'assurer que toute classe l'implémentant contiendra TOUTES les fonctions définies.
Ce qui évite certainement bien des erreurs.
Exemple : un chien, comme tout être vivant, doit manger, l'utilisateur ne doit donc pas oublier la méthode "manger".

L'héritage sert à ne pas se retaper bêtement toutes les méthodes/attributs.

Les classes abstraites servent à ne pas être instanciées.
Exemple : il est idiot d'instancier un objet "Animal", puisqu'un animal n'existe pas en temps que tel. L'utilisateur doit créer un objet "pigeon", "chien", puisqu'un animal est forcément un pigeon ou un chien (enfin, vous me comprendrez).


CEPENDANT
Si je décidais de faire ma tête de ... et de ne rien appliquer de tout ça, tout marcherait quand même. Je m'explique :
1/ Si je prends un programme (qui fonctionne) avec une interface EtreVivant.
Je vire tous les "implements EtreVivant" ainsi que la-dite interface, tout marchera.
2/ Les "copier-coller" peuvent remplacer l'héritage.
3/ Je vire tous les "abstract" servant à définir les classes abstraites et tout marchera aussi.

Conclusion

Tous ces dispositifs n'ajoutent pas de nouvelles possibilités de programmation. On fait exactement la même chose via les trois solutions donnée précédemment.

En revanche, il y a un intérêt certain dans la clarté et la concision du code : pas la peine d'utiliser directement ma classe abstraite animal, c'est stupide, ce qui tombe bien, puisque le compilateur ne l'acceptera pas.
Ainsi, un programmeur qui utilise mes bibliothèques ne se creuse pas la soupière, il créera un objet "chien".

La grande question est donc bien sûr : AI-JE RAISON ?

Non ^^

Et puisque la réponse courte ne te conviendra pas je te propose donc la version longue :p
Il y a un gros problème en programmation orientée objet c'est l'héritage multiple.
C'est toujours difficile de prendre un exemple concret, j'espère que tu comprendras quand même.

Soient :
Une classe A avec une méthode fa abstraite
Deux classes B et C, qui héritent de A et implémentent fa, et respectivement fb, et fc.
Une classe D, qui hérite de B et C, donc de fa, fb, et fc.

Problème : quel fa doit on hérité, celui de B, ou celui de C, un mélange des deux ?

En C++ l'ordre d'héritage est important, ainsi hériter de B et C, implique de prendre fa dans B, alors qu'hériter de C et B, implique de prendre fa dans C.

En Java on ne peut pas faire d'héritage multiple, c'est là qu'interviennent les interfaces.
Dans mon exemple, A serait une interface, B et C deux autres interfaces qui héritent de A.
D par contre pourrait-être une interface aussi, mais surtout une classe qui implémenterait donc à la fois B et C, c'est à dire à qui on impose d'implémenter fa, fb, et fc, et du coup on a pas à choisir quel fa on va utiliser, on sera obligé de l'implémenter puisque les interfaces B et C l'imposent...

Je sais pas si c'est clair, j'espère en tout cas ^^

Oui et non...
Je n'a jamais fait de C++ objet, je ne répondrais donc que pour java...
Ce que tu dis ne me paraît pas inexact, mais je ne vois pas en quoi ça me contredit : si je vire A, B et C qui sont des interfaces, je vire également le "implements B, C" dans la définition de D.
D marchera quand-même, non ?

Sauf que l'on peut avoir, et c'est souvent le cas, une classe E, qui définit une méthode pour tous les éléments de A, donc si D n'implémente plus A, B, ou C, on ne peut plus utiliser les méthodes de E sur des éléments de D.

Un bon exemple c'est l'interface Collection et la classe Collections. La classe Collections offre des méthode de manipulation des classes implémentant Collection et ce peu importe quelle soit leur implémentation. Donc on pourra par exemple trier une liste, un arbre, ou n'importe quelle Collection en utilisant Collections.sort. Si tu créés ta propre classe Arbre mais que tu n'implémente pas Collection tu ne pourras pas utiliser ces méthodes là, et tu devras tout redéfinir, alors qu'il te suffit de faire l'implements pour y avoir accès, ainsi qu'accéder à d'autres méthodes d'autres classes.

Tout cela concerne la réutilisabilité, pourquoi tout réinventer à chaque fois ?
Si tu "vires" tout ce qui concerne l'héritage tu perds de vue la programmation objet.
Tu peux tout recoder tout dans un même fichier à grands coups de copier-coller et oui ça reviendra au même... Pour reprendre ton exemple d'animaux, si tu considères que la seule différence entre labrador noir et un labrador sable c'est la couleur, toi tu vas copier-coller toutes ta classe labrador et modifier la couleur, quand un bon programmeur, héritera de la classe labrador et implémentera la classe couleurDePeau...

J'ai compris l'un des intérêts de l'héritage, à savoir les copier-coller, donc, rendre le code plus concis, ect.
C'est le coup de l'interface qui me turlupinait, mais je crois que j'ai compris.
Si je veux faire Arbre extends Collection, Végétal

Je ne peux pas en java, donc, je fais une classe et une Interface (Collections et Collection) qui remplace la classe Collection. Dans Collections, tout est static et toute les méthodes prennent une Collection en argument.
Végétal reste la classe Végétal qui contient ce qu'on voudra.

Je fais donc Arbre extends Végétal impléments Collection.
Un appel Collections.sort(monArbre) sera équivalent à un monArbre.sort() qui aurait été possible si j'avais pu faire un héritage multiple.

L'interface est donc un moyen de contourner l'impossibilité de faire de l'héritage multiple, comme tu le disais.

L'interface a-t-elle un autre intérêt ?

En tout cas merci.

Je ne crois pas que les interfaces aient vraiment un autre intérêt... sinon celles des classes abstraites.

Par contre je ne comprends pas ton exemple, peut-être y a-t-il confusion entre un arbre (un type particulier de graphe, une collection en Java) et un arbre (un végétal, où les oiseaux font leur nid).
Mettre les deux en même temps me laisse perplexe ^^
De plus les Collection sont typés, il y a toujours une classe E à laquelle elles s'appliquent et qui correspond aux éléments qu'elles contiennent, par exemple Collection<String>, Collection<Integer>...

Et malgré mais effort je ne vois pas trop ce que pourrait être Vegetal, si on considère que Arbre en est une classe fille qui implémente Collection... A priori, une classe qui implémente Collection peut difficilement hérité d'autre chose que Object, mais il faudrait voir un exemple concret ;-)

Non, je sais que l'arbre est un type particulier de graphe.
J'avais simplement besoin d'un exemple d'héritage multiple, j'ai donc voulu faire un jeu de mots avec végétal mais c'est raté.
Quand au typage des collections, je pense que c'est un autre problème, non ?

Oui, c'est un autre problème, mais c'était juste une remarque, tu aurais pu vouloir dire Arbre implements Collection<Vegetal>, ce qui n'est pas faux si on considère que le Vegetal est le type des Feuilles...

Non, non, je voulais bien dire extends Végétal implements Collection<ceQu'onVeut>.

Pour l'exemple concret, prenons l'exemple du Graphe, justement :
Si tu considère qu'un Graph est un machin qui possède des noeuds et des arrêtes, que les noeuds ne sont pas forcément Comparator (appartenant à un ensemble ordonné).
Un Graph n'aurait donc à priori rien d'une Collection.

Un arbre pourrait hériter de Graph (qui doit exister en java) pour tous les aspects théorie des Graphs (chemin de A à B, par exemple) et implémenter Collection pour le côté données.

Je ne crois pas que Graph existe tel quel dans les librairies standards, mais il existe des bibliothèques pour la théorie des graphes. Mais du coup l'arbre au sens des graphes n'est plus vraiment une collection, ça n'aurait pas de sens de le trier par exemple, mais si c'est juste pour stocker des données, alors le graphe aussi serait une collection... ce qui serait malgré tout un peu bizarre. Un graphe serait en fait composé de deux collections, l'ensemble des noeuds, et l'ensemble des arêtes, et un arbre aussi du coup, mais dire que l'arbre est une collection à part entière, ça me parait faux.
Remarque : il n'est pas nécessaire que les éléments d'une Collection implémentent Comparable, sauf évidemment pour les SortedSet, mais ce sont des sous-interfaces particulières, Collection est plus générale que ça.

Moi, j'aurais bien vu une simple matrice pour le graphe... La case (i,j) représentant soit le poids de la liaison (i,j), soit un booléen disant si cette liaison existe.
Trier un arbre n'a effectivement aucun sens, mais puisque tu dis qu'une collection n'a pas forcément besoin d'être ordonnée (donc triable)...

1) la représentation matricielle pour un graphe c'est pas top
2) je ne vois pas en quoi ce serait une Collection : quels serait les éléments contenus ?
3) on s'éloigne du problème, non ?

1/ Ça dépend de l'usage que l'on en fait, il y a tellement d'applications différentes...
2/ Là, comme ça, j'aurais dit les feuilles de l'arbre.
3/ Oui, c'est vrai, j'essayais juste de trouver un exemple, mais on est un peu parti à l'ouest. En tout cas, merci pour tes réponses.

Dans les mails que tu reçois tu as un lien "Arrêter les envois de mails concernant cette discussion "