Discussion :

[devdav]

Bonjour,

en déclarant une classe abstraite Oeuvres :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
public abstract class Oeuvres {
        protected String titre;
        protected int année;
	protected void lire(){
		System.out.println("Je lis une oeuvre");
	}
 
	abstract void ranger();
	abstract void vendre();
 
}

puis dans une autre classe en définissant la méthode void ranger() :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
public class Livres extends Oeuvres{
 
	public Livres(String pTitre, int pAnnée){
		this.titre=pTitre;
		this.année=pAnnée;
	}
 
	void ranger(){
		System.out.println("Je range un livre");
	}
}

ensuite dans une autre classe en définissant la méthode void vendre() :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public class Magazines extends Oeuvres{
 
	void vendre() {
		System.out.println("Je vend un magazine");
	}
}

ma classe Livres a un problème, qui se corrige en définissant dans cette classe la méthode void vendre() (méthode que j'ai déclarée dans Magazines).

Cela signifie-t-il que ma classe abstraite Livres doit obligatoirement définir toutes mes méthodes non définies de ma classe mère (à savoir ici Oeuvres) ?
Car bien que je définisse ma méthode void vendre() dans la classe suivante (Magazines), la classe Livres semble ne pas prendre cela en compte.

Merci d'avance, j'espère avoir été clair !
(bien que la question soit simple, je l'ai peut être un peu compliqué )

[Grom61736]

Cela signifie-t-il que ma classe abstraite Livres doit obligatoirement définir toutes mes méthodes non définies de ma classe mère (à savoir ici Oeuvres) ?

Dans le bout de code donné, la class Livre n'est pas abstraite.

1) Soit Livre est une classe "normale" et tu redéfinis les méthode de la classe abstraite
2) Soit Livre est une classe abstraite et tu ne dois pas redéfinir toutes les méthodes.

Car bien que je définisse ma méthode void vendre() dans la classe suivante (Magazines), la classe Livres semble ne pas prendre cela en compte.

Quelque chose a dû m'échapper car je ne vois pas le lien entre le classe Livre et Magazine.

[andry.aime]

Bonjour,

1-

abstract void ranger();
abstract void vendre();

Les méthodes déclarées sans bloc dans une classe abstraite ou dans un interface sont implicitement abstrait, donc inutile de mettre "abstract".

2- Les méthodes abstraits dans une classe abstraite ou dans un interface doivent être impérativement définit dans une classe concrète qui étend la classe ou implémente l'interface.

