Classes Abstraites et Interfaces

contrairement aux questions qui surgisses sur ces deux termes, je voudrais avouer que moi je comprends parfaitement la différence entre les deux ainsi que leurs avantages en ce qui concerne le polymorphisme et la factorisation du code. Mes questions sont les suivantes :

1) Tout ce que je fais avec une classe abstraite, je le fais avec une classe simple que je décide de ne pas instancier et là donc je me demande l'importance du mot clé Abstract... si ce n'est laisser le refus de l'instanciation au compilateur ?

2) En dehors du faite que je peux déclarer des constantes 'globale' dans mon interface et en bénéficier dans tout le code, du fait qu'une classe peut implémenter plusieurs interfaces et enfin à cause du polymorphisme, Je ne vois pas leur importance quant-à 'non-répétition du code

Exemple :

Soit une interface Int1 ayant une méthode M1 et 50 classes : Class1, Class2 et Class3....Class50 qui implémentent cette méthode.
Si demain je me rends compte dans ma conception qu'une seconde méthode améliorerai l'application que ferais-je ?
Je sais que je peux créer une seconde interface Int2 avec la méthode M2 et je choisirais soit de faire pour éviter d'implémenter cette méthode dans mes 50 classes parce que même si je crée une deuxième Interface, ça n'enlèvera pas le fait que j'ai besoin de cette méthode te je dois l'implémenter, donc autant mieux l'ajouter simplement dans la première Interface et l'implémenter partout.

3) Quelqu'un a-t-il une idée comment faire pour éviter d'implémenter cette méthode 50 fois, si possible le faire une seul fois en établir un lien avec les autres 50 classes.

Citation:

---

Envoyé par mesken

1) Tout ce que je fais avec une classe abstraite, je le fais avec une classe simple que je décide de ne pas instancier et là donc je me demande l'importance du mot clé Abstract... si ce n'est laisser le refus de l'instanciation au compilateur ?

---

Ca n'a en général pas trop d'intéret de déclarer abstract un classe qui n'a aucune méthode abstraite, car elle est utilisable en l'état ;)

Citation:

---

2) En dehors du faite que je peux déclarer des constantes 'globale' dans mon interface et en bénéficier dans tout le code, du fait qu'une classe peut implémenter plusieurs interfaces et enfin à cause du polymorphisme, Je ne vois pas leur importance quant-à 'non-répétition du code

---

Aucun intéret, le but et des interfaces et qu'une partie du code puisse utiliser n'importe quelle classe l'implémentant. C'est là qu'on gagne en terme de code puisqu'on ne dois pas jouer avec des 'if machin instance of truc faire ceci, sinon faire cela, ;) ). De plus on peut implémenter plusieurs interfaces, mais étendre une seul classe.

Citation:

---

Si demain je me rends compte dans ma conception qu'une seconde méthode améliorerai l'application que ferais-je ?

---

Dans l'état actuel des choses en java, l'implémenter 50 fois. Si cette méthode peut raisonnablement se baser sur les autres méthodes existantes, on peux faire ce genre de chose dans une classe utilitaire:

Code:

---

public static boolean faireUnTruc(Int1 linterface){return linterface.a() && linterface.b();}

---

et 50 fois:

Code:

---

1 2	public boolean faireUnTruc(Int1 linterface){return utilitaire.faireUnTruc(this);}

---

Cette impossibilité de fournir dans l'interface une implémentation par défaut est un réel blocage en java, sur lequel des propositions d'amélioration existent, mais qu'on ne verra pas apparaitre avant java 8. C'est d'ailleurs une des raisons qui font que l'api Collection de java n'a plus bougé depuis des années, toutes les implémentation se casseraient la gueule car elle n'implémenteraient pas les nouvelle méthodes :?

Citation:

---

Je sais que je peux créer une seconde interface Int2 avec la méthode M2

---

C'est la solution apportée dans swing pour améliorer l'interface Graphics, une interface Graphics2D qui l'etend et plein de instanceof dans le code, c'est au final pas génial non plus.

Merci beaucoup tchize,

mais le flou demeure lorsque tu dis que

Citation:

---

Ca n'a en général pas trop d'intéret de déclarer abstract un classe qui n'a aucune méthode abstraite, car elle est utilisable en l'état

