Que fait-on avec l'instruction suivante : A o1=new B();
[...]
[...]
En fait c'est pas ça que j'aurais dû demander depuis le début mais plutôt quelle est la différence entre les deux instructions suivantes et quelles sont les conséquences pour la deuxième instruction au niveau de l'accès des données de la classe A puis de la classe B :
A o1=new A(); A o2=new B();
Je te disais dans mon précédant post, que la classe /B/ devait être une classe concrète dérivée du type /A/. J'aurrais dû dir que la classe /B/ devait être soit une classe concrète dérivée du type /A/ soit la classe /A/ elle-même.
Ce faisant, la ligne de code /A o1 = new A()/ n'est qu'un cas remarcable de la forme /A o2 = new B()/, où /B/ est /A/. Le fait que la classe concrète de la partie droite soit équivalente au type de la partie gauche n'implique rien de particulier pour la suite.
*Pour aller plus loint* :
Pour le modele objet, Grady Boosh définit un objet comme suit :
objet = identité + interface + comportement
Rapporté au langage Java on pourrait dire : - que le constructeur /B()/ (ou /A()/) spécifie le _comportement_ possible, - que l'instruction /new/ assure l'_identité_ - et que la partie gauche définit l'_interface_ à travers là quel on "pilotera" l'objet.
En Java, le fait que le type /A/ ait un rapport hiérarchique avec la classe /B/ (ou /A/) tient au seulement fait que ce langage est typé.
*Conseille de programmation* :
Autant ce fair ce peut, pour découpler l'impléméntation de l'utilisation, fais en sorte que la partie gauche (le type /A/) soit une interface au sens Java et non une classe.
Valdo.
Lea wrote:
Lea wrote:
Que fait-on avec l'instruction suivante :
A o1=new B();
[...]
[...]
En fait c'est pas ça que j'aurais dû demander depuis le début mais
plutôt quelle est la différence entre les deux instructions suivantes et
quelles sont les conséquences pour la deuxième instruction au niveau de
l'accès des données de la classe A puis de la classe B :
A o1=new A();
A o2=new B();
Je te disais dans mon précédant post, que la classe /B/ devait être une
classe concrète dérivée du type /A/. J'aurrais dû dir que la classe /B/
devait être soit une classe concrète dérivée du type /A/ soit la classe
/A/ elle-même.
Ce faisant, la ligne de code /A o1 = new A()/ n'est qu'un cas remarcable
de la forme /A o2 = new B()/, où /B/ est /A/. Le fait que la classe
concrète de la partie droite soit équivalente au type de la partie
gauche n'implique rien de particulier pour la suite.
*Pour aller plus loint* :
Pour le modele objet, Grady Boosh définit un objet comme suit :
objet = identité + interface + comportement
Rapporté au langage Java on pourrait dire :
- que le constructeur /B()/ (ou /A()/) spécifie le _comportement_ possible,
- que l'instruction /new/ assure l'_identité_
- et que la partie gauche définit l'_interface_ à travers là quel on
"pilotera" l'objet.
En Java, le fait que le type /A/ ait un rapport hiérarchique avec la
classe /B/ (ou /A/) tient au seulement fait que ce langage est typé.
*Conseille de programmation* :
Autant ce fair ce peut, pour découpler l'impléméntation de
l'utilisation, fais en sorte que la partie gauche (le type /A/) soit une
interface au sens Java et non une classe.
Que fait-on avec l'instruction suivante : A o1=new B();
[...]
[...]
En fait c'est pas ça que j'aurais dû demander depuis le début mais plutôt quelle est la différence entre les deux instructions suivantes et quelles sont les conséquences pour la deuxième instruction au niveau de l'accès des données de la classe A puis de la classe B :
A o1=new A(); A o2=new B();
Je te disais dans mon précédant post, que la classe /B/ devait être une classe concrète dérivée du type /A/. J'aurrais dû dir que la classe /B/ devait être soit une classe concrète dérivée du type /A/ soit la classe /A/ elle-même.
Ce faisant, la ligne de code /A o1 = new A()/ n'est qu'un cas remarcable de la forme /A o2 = new B()/, où /B/ est /A/. Le fait que la classe concrète de la partie droite soit équivalente au type de la partie gauche n'implique rien de particulier pour la suite.
*Pour aller plus loint* :
Pour le modele objet, Grady Boosh définit un objet comme suit :
objet = identité + interface + comportement
Rapporté au langage Java on pourrait dire : - que le constructeur /B()/ (ou /A()/) spécifie le _comportement_ possible, - que l'instruction /new/ assure l'_identité_ - et que la partie gauche définit l'_interface_ à travers là quel on "pilotera" l'objet.
En Java, le fait que le type /A/ ait un rapport hiérarchique avec la classe /B/ (ou /A/) tient au seulement fait que ce langage est typé.
*Conseille de programmation* :
Autant ce fair ce peut, pour découpler l'impléméntation de l'utilisation, fais en sorte que la partie gauche (le type /A/) soit une interface au sens Java et non une classe.
Valdo.
Valdo Tschantre
Lea wrote:
Je suis pas sûre de tout avoir compris :
Je ne suis pas connu pour ma grande pédagogie... ;)
la référence o1 construite avec les données, constructeurs et méthodes de la classe B "se situe" dans la classe A ou B?
*Exemple* :
<code>
public interface A { public void uneMethode(); }
public class B implements A { public B() { //... } public void uneMethode() { //... } public void uneAutreMethode() { //... } }
public class Main { public static void main(String[] args) { A r1 = new B(); r1.uneMethode(); // OK. r1.uneAutreMethode(); // ERREUR! } }
</code>
*Remarque* :
J'utilise /r1/ et non /o1/ pour bien souligner que ce n'est pas un objet mais une référence. Attention, dans la pratique, nous avons tendance à interchanger ces termes. En java, il y a des identifiants pour les référence (/r1/), les méthodes (/uneMethode/), les classes (/B/), les types primitifs, etc., mais il n'y en a pas pour les objets !
Valdo.
Lea wrote:
Je suis pas sûre de tout avoir compris :
Je ne suis pas connu pour ma grande pédagogie... ;)
la référence o1 construite avec les données, constructeurs et méthodes
de la classe B "se situe" dans la classe A ou B?
*Exemple* :
<code>
public interface A {
public void uneMethode();
}
public class B implements A {
public B() {
//...
}
public void uneMethode() {
//...
}
public void uneAutreMethode() {
//...
}
}
public class Main {
public static void main(String[] args) {
A r1 = new B();
r1.uneMethode(); // OK.
r1.uneAutreMethode(); // ERREUR!
}
}
</code>
*Remarque* :
J'utilise /r1/ et non /o1/ pour bien souligner que ce n'est pas un objet
mais une référence. Attention, dans la pratique, nous avons tendance à
interchanger ces termes. En java, il y a des identifiants pour les
référence (/r1/), les méthodes (/uneMethode/), les classes (/B/), les
types primitifs, etc., mais il n'y en a pas pour les objets !
Je ne suis pas connu pour ma grande pédagogie... ;)
la référence o1 construite avec les données, constructeurs et méthodes de la classe B "se situe" dans la classe A ou B?
*Exemple* :
<code>
public interface A { public void uneMethode(); }
public class B implements A { public B() { //... } public void uneMethode() { //... } public void uneAutreMethode() { //... } }
public class Main { public static void main(String[] args) { A r1 = new B(); r1.uneMethode(); // OK. r1.uneAutreMethode(); // ERREUR! } }
</code>
*Remarque* :
J'utilise /r1/ et non /o1/ pour bien souligner que ce n'est pas un objet mais une référence. Attention, dans la pratique, nous avons tendance à interchanger ces termes. En java, il y a des identifiants pour les référence (/r1/), les méthodes (/uneMethode/), les classes (/B/), les types primitifs, etc., mais il n'y en a pas pour les objets !
Valdo.
ZebX
J'utilise /r1/ et non /o1/ pour bien souligner que ce n'est pas un objet mais une référence. Attention, dans la pratique, nous avons tendance à interchanger ces termes. En java, il y a des identifiants pour les référence (/r1/), les méthodes (/uneMethode/), les classes (/B/), les types primitifs, etc., mais il n'y en a pas pour les objets !
Ton approche de l'objet (en dehors de Java proprement dit) m'interresse. As tu un livre en francais à me conseiller sur le sujet ?
J'utilise /r1/ et non /o1/ pour bien souligner que ce n'est pas un objet
mais une référence. Attention, dans la pratique, nous avons tendance à
interchanger ces termes. En java, il y a des identifiants pour les
référence (/r1/), les méthodes (/uneMethode/), les classes (/B/), les
types primitifs, etc., mais il n'y en a pas pour les objets !
Ton approche de l'objet (en dehors de Java proprement dit) m'interresse.
As tu un livre en francais à me conseiller sur le sujet ?
J'utilise /r1/ et non /o1/ pour bien souligner que ce n'est pas un objet mais une référence. Attention, dans la pratique, nous avons tendance à interchanger ces termes. En java, il y a des identifiants pour les référence (/r1/), les méthodes (/uneMethode/), les classes (/B/), les types primitifs, etc., mais il n'y en a pas pour les objets !
Ton approche de l'objet (en dehors de Java proprement dit) m'interresse. As tu un livre en francais à me conseiller sur le sujet ?
Wismerhill
ZebX ecrivit le 25/02/2005 13:01 :
J'utilise /r1/ et non /o1/ pour bien souligner que ce n'est pas un objet mais une référence. Attention, dans la pratique, nous avons tendance à interchanger ces termes. En java, il y a des identifiants pour les référence (/r1/), les méthodes (/uneMethode/), les classes (/B/), les types primitifs, etc., mais il n'y en a pas pour les objets !
Ton approche de l'objet (en dehors de Java proprement dit) m'interresse. As tu un livre en francais à me conseiller sur le sujet ?
Bin heu, n'importe quel bouquin sur la programmation objet vu que ce sont les principes de base.
ZebX ecrivit le 25/02/2005 13:01 :
J'utilise /r1/ et non /o1/ pour bien souligner que ce n'est pas un objet
mais une référence. Attention, dans la pratique, nous avons tendance à
interchanger ces termes. En java, il y a des identifiants pour les
référence (/r1/), les méthodes (/uneMethode/), les classes (/B/), les
types primitifs, etc., mais il n'y en a pas pour les objets !
Ton approche de l'objet (en dehors de Java proprement dit) m'interresse.
As tu un livre en francais à me conseiller sur le sujet ?
Bin heu, n'importe quel bouquin sur la programmation objet vu que ce
sont les principes de base.
J'utilise /r1/ et non /o1/ pour bien souligner que ce n'est pas un objet mais une référence. Attention, dans la pratique, nous avons tendance à interchanger ces termes. En java, il y a des identifiants pour les référence (/r1/), les méthodes (/uneMethode/), les classes (/B/), les types primitifs, etc., mais il n'y en a pas pour les objets !
Ton approche de l'objet (en dehors de Java proprement dit) m'interresse. As tu un livre en francais à me conseiller sur le sujet ?
Bin heu, n'importe quel bouquin sur la programmation objet vu que ce sont les principes de base.
ZebX
Bin heu, n'importe quel bouquin sur la programmation objet vu que ce sont les principes de base.
Ce qui est écrit oui, mais je ne pense pas que la culture de Valdo s'arrete là...
Les bouquins sur l'objet que je connais sont soient opérationnels, soient très évasifs.
Bin heu, n'importe quel bouquin sur la programmation objet vu que ce
sont les principes de base.
Ce qui est écrit oui, mais je ne pense pas que la culture de Valdo
s'arrete là...
Les bouquins sur l'objet que je connais sont soient opérationnels,
soient très évasifs.
Si A est un Object et B hérite de A et possède l'attribut couleur.
o1 n'a pas d'attribut couleur. o2 possède mais ne peut pas accéder à l'attribut couleur.
Pourquoi o2 ne peut accéder à la couleur?
o3 possède et accède à l'attribut couleur.
Lea
Lea wrote:
Lea wrote:
Que fait-on avec l'instruction suivante : A o1=new B();
[...]
[...]
En fait c'est pas ça que j'aurais dû demander depuis le début mais plutôt quelle est la différence entre les deux instructions suivantes et quelles sont les conséquences pour la deuxième instruction au niveau de l'accès des données de la classe A puis de la classe B :
A o1=new A(); A o2=new B();
Je te disais dans mon précédant post, que la classe /B/ devait être une classe concrète dérivée du type /A/. J'aurrais dû dir que la classe /B/ devait être soit une classe concrète dérivée du type /A/ soit la classe /A/ elle-même.
Ce faisant, la ligne de code /A o1 = new A()/ n'est qu'un cas remarcable de la forme /A o2 = new B()/, où /B/ est /A/. Que faut-il comprendre par "cas remarquable"?
Le fait que la classe concrète de la partie droite soit équivalente au type de la partie gauche n'implique rien de particulier pour la suite.
Mais alors pourquoi se donner la peine de l'écrire sous la forme A o2=new B();
*Pour aller plus loint* :
Pour le modele objet, Grady Boosh définit un objet comme suit :
objet = identité + interface + comportement
Rapporté au langage Java on pourrait dire : - que le constructeur /B()/ (ou /A()/) spécifie le _comportement_ possible, - que l'instruction /new/ assure l'_identité_ - et que la partie gauche définit l'_interface_ à travers là quel on "pilotera" l'objet.
J'ai pas vu la notion d'interface encore mais je pense que l'on peut dire aussi que la partie gauche définit l'_interface_ ou la classe à travers laquelle on "pilotera" l'objet, non?
Quelles seront les conséquences concernant l'accès des données et méthodes de la classe B si l'on pilote à partir de la classe A et non pas de la classe B?
En Java, le fait que le type /A/ ait un rapport hiérarchique avec la classe /B/ (ou /A/) tient au seulement fait que ce langage est typé.
*Conseille de programmation* :
Autant ce fair ce peut, pour découpler l'impléméntation de l'utilisation, fais en sorte que la partie gauche (le type /A/) soit une interface au sens Java et non une classe.
Pourquoi?
Valdo.
Lea wrote:
Lea wrote:
Que fait-on avec l'instruction suivante :
A o1=new B();
[...]
[...]
En fait c'est pas ça que j'aurais dû demander depuis le début mais
plutôt quelle est la différence entre les deux instructions suivantes
et quelles sont les conséquences pour la deuxième instruction au
niveau de l'accès des données de la classe A puis de la classe B :
A o1=new A();
A o2=new B();
Je te disais dans mon précédant post, que la classe /B/ devait être une
classe concrète dérivée du type /A/. J'aurrais dû dir que la classe /B/
devait être soit une classe concrète dérivée du type /A/ soit la classe
/A/ elle-même.
Ce faisant, la ligne de code /A o1 = new A()/ n'est qu'un cas remarcable
de la forme /A o2 = new B()/, où /B/ est /A/.
Que faut-il comprendre par "cas remarquable"?
Le fait que la classe
concrète de la partie droite soit équivalente au type de la partie
gauche n'implique rien de particulier pour la suite.
Mais alors pourquoi se donner la peine de l'écrire sous la forme A
o2=new B();
*Pour aller plus loint* :
Pour le modele objet, Grady Boosh définit un objet comme suit :
objet = identité + interface + comportement
Rapporté au langage Java on pourrait dire :
- que le constructeur /B()/ (ou /A()/) spécifie le _comportement_ possible,
- que l'instruction /new/ assure l'_identité_
- et que la partie gauche définit l'_interface_ à travers là quel on
"pilotera" l'objet.
J'ai pas vu la notion d'interface encore mais je pense que l'on peut
dire aussi que la partie gauche définit l'_interface_ ou la classe à
travers laquelle on "pilotera" l'objet, non?
Quelles seront les conséquences concernant l'accès des données et
méthodes de la classe B si l'on pilote à partir de la classe A et non
pas de la classe B?
En Java, le fait que le type /A/ ait un rapport hiérarchique avec la
classe /B/ (ou /A/) tient au seulement fait que ce langage est typé.
*Conseille de programmation* :
Autant ce fair ce peut, pour découpler l'impléméntation de
l'utilisation, fais en sorte que la partie gauche (le type /A/) soit une
interface au sens Java et non une classe.
Que fait-on avec l'instruction suivante : A o1=new B();
[...]
[...]
En fait c'est pas ça que j'aurais dû demander depuis le début mais plutôt quelle est la différence entre les deux instructions suivantes et quelles sont les conséquences pour la deuxième instruction au niveau de l'accès des données de la classe A puis de la classe B :
A o1=new A(); A o2=new B();
Je te disais dans mon précédant post, que la classe /B/ devait être une classe concrète dérivée du type /A/. J'aurrais dû dir que la classe /B/ devait être soit une classe concrète dérivée du type /A/ soit la classe /A/ elle-même.
Ce faisant, la ligne de code /A o1 = new A()/ n'est qu'un cas remarcable de la forme /A o2 = new B()/, où /B/ est /A/. Que faut-il comprendre par "cas remarquable"?
Le fait que la classe concrète de la partie droite soit équivalente au type de la partie gauche n'implique rien de particulier pour la suite.
Mais alors pourquoi se donner la peine de l'écrire sous la forme A o2=new B();
*Pour aller plus loint* :
Pour le modele objet, Grady Boosh définit un objet comme suit :
objet = identité + interface + comportement
Rapporté au langage Java on pourrait dire : - que le constructeur /B()/ (ou /A()/) spécifie le _comportement_ possible, - que l'instruction /new/ assure l'_identité_ - et que la partie gauche définit l'_interface_ à travers là quel on "pilotera" l'objet.
J'ai pas vu la notion d'interface encore mais je pense que l'on peut dire aussi que la partie gauche définit l'_interface_ ou la classe à travers laquelle on "pilotera" l'objet, non?
Quelles seront les conséquences concernant l'accès des données et méthodes de la classe B si l'on pilote à partir de la classe A et non pas de la classe B?
En Java, le fait que le type /A/ ait un rapport hiérarchique avec la classe /B/ (ou /A/) tient au seulement fait que ce langage est typé.
*Conseille de programmation* :
Autant ce fair ce peut, pour découpler l'impléméntation de l'utilisation, fais en sorte que la partie gauche (le type /A/) soit une interface au sens Java et non une classe.
Pourquoi?
Valdo.
ZebX
Pourquoi o2 ne peut accéder à la couleur? Parce que o2 "croit" qu'il référence une instance de A et non de B. Or A
n'a pas de couleur. Si tu complètes par o3 = o2; tu peux alors accéder à la couleur de o2 via la référence o3. Si tu fais o2 = o3, le compilateur te jette car o2 n'a pas la capacité de représenter une référence sur B ;
Maintenant dans la pratique, c'est util pour simplifier l'usage de ton code.
Tu crées la classe GestionRessourcesHumaines :) et tu donnes une interface (vue limitée) IComptable au comptable, IProjet au chef de projet et IEmbauche au recruteur...
Chacun ne voit que la partie qui le concerne : plus simple à produire -tu peux morcellé ton dev plus simple à utiliser - l'interface est ton "seul engagement" vis à vis des utilisateurs de ta classe. et moins d'effet de bord dans la vie du produit par rapport à une application mainframe par exemple :)
Pourquoi o2 ne peut accéder à la couleur?
Parce que o2 "croit" qu'il référence une instance de A et non de B. Or A
n'a pas de couleur.
Si tu complètes par o3 = o2; tu peux alors accéder à la couleur de o2
via la référence o3.
Si tu fais o2 = o3, le compilateur te jette car o2 n'a pas la capacité
de représenter une référence sur B ;
Maintenant dans la pratique, c'est util pour simplifier l'usage de ton code.
Tu crées la classe GestionRessourcesHumaines :) et tu donnes une
interface (vue limitée) IComptable au comptable, IProjet au chef de
projet et IEmbauche au recruteur...
Chacun ne voit que la partie qui le concerne :
plus simple à produire -tu peux morcellé ton dev
plus simple à utiliser - l'interface est ton "seul engagement" vis à vis
des utilisateurs de ta classe.
et moins d'effet de bord dans la vie du produit par rapport à une
application mainframe par exemple :)
Pourquoi o2 ne peut accéder à la couleur? Parce que o2 "croit" qu'il référence une instance de A et non de B. Or A
n'a pas de couleur. Si tu complètes par o3 = o2; tu peux alors accéder à la couleur de o2 via la référence o3. Si tu fais o2 = o3, le compilateur te jette car o2 n'a pas la capacité de représenter une référence sur B ;
Maintenant dans la pratique, c'est util pour simplifier l'usage de ton code.
Tu crées la classe GestionRessourcesHumaines :) et tu donnes une interface (vue limitée) IComptable au comptable, IProjet au chef de projet et IEmbauche au recruteur...
Chacun ne voit que la partie qui le concerne : plus simple à produire -tu peux morcellé ton dev plus simple à utiliser - l'interface est ton "seul engagement" vis à vis des utilisateurs de ta classe. et moins d'effet de bord dans la vie du produit par rapport à une application mainframe par exemple :)
