bloqué sur l’exemple du cours 3-1 page 15

Programmation Avancée

Modérateur : Douin

daddy.K
Messages : 3
Inscription : 02 nov. 2018 12:52

bloqué sur l’exemple du cours 3-1 page 15

Message par daddy.K » 02 nov. 2018 13:04

Bonjour,

Je bloque sur l’exemple du cours 3-1 page 15 (Inscription tardive).

En visionnant la vidéo « Lecture 5 | Programming Methodology (Stanford) » du Professeur Mehran à propos des variables, objets et méthodes, ce que je comprends c’est qu’une variable se caractérise par un Nom, un Type et une Valeur.

Du coup :

- une Classe est une variable avec un nom donné, de type « Object » (l’objet racine, en gros le Big bang du programme car avant lui il n’y a rien) et de valeur ne faisant référence à rien (car non instancié càd non initialiser).

- une sous-Classe (Classe enfant), idem qu’une variable Classe mais récupère les Méthodes (voir ci-dessous) de la Classe au-dessus (héritage). Peut avoir ses Méthodes propres non présentes dans la Classe parent et peut modifier le comportement de la Méthode venant de la Classe parent (Overriding en français outrepasser. Ce qui en fait une sur-classe en termes de Méthodes car il peut en posséder plus que la classe parent dont il est issu. Non ?).

- Un Objet est une variable avec un nom donné, de type une Classe de notre programme et de valeur faisant référence à une Classe du programme. (« Classes as Types, Objects as Variables » dans la vidéo).

- Et pour agir sur ces variables, nous avons les méthodes qui eux se caractérisent par un nom donné, un type de valeur d’entrée attendue, des fonctions (suite d’action à exécuter) et produit un type de valeur attendue en sortie.

Donc dans l’exemple du cours 3-1 page 15, nous avons donc :

=> Classe Object
===> Classe A/type Object/référence null
=====> Méthode m / type de valeur d’entrée attendue Classe A / fonction afficher « m de A »
=====> Méthode n / type de valeur d’entrée attendue Classe A / fonction afficher «  n de A »
=====> Classe B/type Object/référence null
=======> Méthode main / type de valeur d’entrée attendue « string » / fonctions instancier et présenter
=========> Objet a/type Classe A/référence à la valeur de B
=========> Objet b/type Classe B/référence à la valeur de B
=========> présenter Objet a vers la Méthode m
=========> présenter Objet a vers la Méthode n
=======> Méthode m / type de valeur d’entrée attendue Classe A / fonction afficher « m de B »
=======> Méthode n / type de valeur d’entrée attendue Classe B / fonction afficher «  n de B »

Dans la Classe B on se retrouve donc avec 5 Méthodes :
2 héritées :
- Méthode m / type de valeur d’entrée attendue Classe A / fonction afficher « m de A »
- Méthode n / type de valeur d’entrée attendue Classe A / fonction afficher « n de A »
et 3 lui appartenant :
- Méthode main/ type de valeur d’entrée attendue « string »/fonctions instancier et présenter
- Méthode m / type de valeur d’entrée attendue Classe A / fonction afficher « m de B »
- Méthode n / type de valeur d’entrée attendue Classe B / fonction afficher « n de B »

Mais il se retrouve que la Méthode « m » héritée de la Classe A porte le même nom et attend le même type de valeur que celle présente dans la Classe B donc la Méthode « m » héritée passe à la trappe.

Il ne nous reste donc que 4 Méthodes pour la Classe B :
- Méthode n / type de valeur d’entrée attendue Classe A / fonction afficher « n de A »
- Méthode main / type de valeur d’entrée attendue « string »/fonctions instancier et présenter
- Méthode m / type de valeur d’entrée attendue Classe A / fonction afficher « m de B »
- Méthode n / type de valeur d’entrée attendue Classe B / fonction afficher « n de B »

Exécution de la Méthode « main » de la classe B (B.main) :
- main présente Objet a/type A/réf. B à la Méthode m/type attendu A ça match donc « m de B »
- main présente Objet a/type A/réf. B à la Méthode n/type attendu A ça match donc « n de A »

- main ne peut présenter Objet a/type A/réf B à la Méthode n/type attendu B car le type en entrée et celle attendu diffère.

Il aurait fallu avant de le présenter « caster » l’Objet « a » avec « a = (B) a » et là il n’y aurait eu qu’un seul résultat qui aurait été « n de B ».

Ai-je bien compris la logique du truc ou je suis vraiment à la ramasse ?

Du coup je me demande :

- Est-ce que le type de valeur attendu en sortie joue également dans le passage à la trappe d’une Méthode héritée (la composition de sa signature) ?

- Peut-on considérer la variable Objet comme une sous-Classe tronqué car ne possédant pas ses propres méthodes ?

- Peut-on dire qu’une variable sous-Classe est un Objet non tronqué car possède une valeur faisant référence à sa Classe parent et peut posséder ses propres Méthodes ?


Lien vers la vidéo en anglais : https://www.youtube.com/watch?v=NPzPnycCFuE