---

Je répète, même si j'ai une méthode abstraite, je peut la laisser dans cette classe sans la déclarer explicitement (Abstract...) et l'utiliser parfaitement pour faire du polymorphisme comme je veux
Pour comprendre ma préoccupation, définis un petit programme avec une classe Abstraite et tu le compile, il marche parfaitement, après tu enlève le mot clé 'Abstract', tu te rendra compte qu'il marche toujours parfaitement
d'où ma question "Que sert le mot clé 'Abstract' ou alors ce n'est qu'un concept ?

Citation:

---

Envoyé par mesken

Pour comprendre ma préoccupation, définis un petit programme avec une classe Abstraite et tu le compile

---

Si la classe est abstraite tu ne peux pas en créer d'instance...

Oui, herve91,
ça je sais, c'est pourquoi je dis que je peux créer une classe normale et refuser de l'instancier...

Citation:

---

Envoyé par mesken

Pour comprendre ma préoccupation, définis un petit programme avec une classe Abstraite et tu le compile, il marche parfaitement, après tu enlève le mot clé 'Abstract', tu te rendra compte qu'il marche toujours parfaitement

---

Si vous retirez le mot clé abstract dans la déclaration de classe et que ça compile toujours à tous points de vue, c'est que votre classe abstraite n'a aucune méthode abstraite et donc, il n'y a aucune raison de déclarer cette classe en abstract. Vous pouvez le faire, mais ça n'a aucun intérêt. Ce que vous ne pouvez pas faire:

Code:

---

1 2 3 4

