Discussion :

[sheridan08]

Bonsoir a tous,
j'ai quelque question en ce qui conserne l'heritage
supposons que j'ai une classe A
et une classe B qui herite de la classe A.
et qu' on est une declaration comme ceci:

Code :

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

A a=new B();

que signifie concrètement ce bout de code, que j'ai une variable de type A mais a la création c'est un objet de type B.
l'objet a a t'il accée au methode des deux classe?
et quelle est la difference entre cette declaration (qui pour moi est la meme)

Code :

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

B a=new B();

merci de votre compréhension

[Mathieu.J]

Dans les 2 cas, tu as bien 2 objets B.
Dans le premier tu n'auras accès qu'au membre déclarés dans A. Ton objet est "vu comme" un A mais et "se comporte comme" un B.

Dans le deuxième, tu auras accès à toutes les possibilités offertes par B.

En gros si ta classe B déclare une nouvelle méthode. Dans la première notation tu ne la verra pas. Alors que dans la deuxième oui.

[sheridan08]

quelle est alors l’intérêt d'avoir un objet qui se comporte comme une classe B mais qui au final n’accède qu'aux méthode de la classe A.
y'a t-il des cas ou on doit choisir tel ou tel déclaration?

[tchize_]

L'intéret c'est de passer ton B à des methodes ou des algorithme qui sont codés pour ne travailler qu'avec des A.

Quand j'utilise une voiture, pour avancer, reculer ou me garer, j'ai pas besoin de savoir que c'est une Dacia ou une Porshe. Le fait que ce soit une Voiture avec un volant et des pédales me suffit à l'usage. Mais quand je l'achête j'ai quand même besoin de choisir le modèle

[sheridan08]

Quand j'utilise une voiture, pour avancer, reculer ou me garer, j'ai pas besoin de savoir que c'est une Dacia ou une Porshe. Le fait que ce soit une Voiture avec un volant et des pédales me suffit à l'usage. Mais quand je l'achête j'ai quand même besoin de choisir le modèle

si je considère la classe voiture--> A
la classe porche-->B
B b=new B();

j'ai choisi mon modèle et je peux par la même occasion accéder au méthode de la classe mère.

ton exemple de m'a pas convaincu

[Mathieu.J]

Pour un cas simple oui.
Mais pour un cas un poil plus complexe (Même si un peu moche).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Voiture v = null;
switch(t) {
    case 1:
       v = new Porsche();
       break;
    case 2:
       v = new Peugeot();
       break;
    default:
       v = new AutreMarque();
}
v.avancer();

[Népomucène]

L'intérêt est de pouvoir faire un seul programme qui fonctionne pour des objets différents.

Exemple : on a un écran (JFrame). Sur cet écran, on a 5 composants :
- deux étiquettes (JLabel)
- deux zones de saisie (JTextField)
- un rectangle coloré en bleu (JPanel)

Le programme qui va placer ces 5 composants sur l'écran (JFrame)
ne connait pas les propriétés et les méthodes spécifiques de chacun
MAIS il sait qu'ils héritent tous de la classe Component et qu'ils sont donc rectangulaires.
Le programme va donc utiliser uniquement les dimensions externes des composants pour les placer.

Avec ce système, on peut se fabriquer tranquillement un nouveau JPanel qui hérite du JPanel bleu.
On lui ajoute une bordure verte
et on peut le placer dans notre JFrame car il sera à son tour vu comme un Component.

-> le programme de mise en page n'est jamais modifié !

[tchize_]

si je considère la classe voiture--> A
la classe porche-->B
B b=new B();

j'ai choisi mon modèle et je peux par la même occasion accéder au méthode de la classe mère.

ton exemple de m'a pas convaincu

Et bien, tout simplement

Code :

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

1
2
3
4
5
public class Conducteur {
 
 
     public void demarrer(Voiture v);
}

Je ne vais pas m'amuser à faire une méthode démarrer pour chaque type de voiture dans mon conducteur Les object servent à factoriser le code, il faut donc les utiliser comme tels. Ta méthode peux se contenter d'une voiture -> utilise une voiture plutot qu'une Renault (il y en faut pour tout le monde), ça évitera de devoir changer tout ton code si t'as une Ferrari demain.