Douin
Messages : 342
Inscription : 18 mars 2009 15:46

Re: bloqué sur l’exemple du cours 3-1 page 15

Message par Douin » 02 nov. 2018 17:23

Bonjour
Il aurait fallu avant de le présenter « caster » l’Objet « a » avec « a = (B) a » et là il n’y aurait eu qu’un seul résultat qui aurait été « n de B ».
Attention cela n'aurait aucun effet, faites le test avec bluej
- Est-ce que le type de valeur attendu en sortie joue également dans le passage à la trappe d’une Méthode héritée (la composition de sa signature) ?
Je préfère redéfinition, masquage d'une méthode au passage à la trappe d’une Méthode héritée

regardez le support 3, une diapositive nommée covariance
- Peut-on considérer la variable Objet comme une sous-Classe tronqué car ne possédant pas ses propres méthodes ?
- Peut-on dire qu’une variable sous-Classe est un Objet non tronqué car possède une valeur faisant référence à sa Classe parent et peut posséder ses propres Méthodes ?
Je ne suis pas sûr de bien comprendre vos termes de variable sous-classe tronqué et une variable sous-Classe est un Objet non tronqué ?

Bonnes lectures

daddy.K
Messages : 3
Inscription : 02 nov. 2018 12:52

Re: bloqué sur l’exemple du cours 3-1 page 15

Message par daddy.K » 02 nov. 2018 23:46

Effectivement BlueJ accepte la syntaxe "a = (B) a" et la compile mais le résultat de la commande reste la même, à savoir "m de B" et "n de A".
À creuser plus tard si j'arrive à rattraper mon retard dans les TP.

Par contre en changeant "A a = new B()" en "B a = new B()" je reçois bien "n de B" mais aussi et ça m'a étonné "m de B".
Pareil à creuser plus tard.
Je préfère redéfinition, masquage d'une méthode au passage à la trappe d’une Méthode héritée
Effectivement vous avez raison elle est masquer mais pas jeter.

Je ne suis pas sûr de bien comprendre vos termes de variable sous-classe tronqué et une variable sous-Classe est un Objet non tronqué ?
C'est vrai qu'avec Java ce n'est pas simple de définir les chose car tout y est considérer comme objet.
Ce que je voulais dire c'est si tout est objet y compris les Classes, peut on considérer les objets (ici les instances de classe) comme des sous-classe (un peu comme B est une sous-classe de A) qui n'héritent d'aucune méthode (d’où mon "tronquer") et à l'inverse les sous-classe (les classes qui héritent) comme des objets (instances de classe) non tronqués car comme les objets (les instances de classe) elles ont comme valeur une référence vers la classe parent mais possède des méthodes.

Mais bon, pour ces deux dernières question j'ai trouvé la réponse dans votre vidéo avec l'analogie UNIX.
Dans UNIX tout est fichier (objet dans java), les dossiers (classes dans java) sont aussi des fichiers qui contiennent d'autres fichiers.
Par contre, tout les fichiers ne sont pas des dossiers.
Au final, on peut considérer que tous ces fichiers (objets dans java) pointent vers des bits sur le disque dur (variables en mémoire pour java) auquel les fichiers (objets dans java) font référence.

Merci en tous les cas pour votre aide et pour avoir pris le temps de répondre à mes questions.
Il ne me reste plus qu'a me pencher sur la covariance et les fameux "Patterns".

daddy.K
Messages : 3
Inscription : 02 nov. 2018 12:52

Re: bloqué sur l’exemple du cours 3-1 page 15

Message par daddy.K » 04 nov. 2018 21:18

Ce n’était pas facile mais je crois comprendre maintenant.

En gros Java c’est un peu comme une société ou règne le népotisme.
Tout est objet mais, si tu hérites des méthodes qu’il faut, tu peux t’affranchir de certaines règles.

Les primitives par exemple peuvent être caster. Ce qui m’a conduit à penser que tous les objets pouvaient l’être. Ce qui semble être faux.

Les objets, une fois créer sont immuables. On ne peut donc pas les caster même si la syntaxe en soit n’est pas fausses (car utilisée par certains héritiers).

Pour la covariance, venant du monde des réseaux, si je n’ai pas un schéma avec pleins de Switchs/routeurs et pleins de flèches partout, je suis perdu. Et j’avoue que même en relisant plusieurs fois le support de cours, c’était le brouillard.

Et je suis tombé sur ça : https://i.stack.imgur.com/6MQ16.png
Là, ça semble un peu plus clair.

Divertissement => musique => Métal
Clown => Producteur de musique => Producteur de Métal

Un clown produit du divertissement mais pas de Métal.
À l’inverse un producteur de Métal produit les trois (divertissement, musique et Métal).

Donc les méthodes de la classe Métal retourne aussi bien du divertissement, de la musique et du Métal.
Ceux de la classe musique de la musique et du divertissement alors que ceux de la classe divertissement que du divertissement.

Ce qui pourrait expliquer pourquoi "B a = new B()" retourne "n de B" et "m de B".

Répondre

Qui est en ligne ?

Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 1 invité