Héritage et déclaration de variable

Version imprimable

20/08/2012, 21h12
sheridan08

Héritage et déclaration de variable

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:

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:

B a=new B();

merci de votre compréhension
20/08/2012, 21h23
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.
21/08/2012, 00h09
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?
21/08/2012, 00h24
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 :)
21/08/2012, 10h11
sheridan08

Citation:

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 :calim2:

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

Code:

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

21/08/2012, 11h03
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é !
21/08/2012, 11h04
tchize_
Citation:

Envoyé par sheridan08

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 :calim2:

Et bien, tout simplement
Code:

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.
21/08/2012, 11h12
sheridan08

Citation:

Envoyé par 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é !

desolé mais ton exemple m'a encore plus perturbé :aie:, 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 )
21/08/2012, 11h20
sheridan08
Citation:
Envoyé par tchize_

Et bien, tout simplement

Code:

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:

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)
21/08/2012, 11h20
Népomucène

Citation:

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

Ah mince ! pourtant, je me disais qu'en prenant un exemple réel !
21/08/2012, 11h42
thelvin

Personnellement j'expliquerais les choses autrement...

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

Code:

A a = new B();

est mieux que

Code:

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:

A a = new B();

sera amélioré en

Code:

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.
21/08/2012, 12h18
sheridan08

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