[sheridan08]

L'intérêt est de pouvoir faire un seul programme qui fonctionne pour des objets différents.

Exemple : on a un écran (JFrame). Sur cet écran, on a 5 composants :
- deux étiquettes (JLabel)
- deux zones de saisie (JTextField)
- un rectangle coloré en bleu (JPanel)

Le programme qui va placer ces 5 composants sur l'écran (JFrame)
ne connait pas les propriétés et les méthodes spécifiques de chacun
MAIS il sait qu'ils héritent tous de la classe Component et qu'ils sont donc rectangulaires.
Le programme va donc utiliser uniquement les dimensions externes des composants pour les placer.

Avec ce système, on peut se fabriquer tranquillement un nouveau JPanel qui hérite du JPanel bleu.
On lui ajoute une bordure verte
et on peut le placer dans notre JFrame car il sera à son tour vu comme un Component.

-> le programme de mise en page n'est jamais modifié !

desolé mais ton exemple m'a encore plus perturbé , j'ai une très faible expérience en ce qui concerne la programmation évènementiel , ce que je voudrais c'est un exemple assez simple ( comme celui des voitures )

[sheridan08]

Et bien, tout simplement

Code :

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

1
2
3
4
5
public class Conducteur {
 
 
     public void demarrer(Voiture v);
}

Je ne vais pas m'amuser à faire une méthode démarrer pour chaque type de voiture dans mon conducteur Les object servent à factoriser le code, il faut donc les utiliser comme tels. Ta méthode peux se contenter d'une voiture -> utilise une voiture plutot qu'une Renault (il y en faut pour tout le monde), ça évitera de devoir changer tout ton code si t'as une Ferrari demain.

donc si je comprend bien:

Code :

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

1
2
3
4
5
6
Voiture v =new Porche()// j'ai choisi un modèle 
Voiture d =new Voiture();
Conducteur c=new Conducteur();
 
c.demarrer(v);// v est une voiture et donc le code compilera
c.demarrer(d)

[Népomucène]

desolé mais ton exemple m'a encore plus perturbé

Ah mince ! pourtant, je me disais qu'en prenant un exemple réel !

[thelvin]

Personnellement j'expliquerais les choses autrement...

Enfin, non, en fait, à mon avis on ne peut pas expliquer aux débutants pourquoi

Code :

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

A a = new B();

est mieux que

Code :

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

B b = new B();

Le débutant voit qu'avec la deuxième forme, il a accès à plus de choses, il peut faire plus de choses, donc c'est mieux !

Eh bien non. C'est l'inverse. Plus on peut faire de choses, moins le code sera bon. Mais ça, ça ne s'apprend pas facilement.
C'est un peu comme l'encapsulation, faire des champs private, ça sert à quoi de m'empêcher à moi-même de les utiliser dans d'autres classes ? Ça sert à se rappeler qu'on en a pas besoin, ça sert à ne pas s'embarrasser avec leur existence, donc à aller plus vite, ne pas faire d'erreur, et à mieux s'adapter au cas général.

C'est la même chose :
si tu fais B b = new B(), tu vas écrire ton code en utilisant un B, donc un code qui ne gère que les B.
Et c'est une erreur. Tu n'en avais pas besoin, tu aurais pu écrire un code qui gère tous les A, et c'est préférable, parce que la différence entre A et B ne t'intéresse pas : un A et un B ça se gare de la même manière, parce que tous les B sont aussi des A.

Un jour

Code :

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

A a = new B();

sera amélioré en

Code :

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

A a = récupérerUnA();

pour éviter de dupliquer du code.
Si tu étais parti de B b = new B();, tu te retrouverais donc à devoir rendre ton code compatible avec tous les A. Alors que ça ne servait à rien de le rendre incompatible au départ.

[sheridan08]

merci Thelvin , et merci a tous les autres c'est plus clair maintenant