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();

[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.

[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é !

[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 )