public class Machin { public abstract void bidule(); // erreur, la classe n'est pas abstraite }

---

Code:

---

1 2 3

public abstract class Machin {...} new Machin(); // erreur, la classe est abstraite

---

Code:

---

1 2 3 4 5 6 7

public interface Truc{ public void bidule(); } public class Machin implements Truc { // Erreur, doit implémenter bidule ou être abstract! // Rien }

---

Citation:

---

Envoyé par mesken

Oui, herve91,
ça je sais, c'est pourquoi je dis que je peux créer une classe normale et refuser de l'instancier...

---

C'est pourtant pas compliqué... Une classe abstraite a le droit d'avoir des méthodes abstraites, c'est-à-dire, déclarées, mais pas définies.
Une classe normale n'en a pas le droit.

Donc, avec une classe normale on est obligé d'implémenter toutes les méthodes, alors qu'avec une classe abstraite on peut laisser ça en partie aux sous-classes et n'implémenter que la logique qui leur est commune.

Code:

---

1 2 3 4 5 6 7 8 9 10

package com.xyz.abc ;   public class PasInstantiableEnDehorsDuPackage { // mais qui peut avoir des sous-classes   protected PasInstantiableEnDehorsDuPackage( /* arguments */) { // code du constructeur qui sera appelé par super dans les sous classes } }

---

variante: créer effectivement une classe abstraite sans méthode abstraite .... d'éminents auteurs (Josh. Bloch, Tchize_,...) disent que ce n'est pas pertinent , mais comme j'ai parfois des opinions bizarres je ne suis pas 100% d'accord (ce qui compte dans abstract c'est le concept lui même d'un objet qui ne peut exister en tant que tel), mais bon c'est mon avis et je le partage hein :mouarf:

Citation:

---

Envoyé par mesken

Pour comprendre ma préoccupation, définis un petit programme avec une classe Abstraite et tu le compile, il marche parfaitement, après tu enlève le mot clé 'Abstract', tu te rendra compte qu'il marche toujours parfaitement
d'où ma question "Que sert le mot clé 'Abstract' ou alors ce n'est qu'un concept ?

---

Tu peux faire ce que tu veux en Java mais l'important est de respecter les concepts de base de la POO qui sont à l'origine de sa création. Tout comme les objets de la vie courante peuvent être détourner de leur usage courant.

Les classes abstraites sont utilisées pour matérialiser des objets abstraits, qu'on ne doit pas instancier. Tu as le choix de compter sur la bonne foi des futurs utilisateurs de ton code ou leur imposer une manière de s'en servir. En cas de mauvaise manipulation les erreurs sont détectées à la compilation.

L'interface est utilisée pour réduire les couplages (dépendances) entre les différents composants de ton application. Elle doit être l'unique porte d'entrée d'un composant, comme son nom l'indique, l'implémentation qui est plus exposée aux changements doit être cachée. Ca te permet d'avoir du code maintenable.

Citation:

---

Envoyé par tchize_

Si vous retirez le mot clé abstract dans la déclaration de classe et que ça compile toujours à tous points de vue, c'est que votre classe abstraite n'a aucune méthode abstraite et donc, il n'y a aucune raison de déclarer cette classe en abstract. Vous pouvez le faire, mais ça n'a aucun intérêt.

---

Si, il peut y avoir un intérêt : prenons le cas d'une librairie. Lorsque le concepteur de la librairie n'a pas imaginé qu'une classe pouvait être instanciée (parce qu'elle est utilisée à but de factorisation uniquement, par exemple), il a tout intérêt à la marquer abstract pour s'assurer que personne ne l'instanciera. De plus, cela rend l'API plus claire pour l'utilisateur de la librairie.
Je dirais donc exactement le contraire : lorsqu'une classe n'est pas prévue pour être instanciée, c'est une bonne pratique que de la marquer abstract.

Citation:

---

Je dirais donc exactement le contraire : lorsqu'une classe n'est pas prévue pour être instanciée, c'est une bonne pratique que de la marquer abstract.

---

Là on est d'accord

Citation:

---

Envoyé par cdefranoux

Si, il peut y avoir un intérêt : prenons le cas d'une librairie. Lorsque le concepteur de la librairie n'a pas imaginé qu'une classe pouvait être instanciée (parce qu'elle est utilisée à but de factorisation uniquement, par exemple), il a tout intérêt à la marquer abstract pour s'assurer que personne ne l'instanciera. De plus, cela rend l'API plus claire pour l'utilisateur de la librairie.

---

La on est moins d'accord. Pourriez vous me donner un exemple d'un classe où tout a été implémenté dedans, mais où on ne veut forcer les gens à faire des sous classe? Parce que, pour moi, ça reviens à forcer les dev à écrire ce genre de code cochon:

Code:

---

1 2 3 4 5

public abstract class A { // tout est dedans, rien d'abstrait } public class B extends A {} // Ben oui, A marche pour mon besoin, j'ai rien à faire donc

---

Par exemple, si A ne marche pour aucun besoin légitime a priori.

Mais bon, normalement ça veut dire que pour répondre à un besoin légitime, les sous-classes doivent redéfinir quelque chose, et c'est mal que le compilateur ne les y oblige pas. Donc bof.

Je verrais plutôt une classe A qui a du code commun hérité de plusieurs classes abstraites BA et BB, qui spécialisent chacune le type de A à leur manière avec de nouvelles méthodes. Et qu'il se trouve que A peut implémenter toutes ses méthodes à elle.

Citation:

---

Envoyé par thelvin

Je verrais plutôt une classe A qui a du code commun hérité de plusieurs classes abstraites BA et BB, qui spécialisent chacune le type de A à leur manière avec de nouvelles méthodes. Et qu'il se trouve que A peut implémenter toutes ses méthodes à elle.

---

Oui et ça c'est simplement de l'héritage. La classe ne fait pas grand chose en soit, les classe BA, BB spécialisent le besoin. Ca n'a rien a voir avec les classes abstraite. Pour moi faire une classe abstraite qui n'a pas de méthode abstraite, ca sent l'erreur de design.

Soit certaines méthode sont implémentées à vide -> Alors il aurait fallu les marquer abstraites.

Soit toutes les méthodes sont implémentées basiquement -> Alors on ne peut préjuger d'un besoin légitime de quelqu'un de l'utiliser en l'état car elle suffira à son besoin, elle n'a donc pas a être abstraite.

Citation:

---

Envoyé par tchize_

. Pour moi faire une classe abstraite qui n'a pas de méthode abstraite, ca sent l'erreur de design.

---

si le bon dieu l'a permis c'est que ça peut exister ;)....
j'ai un exemple un peu trop compliqué pour mettre sur le forum (ça implique des tas de classes paramétrées) mais on peut en trouver d'autres (pour des raisons qu'on a le droit d'estimer limites comme HttpServlet)