Avec ce que tu veux, je pense que c'est mieux de faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public interface rangeable{
	public void ranger();
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public interface vendable{
	public void vendre();
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
public abstract class Oeuvres {
        protected String titre;
        protected int année;
	protected void lire(){
		System.out.println("Je lis une oeuvre");
	}
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
public class Livres extends Oeuvres implements rangeable{
 
	public Livres(String pTitre, int pAnnée){
		this.titre=pTitre;
		this.année=pAnnée;
	}
 
	public void ranger(){
		System.out.println("Je range un livre");
	}
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public class Magazines extends Oeuvres implements vendable{
 
	public void vendre() {
		System.out.println("Je vend un magazine");
	}
}

Fait attentetion avec la visibilité protected.

A+.

[devdav]

Ah oui, j'avais oublié que les méthodes abstraites ne peuvent être définies que dans des classes abstraites (Livres ne l'est pas). Donc ça OK.

En fait Grom61736, j'ai mal réfléchis car en parlant des deux classes Livres et Magazines, je me suis dit "la classe Magazine va "comprendre" que j'ai définis la méthode ranger() dans Livres" mais c'est complètement faux comme raisonnement, je viens de m'en rendre compte.

Merci andry.aime pour ton détail de solution, bien que les interfaces soient dans le prochain chapitre

Grâce à vos réponses et en voyant mon code comme ça, je crois avoir davantage compris cette partie.

Question finale quand même : étant donnée qu'on peut déclarer plusieurs méthodes dans différentes classes abstraites, quand vient le moment de donner ces méthodes à un objet, on peut en oublier... Du coup, peut-on avoir une sorte de centralisation de toutes les méthodes abstraites déclarées ? Ou bien peut-on peut être déclarées toutes ces méthodes dans la classe abstraite mère puis les définir dans les filles ?

[hwoarang]

Question finale quand même : étant donnée qu'on peut déclarer plusieurs méthodes dans différentes classes abstraites, quand vient le moment de donner ces méthodes à un objet, on peut en oublier...

N'importe quel IDE te sortira une erreur sur la classe non abstraite héritant de ta classe abstraite en te disant qu'elle ne définit pas toutes les fonctions abstraites. Ils te permettront meme de créer les prototypes tout seul

Ou bien peut-on peut être déclarées toutes ces méthodes dans la classe abstraite mère puis les définir dans les filles ?

Je ne comprends pas la question. Mais il faut voir les classes abstraites ou les interfaces comme des contrats. Elles garantissent qu'une classe qui peut etre instanciée (donc non-abstraite) implémentera les fonctions abstraites de la classe mere. On est donc sur qu'on peut appeler ces fonctions quelle que soit la classe fille. J'insiste sur ces points parce que l'exemple que tu postes en #1 n'a aucun interet du point de vue objet/héritage donc je ne suis pas sur que ce concept est clair dans ta tete.

[devdav]

N'importe quel IDE te sortira une erreur sur la classe non abstraite héritant de ta classe abstraite en te disant qu'elle ne définit pas toutes les fonctions abstraites.

... parce que toutes les fonctions abstraites déclarées dans la classe abstraite principale doivent être déclarées (dans la mère ou les filles) avant de faire la classe non abstraite, c'est ça ?

Voici un exemple pour ma dernière question :

- Je crée ma classe main, ça OK;
- Je crée ma classe abstraite Arbre dans laquelle je déclare :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public abstract class Arbre {
	protected String couleur;
	protected int nombre;
	abstract void planter();
	abstract void couper();
}

- Je crée une classe abstraite fille Sapin où je définit void planter() et void () couper mais en plus je crée la méthode void arroser() :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
public abstract class Sapin extends Arbre {
	void planter(){
		System.out.println("Plantation d'un sapin");
	}
	void couper(){
		System.out.println("Il faut le couper");
	}
	void arroser(){
		System.out.println("Il faut arroser");
	}
}

- Puis je crée ma classe normale Pins :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public class Pins extends Sapin{
	public Pins(String pCouleur, int pNombre){
		this.couleur=pCouleur;
		this.nombre=pNombre;
	}
}

- Enfin je reviens dans ma classe main pour y créer mon objet Sapin s :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public class Main {
	public static void main(String[] args) {
 
		Pins p = new Pins("bleu", 200);
		p.couper();
		p.planter();
		p.arroser();
	}
}

Et là, tout fonctionne. Du coup, j'aurai aimé savoir si il y avait une astuce pour connaitre, au final, quelles sont toutes les méthodes abstraites que l'on a déclarée ? Car en regardant la classe abstraite principale Arbre, on en voit que deux, puisque j'en ai déclarée une autre dans Sapin
(genre un : System.out.print(lister_toutes_les_methodes_asbtraites_inclues_dans_mes_classes_abstraites_(donc_mère_et_filles));
Je sais que cette fonction n'existe pas hein, c'est juste pour mieux comprendre.

Je suis désolé d'embrouiller un peu la situation... En tout cas, c'est vachement sympa vos interventions, merci beaucoup !
Après ça, je vous embête plus, promis.

[Edit] Je viens de voir les interfaces. C'est pas mal du tout en fait. C'est comme une classe abstraite sans les implémentations (que l'on fait dans les classes normales). Je comprend maintenant ta réponse andry.aime

[Grom61736]

Oulà ! :S

Je n'ai aucune idée pour ta fonction "lister_toutes_les_methodes_asbtraites_inclues_dans_mes_classes_abstraites_(donc_mère_et_filles)".
D'ailleurs, je ne sais pas s'il y a un cas où c'est "utile" vu que ton IDE te dit quoi réimplémenter.

Cependant, si c'est la liste des méthodes possibles par ta class, tu peux utiliser la reflexivité Liste des méthodes publiques d'une classe.

[hwoarang]

... parce que toutes les fonctions abstraites déclarées dans la classe abstraite principale doivent être déclarées (dans la mère ou les filles) avant de faire la classe non abstraite, c'est ça ?

Une classe instanciable (donc non abstraite) doit avoir toutes ses méthodes déclarées. Et que ce soit sur elles memes ou l'une de ses classes meres, peu importe. Mais du coup, une classe instanciable qui hérite d'une classe abstraite doit implémenter toutes les méthodes abstraites.

Et là, tout fonctionne. Du coup, j'aurai aimé savoir si il y avait une astuce pour connaitre, au final, quelles sont toutes les méthodes abstraites que l'on a déclarée ? Car en regardant la classe abstraite principale Arbre, on en voit que deux, puisque j'en ai déclarée une autre dans Sapin

En général ton IDE t'indique si les méthodes de ta classe sont abstraites ou non. Ceci dit, au vu de tes questions (et des exemples), je suis curieux de savoir, d'apres toi, à quoi ca sert les méthodes abstraites ?