>
Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
questions..
L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
>
Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
questions..
L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
>
Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
questions..
L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
questions..
L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
Bonjour,
Alors va voir ça si tu connais pas déjà l'adresse
http://ftp.lami.univ-evry.fr/pub/specif/fzaidi/UML%20pam.pdf
La version 2.0 est dispo en librairie.
J'ai lu ça il y a pas longtemps et ça change radicalement la façon de voir
les choses.
Christophe
Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
questions..
L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
Bonjour,
Alors va voir ça si tu connais pas déjà l'adresse
http://ftp.lami.univ-evry.fr/pub/specif/fzaidi/UML%20pam.pdf
La version 2.0 est dispo en librairie.
J'ai lu ça il y a pas longtemps et ça change radicalement la façon de voir
les choses.
Christophe
Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
questions..
L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
Bonjour,
Alors va voir ça si tu connais pas déjà l'adresse
http://ftp.lami.univ-evry.fr/pub/specif/fzaidi/UML%20pam.pdf
La version 2.0 est dispo en librairie.
J'ai lu ça il y a pas longtemps et ça change radicalement la façon de voir
les choses.
Christophe
"Patrice Henrio" a écrit dans le
message de news:
Puisque nous en sommes aux questions théoriques, en voici une sur les
propriétés des objets ou classes.
Pourquoi faut-il les déclarer private et créer des procédures de lecture
etd'écriture ?
En effet, à priori je sais ce que je programme et il me semble plus
simple
décrire directement
objet.nom="Machin" ou if objet.condition then
sans que le programme fasse le détour par objet.setNom("Machin"), ou
objet.GetCondition.
Or dans les cours sur la POO (programmation orientée objet) on insiste
biensur le fait qu'il ne faut pas manipuler directement les propriétés. Je
repose ma question pourquoi ?
Je comprends si l'affectation doit faire plusieurs chose, par exemple en
plus de rentrer la propriété nom, renseigner la propriété longueur du
nom,
mais dans la plupart des cas nous avons
property get Nom()
Nom=m_Nom
end property
property set Nom(string Nom)
m_nom=Nom
end property
Bonjour Patrice,
Lisant -a temps perdu- de vieux messages,
(et apprenant avec bcp d'interet les "SOLUTIONS POUR LA FONCTION PUBLIQUE"
precedents,
je vais rapidement te donner une "excellente" raison pratique
pour /en objet/ TOUJORUS passer par des Methodes, et non l'accès direct
aux
données !
Tu sais que l'objectif /l'un des../ de l'objet, est de garantir
independance
entre
code interne et externe de l'objet, en d'autres terme entre utilisation
et implementation (la façon dont c'est rtaité au niveau binaire ou...).
Passer par ces "méthodes" (le nom courant en technologie objet) libère le
programmeur utilisateur
de toute contrainte a ce niveau : un exemple => je viens de voir que
Currency disparait avec VB.NET
Comment vai-je choisir de le re-intercaler ?
dans certains cas, la precision Simple suffira, dans d'autre DOUBLE ou
meme Integer !
- quelque soir le choix du programmeur de la classe qui va refaire
l'implementation,
apr exemple en utilisant une classe de "COMPLEX" (idée farfelue en
l'occurrence),
avec en particulier une partie réelle partielle, ton programme utilisateur
ne sera pas concerné
du moment que tu respectes strictement l'interface de programmation.
Autre solution :un exemple que j'ai tres souvent pris dans l'enseignement
:
imagine que tu doive coder "APPRENDRE" pour ton personnel !
en anglais aucun probleme, en tre TEACH et LEARN,
en francias, il faudra distinguer Eleve.Apprendre et
Professeur.Apprendre...
Dans le cas particulier des Noms puisque c'etait ton exemple,
imagine que nous décidions de gérer les Noms avec un controle
d'orthographe
et de formattage :
il suffit de rajouter dans le Set Nom le controle garantissant
automatiquement
la transformation des Espaces CHR(20) en CHR(255) pour avoir un format non
déformable, etc....
Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
questions..
L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
ydx35[NO_SAPM]at_YahOOOOOO.fr
"Patrice Henrio" <patrice.henrio.pasdepub@laposte.net> a écrit dans le
message de news:eED34v5hEHA.356@tk2msftngp13.phx.gbl...
Puisque nous en sommes aux questions théoriques, en voici une sur les
propriétés des objets ou classes.
Pourquoi faut-il les déclarer private et créer des procédures de lecture
et
d'écriture ?
En effet, à priori je sais ce que je programme et il me semble plus
simple
décrire directement
objet.nom="Machin" ou if objet.condition then
sans que le programme fasse le détour par objet.setNom("Machin"), ou
objet.GetCondition.
Or dans les cours sur la POO (programmation orientée objet) on insiste
bien
sur le fait qu'il ne faut pas manipuler directement les propriétés. Je
repose ma question pourquoi ?
Je comprends si l'affectation doit faire plusieurs chose, par exemple en
plus de rentrer la propriété nom, renseigner la propriété longueur du
nom,
mais dans la plupart des cas nous avons
property get Nom()
Nom=m_Nom
end property
property set Nom(string Nom)
m_nom=Nom
end property
Bonjour Patrice,
Lisant -a temps perdu- de vieux messages,
(et apprenant avec bcp d'interet les "SOLUTIONS POUR LA FONCTION PUBLIQUE"
precedents,
je vais rapidement te donner une "excellente" raison pratique
pour /en objet/ TOUJORUS passer par des Methodes, et non l'accès direct
aux
données !
Tu sais que l'objectif /l'un des../ de l'objet, est de garantir
independance
entre
code interne et externe de l'objet, en d'autres terme entre utilisation
et implementation (la façon dont c'est rtaité au niveau binaire ou...).
Passer par ces "méthodes" (le nom courant en technologie objet) libère le
programmeur utilisateur
de toute contrainte a ce niveau : un exemple => je viens de voir que
Currency disparait avec VB.NET
Comment vai-je choisir de le re-intercaler ?
dans certains cas, la precision Simple suffira, dans d'autre DOUBLE ou
meme Integer !
- quelque soir le choix du programmeur de la classe qui va refaire
l'implementation,
apr exemple en utilisant une classe de "COMPLEX" (idée farfelue en
l'occurrence),
avec en particulier une partie réelle partielle, ton programme utilisateur
ne sera pas concerné
du moment que tu respectes strictement l'interface de programmation.
Autre solution :un exemple que j'ai tres souvent pris dans l'enseignement
:
imagine que tu doive coder "APPRENDRE" pour ton personnel !
en anglais aucun probleme, en tre TEACH et LEARN,
en francias, il faudra distinguer Eleve.Apprendre et
Professeur.Apprendre...
Dans le cas particulier des Noms puisque c'etait ton exemple,
imagine que nous décidions de gérer les Noms avec un controle
d'orthographe
et de formattage :
il suffit de rajouter dans le Set Nom le controle garantissant
automatiquement
la transformation des Espaces CHR(20) en CHR(255) pour avoir un format non
déformable, etc....
Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
questions..
L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
ydx35[NO_SAPM]at_YahOOOOOO.fr
"Patrice Henrio" a écrit dans le
message de news:
Puisque nous en sommes aux questions théoriques, en voici une sur les
propriétés des objets ou classes.
Pourquoi faut-il les déclarer private et créer des procédures de lecture
etd'écriture ?
En effet, à priori je sais ce que je programme et il me semble plus
simple
décrire directement
objet.nom="Machin" ou if objet.condition then
sans que le programme fasse le détour par objet.setNom("Machin"), ou
objet.GetCondition.
Or dans les cours sur la POO (programmation orientée objet) on insiste
biensur le fait qu'il ne faut pas manipuler directement les propriétés. Je
repose ma question pourquoi ?
Je comprends si l'affectation doit faire plusieurs chose, par exemple en
plus de rentrer la propriété nom, renseigner la propriété longueur du
nom,
mais dans la plupart des cas nous avons
property get Nom()
Nom=m_Nom
end property
property set Nom(string Nom)
m_nom=Nom
end property
Bonjour Patrice,
Lisant -a temps perdu- de vieux messages,
(et apprenant avec bcp d'interet les "SOLUTIONS POUR LA FONCTION PUBLIQUE"
precedents,
je vais rapidement te donner une "excellente" raison pratique
pour /en objet/ TOUJORUS passer par des Methodes, et non l'accès direct
aux
données !
Tu sais que l'objectif /l'un des../ de l'objet, est de garantir
independance
entre
code interne et externe de l'objet, en d'autres terme entre utilisation
et implementation (la façon dont c'est rtaité au niveau binaire ou...).
Passer par ces "méthodes" (le nom courant en technologie objet) libère le
programmeur utilisateur
de toute contrainte a ce niveau : un exemple => je viens de voir que
Currency disparait avec VB.NET
Comment vai-je choisir de le re-intercaler ?
dans certains cas, la precision Simple suffira, dans d'autre DOUBLE ou
meme Integer !
- quelque soir le choix du programmeur de la classe qui va refaire
l'implementation,
apr exemple en utilisant une classe de "COMPLEX" (idée farfelue en
l'occurrence),
avec en particulier une partie réelle partielle, ton programme utilisateur
ne sera pas concerné
du moment que tu respectes strictement l'interface de programmation.
Autre solution :un exemple que j'ai tres souvent pris dans l'enseignement
:
imagine que tu doive coder "APPRENDRE" pour ton personnel !
en anglais aucun probleme, en tre TEACH et LEARN,
en francias, il faudra distinguer Eleve.Apprendre et
Professeur.Apprendre...
Dans le cas particulier des Noms puisque c'etait ton exemple,
imagine que nous décidions de gérer les Noms avec un controle
d'orthographe
et de formattage :
il suffit de rajouter dans le Set Nom le controle garantissant
automatiquement
la transformation des Espaces CHR(20) en CHR(255) pour avoir un format non
déformable, etc....
Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
questions..
L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
ydx35[NO_SAPM]at_YahOOOOOO.fr
Je suis d'accord pour la plupart des méthodes, type print, somme ou autre
mais pour l'accès aux propriétés, je ne comprends pas en quoi <Objet>.name
plutôt que d'une variable privée. de l'usage
"YannX" a écrit dans le message de news:
>
> "Patrice Henrio" a écrit dans le
> message de news:
>
>>
>> Puisque nous en sommes aux questions théoriques, en voici une sur les
>> propriétés des objets ou classes.
>> Pourquoi faut-il les déclarer private et créer des procédures de
> et
>> d'écriture ?
>> En effet, à priori je sais ce que je programme et il me semble plus
>> simple
>> décrire directement
>> objet.nom="Machin" ou if objet.condition then
>> sans que le programme fasse le détour par objet.setNom("Machin"), ou
>> objet.GetCondition.
>> Or dans les cours sur la POO (programmation orientée objet) on insiste
> bien
>> sur le fait qu'il ne faut pas manipuler directement les propriétés. Je
>> repose ma question pourquoi ?
>> Je comprends si l'affectation doit faire plusieurs chose, par exemple
>> plus de rentrer la propriété nom, renseigner la propriété longueur du
>> nom,
>> mais dans la plupart des cas nous avons
>>
>> property get Nom()
>> Nom=m_Nom
>> end property
>>
>> property set Nom(string Nom)
>> m_nom=Nom
>> end property
>>
> Bonjour Patrice,
>
> Lisant -a temps perdu- de vieux messages,
> (et apprenant avec bcp d'interet les "SOLUTIONS POUR LA FONCTION
> precedents,
> je vais rapidement te donner une "excellente" raison pratique
> pour /en objet/ TOUJORUS passer par des Methodes, et non l'accès direct
> aux
> données !
>
> Tu sais que l'objectif /l'un des../ de l'objet, est de garantir
> independance
> entre
> code interne et externe de l'objet, en d'autres terme entre utilisation
> et implementation (la façon dont c'est rtaité au niveau binaire ou...).
>
> Passer par ces "méthodes" (le nom courant en technologie objet) libère
> programmeur utilisateur
> de toute contrainte a ce niveau : un exemple => je viens de voir que
> Currency disparait avec VB.NET
> Comment vai-je choisir de le re-intercaler ?
> dans certains cas, la precision Simple suffira, dans d'autre DOUBLE ou
> meme Integer !
> - quelque soir le choix du programmeur de la classe qui va refaire
> l'implementation,
> apr exemple en utilisant une classe de "COMPLEX" (idée farfelue en
> l'occurrence),
> avec en particulier une partie réelle partielle, ton programme
> ne sera pas concerné
> du moment que tu respectes strictement l'interface de programmation.
>
> Autre solution :un exemple que j'ai tres souvent pris dans
> :
> imagine que tu doive coder "APPRENDRE" pour ton personnel !
> en anglais aucun probleme, en tre TEACH et LEARN,
> en francias, il faudra distinguer Eleve.Apprendre et
> Professeur.Apprendre...
>
> Dans le cas particulier des Noms puisque c'etait ton exemple,
> imagine que nous décidions de gérer les Noms avec un controle
> d'orthographe
> et de formattage :
> il suffit de rajouter dans le Set Nom le controle garantissant
> automatiquement
> la transformation des Espaces CHR(20) en CHR(255) pour avoir un format
> déformable, etc....
>
> Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
> questions..
> L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
>
> ydx35[NO_SAPM]at_YahOOOOOO.fr
>
>
>
Je suis d'accord pour la plupart des méthodes, type print, somme ou autre
mais pour l'accès aux propriétés, je ne comprends pas en quoi <Objet>.name
plutôt que d'une variable privée. de l'usage
"YannX" <ydx_nospam@yahoo.fr> a écrit dans le message de news:
eFrfKUotEHA.4040@TK2MSFTNGP09.phx.gbl...
>
> "Patrice Henrio" <patrice.henrio.pasdepub@laposte.net> a écrit dans le
> message de news:eED34v5hEHA.356@tk2msftngp13.phx.gbl...
>
>>
>> Puisque nous en sommes aux questions théoriques, en voici une sur les
>> propriétés des objets ou classes.
>> Pourquoi faut-il les déclarer private et créer des procédures de
> et
>> d'écriture ?
>> En effet, à priori je sais ce que je programme et il me semble plus
>> simple
>> décrire directement
>> objet.nom="Machin" ou if objet.condition then
>> sans que le programme fasse le détour par objet.setNom("Machin"), ou
>> objet.GetCondition.
>> Or dans les cours sur la POO (programmation orientée objet) on insiste
> bien
>> sur le fait qu'il ne faut pas manipuler directement les propriétés. Je
>> repose ma question pourquoi ?
>> Je comprends si l'affectation doit faire plusieurs chose, par exemple
>> plus de rentrer la propriété nom, renseigner la propriété longueur du
>> nom,
>> mais dans la plupart des cas nous avons
>>
>> property get Nom()
>> Nom=m_Nom
>> end property
>>
>> property set Nom(string Nom)
>> m_nom=Nom
>> end property
>>
> Bonjour Patrice,
>
> Lisant -a temps perdu- de vieux messages,
> (et apprenant avec bcp d'interet les "SOLUTIONS POUR LA FONCTION
> precedents,
> je vais rapidement te donner une "excellente" raison pratique
> pour /en objet/ TOUJORUS passer par des Methodes, et non l'accès direct
> aux
> données !
>
> Tu sais que l'objectif /l'un des../ de l'objet, est de garantir
> independance
> entre
> code interne et externe de l'objet, en d'autres terme entre utilisation
> et implementation (la façon dont c'est rtaité au niveau binaire ou...).
>
> Passer par ces "méthodes" (le nom courant en technologie objet) libère
> programmeur utilisateur
> de toute contrainte a ce niveau : un exemple => je viens de voir que
> Currency disparait avec VB.NET
> Comment vai-je choisir de le re-intercaler ?
> dans certains cas, la precision Simple suffira, dans d'autre DOUBLE ou
> meme Integer !
> - quelque soir le choix du programmeur de la classe qui va refaire
> l'implementation,
> apr exemple en utilisant une classe de "COMPLEX" (idée farfelue en
> l'occurrence),
> avec en particulier une partie réelle partielle, ton programme
> ne sera pas concerné
> du moment que tu respectes strictement l'interface de programmation.
>
> Autre solution :un exemple que j'ai tres souvent pris dans
> :
> imagine que tu doive coder "APPRENDRE" pour ton personnel !
> en anglais aucun probleme, en tre TEACH et LEARN,
> en francias, il faudra distinguer Eleve.Apprendre et
> Professeur.Apprendre...
>
> Dans le cas particulier des Noms puisque c'etait ton exemple,
> imagine que nous décidions de gérer les Noms avec un controle
> d'orthographe
> et de formattage :
> il suffit de rajouter dans le Set Nom le controle garantissant
> automatiquement
> la transformation des Espaces CHR(20) en CHR(255) pour avoir un format
> déformable, etc....
>
> Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
> questions..
> L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
>
> ydx35[NO_SAPM]at_YahOOOOOO.fr
>
>
>
Je suis d'accord pour la plupart des méthodes, type print, somme ou autre
mais pour l'accès aux propriétés, je ne comprends pas en quoi <Objet>.name
plutôt que d'une variable privée. de l'usage
"YannX" a écrit dans le message de news:
>
> "Patrice Henrio" a écrit dans le
> message de news:
>
>>
>> Puisque nous en sommes aux questions théoriques, en voici une sur les
>> propriétés des objets ou classes.
>> Pourquoi faut-il les déclarer private et créer des procédures de
> et
>> d'écriture ?
>> En effet, à priori je sais ce que je programme et il me semble plus
>> simple
>> décrire directement
>> objet.nom="Machin" ou if objet.condition then
>> sans que le programme fasse le détour par objet.setNom("Machin"), ou
>> objet.GetCondition.
>> Or dans les cours sur la POO (programmation orientée objet) on insiste
> bien
>> sur le fait qu'il ne faut pas manipuler directement les propriétés. Je
>> repose ma question pourquoi ?
>> Je comprends si l'affectation doit faire plusieurs chose, par exemple
>> plus de rentrer la propriété nom, renseigner la propriété longueur du
>> nom,
>> mais dans la plupart des cas nous avons
>>
>> property get Nom()
>> Nom=m_Nom
>> end property
>>
>> property set Nom(string Nom)
>> m_nom=Nom
>> end property
>>
> Bonjour Patrice,
>
> Lisant -a temps perdu- de vieux messages,
> (et apprenant avec bcp d'interet les "SOLUTIONS POUR LA FONCTION
> precedents,
> je vais rapidement te donner une "excellente" raison pratique
> pour /en objet/ TOUJORUS passer par des Methodes, et non l'accès direct
> aux
> données !
>
> Tu sais que l'objectif /l'un des../ de l'objet, est de garantir
> independance
> entre
> code interne et externe de l'objet, en d'autres terme entre utilisation
> et implementation (la façon dont c'est rtaité au niveau binaire ou...).
>
> Passer par ces "méthodes" (le nom courant en technologie objet) libère
> programmeur utilisateur
> de toute contrainte a ce niveau : un exemple => je viens de voir que
> Currency disparait avec VB.NET
> Comment vai-je choisir de le re-intercaler ?
> dans certains cas, la precision Simple suffira, dans d'autre DOUBLE ou
> meme Integer !
> - quelque soir le choix du programmeur de la classe qui va refaire
> l'implementation,
> apr exemple en utilisant une classe de "COMPLEX" (idée farfelue en
> l'occurrence),
> avec en particulier une partie réelle partielle, ton programme
> ne sera pas concerné
> du moment que tu respectes strictement l'interface de programmation.
>
> Autre solution :un exemple que j'ai tres souvent pris dans
> :
> imagine que tu doive coder "APPRENDRE" pour ton personnel !
> en anglais aucun probleme, en tre TEACH et LEARN,
> en francias, il faudra distinguer Eleve.Apprendre et
> Professeur.Apprendre...
>
> Dans le cas particulier des Noms puisque c'etait ton exemple,
> imagine que nous décidions de gérer les Noms avec un controle
> d'orthographe
> et de formattage :
> il suffit de rajouter dans le Set Nom le controle garantissant
> automatiquement
> la transformation des Espaces CHR(20) en CHR(255) pour avoir un format
> déformable, etc....
>
> Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
> questions..
> L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
>
> ydx35[NO_SAPM]at_YahOOOOOO.fr
>
>
>
"Patrice Henrio" a écrit dans le
message de news:
Puisque nous en sommes aux questions théoriques, en voici une sur les
propriétés des objets ou classes.
Pourquoi faut-il les déclarer private et créer des procédures de lecture
etd'écriture ?
En effet, à priori je sais ce que je programme et il me semble plus
simple
décrire directement
objet.nom="Machin" ou if objet.condition then
sans que le programme fasse le détour par objet.setNom("Machin"), ou
objet.GetCondition.
Or dans les cours sur la POO (programmation orientée objet) on insiste
biensur le fait qu'il ne faut pas manipuler directement les propriétés. Je
repose ma question pourquoi ?
Je comprends si l'affectation doit faire plusieurs chose, par exemple en
plus de rentrer la propriété nom, renseigner la propriété longueur du
nom,
mais dans la plupart des cas nous avons
property get Nom()
Nom=m_Nom
end property
property set Nom(string Nom)
m_nom=Nom
end property
Bonjour Patrice,
Lisant -a temps perdu- de vieux messages,
(et apprenant avec bcp d'interet les "SOLUTIONS POUR LA FONCTION PUBLIQUE"
precedents,
je vais rapidement te donner une "excellente" raison pratique
pour /en objet/ TOUJORUS passer par des Methodes, et non l'accès direct
aux
données !
Tu sais que l'objectif /l'un des../ de l'objet, est de garantir
independance
entre
code interne et externe de l'objet, en d'autres terme entre utilisation
et implementation (la façon dont c'est rtaité au niveau binaire ou...).
Passer par ces "méthodes" (le nom courant en technologie objet) libère le
programmeur utilisateur
de toute contrainte a ce niveau : un exemple => je viens de voir que
Currency disparait avec VB.NET
Comment vai-je choisir de le re-intercaler ?
dans certains cas, la precision Simple suffira, dans d'autre DOUBLE ou
meme Integer !
- quelque soir le choix du programmeur de la classe qui va refaire
l'implementation,
apr exemple en utilisant une classe de "COMPLEX" (idée farfelue en
l'occurrence),
avec en particulier une partie réelle partielle, ton programme utilisateur
ne sera pas concerné
du moment que tu respectes strictement l'interface de programmation.
Autre solution :un exemple que j'ai tres souvent pris dans l'enseignement
:
imagine que tu doive coder "APPRENDRE" pour ton personnel !
en anglais aucun probleme, en tre TEACH et LEARN,
en francias, il faudra distinguer Eleve.Apprendre et
Professeur.Apprendre...
Dans le cas particulier des Noms puisque c'etait ton exemple,
imagine que nous décidions de gérer les Noms avec un controle
d'orthographe
et de formattage :
il suffit de rajouter dans le Set Nom le controle garantissant
automatiquement
la transformation des Espaces CHR(20) en CHR(255) pour avoir un format non
déformable, etc....
Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
questions..
L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
ydx35[NO_SAPM]at_YahOOOOOO.fr
"Patrice Henrio" <patrice.henrio.pasdepub@laposte.net> a écrit dans le
message de news:eED34v5hEHA.356@tk2msftngp13.phx.gbl...
Puisque nous en sommes aux questions théoriques, en voici une sur les
propriétés des objets ou classes.
Pourquoi faut-il les déclarer private et créer des procédures de lecture
et
d'écriture ?
En effet, à priori je sais ce que je programme et il me semble plus
simple
décrire directement
objet.nom="Machin" ou if objet.condition then
sans que le programme fasse le détour par objet.setNom("Machin"), ou
objet.GetCondition.
Or dans les cours sur la POO (programmation orientée objet) on insiste
bien
sur le fait qu'il ne faut pas manipuler directement les propriétés. Je
repose ma question pourquoi ?
Je comprends si l'affectation doit faire plusieurs chose, par exemple en
plus de rentrer la propriété nom, renseigner la propriété longueur du
nom,
mais dans la plupart des cas nous avons
property get Nom()
Nom=m_Nom
end property
property set Nom(string Nom)
m_nom=Nom
end property
Bonjour Patrice,
Lisant -a temps perdu- de vieux messages,
(et apprenant avec bcp d'interet les "SOLUTIONS POUR LA FONCTION PUBLIQUE"
precedents,
je vais rapidement te donner une "excellente" raison pratique
pour /en objet/ TOUJORUS passer par des Methodes, et non l'accès direct
aux
données !
Tu sais que l'objectif /l'un des../ de l'objet, est de garantir
independance
entre
code interne et externe de l'objet, en d'autres terme entre utilisation
et implementation (la façon dont c'est rtaité au niveau binaire ou...).
Passer par ces "méthodes" (le nom courant en technologie objet) libère le
programmeur utilisateur
de toute contrainte a ce niveau : un exemple => je viens de voir que
Currency disparait avec VB.NET
Comment vai-je choisir de le re-intercaler ?
dans certains cas, la precision Simple suffira, dans d'autre DOUBLE ou
meme Integer !
- quelque soir le choix du programmeur de la classe qui va refaire
l'implementation,
apr exemple en utilisant une classe de "COMPLEX" (idée farfelue en
l'occurrence),
avec en particulier une partie réelle partielle, ton programme utilisateur
ne sera pas concerné
du moment que tu respectes strictement l'interface de programmation.
Autre solution :un exemple que j'ai tres souvent pris dans l'enseignement
:
imagine que tu doive coder "APPRENDRE" pour ton personnel !
en anglais aucun probleme, en tre TEACH et LEARN,
en francias, il faudra distinguer Eleve.Apprendre et
Professeur.Apprendre...
Dans le cas particulier des Noms puisque c'etait ton exemple,
imagine que nous décidions de gérer les Noms avec un controle
d'orthographe
et de formattage :
il suffit de rajouter dans le Set Nom le controle garantissant
automatiquement
la transformation des Espaces CHR(20) en CHR(255) pour avoir un format non
déformable, etc....
Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
questions..
L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
ydx35[NO_SAPM]at_YahOOOOOO.fr
"Patrice Henrio" a écrit dans le
message de news:
Puisque nous en sommes aux questions théoriques, en voici une sur les
propriétés des objets ou classes.
Pourquoi faut-il les déclarer private et créer des procédures de lecture
etd'écriture ?
En effet, à priori je sais ce que je programme et il me semble plus
simple
décrire directement
objet.nom="Machin" ou if objet.condition then
sans que le programme fasse le détour par objet.setNom("Machin"), ou
objet.GetCondition.
Or dans les cours sur la POO (programmation orientée objet) on insiste
biensur le fait qu'il ne faut pas manipuler directement les propriétés. Je
repose ma question pourquoi ?
Je comprends si l'affectation doit faire plusieurs chose, par exemple en
plus de rentrer la propriété nom, renseigner la propriété longueur du
nom,
mais dans la plupart des cas nous avons
property get Nom()
Nom=m_Nom
end property
property set Nom(string Nom)
m_nom=Nom
end property
Bonjour Patrice,
Lisant -a temps perdu- de vieux messages,
(et apprenant avec bcp d'interet les "SOLUTIONS POUR LA FONCTION PUBLIQUE"
precedents,
je vais rapidement te donner une "excellente" raison pratique
pour /en objet/ TOUJORUS passer par des Methodes, et non l'accès direct
aux
données !
Tu sais que l'objectif /l'un des../ de l'objet, est de garantir
independance
entre
code interne et externe de l'objet, en d'autres terme entre utilisation
et implementation (la façon dont c'est rtaité au niveau binaire ou...).
Passer par ces "méthodes" (le nom courant en technologie objet) libère le
programmeur utilisateur
de toute contrainte a ce niveau : un exemple => je viens de voir que
Currency disparait avec VB.NET
Comment vai-je choisir de le re-intercaler ?
dans certains cas, la precision Simple suffira, dans d'autre DOUBLE ou
meme Integer !
- quelque soir le choix du programmeur de la classe qui va refaire
l'implementation,
apr exemple en utilisant une classe de "COMPLEX" (idée farfelue en
l'occurrence),
avec en particulier une partie réelle partielle, ton programme utilisateur
ne sera pas concerné
du moment que tu respectes strictement l'interface de programmation.
Autre solution :un exemple que j'ai tres souvent pris dans l'enseignement
:
imagine que tu doive coder "APPRENDRE" pour ton personnel !
en anglais aucun probleme, en tre TEACH et LEARN,
en francias, il faudra distinguer Eleve.Apprendre et
Professeur.Apprendre...
Dans le cas particulier des Noms puisque c'etait ton exemple,
imagine que nous décidions de gérer les Noms avec un controle
d'orthographe
et de formattage :
il suffit de rajouter dans le Set Nom le controle garantissant
automatiquement
la transformation des Espaces CHR(20) en CHR(255) pour avoir un format non
déformable, etc....
Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
questions..
L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
ydx35[NO_SAPM]at_YahOOOOOO.fr
Je crois après plusieurs réflexion avoir enfin compris l'intérêt des
méthodes même dasn le cas d'un set qui se contente de recopier dans une
variable privée la valeur d'un paramètre.
Je pense que si on modifie certains aspects de la classe qui nécessite que
l'affectation d'une valeur soit modifiée, on n'a besoin de ne modifier que
la classe elle-même au lieu d'avoir à récupérer toutes les affectations
se trouvent dans le projet.
Je crois que c'est ce que tu voulais dire par indépendance du code.
Merci en tout cas de ces infos.
"YannX" a écrit dans le message de news:
>
> "Patrice Henrio" a écrit dans le
> message de news:
>
>>
>> Puisque nous en sommes aux questions théoriques, en voici une sur les
>> propriétés des objets ou classes.
>> Pourquoi faut-il les déclarer private et créer des procédures de
> et
>> d'écriture ?
>> En effet, à priori je sais ce que je programme et il me semble plus
>> simple
>> décrire directement
>> objet.nom="Machin" ou if objet.condition then
>> sans que le programme fasse le détour par objet.setNom("Machin"), ou
>> objet.GetCondition.
>> Or dans les cours sur la POO (programmation orientée objet) on insiste
> bien
>> sur le fait qu'il ne faut pas manipuler directement les propriétés. Je
>> repose ma question pourquoi ?
>> Je comprends si l'affectation doit faire plusieurs chose, par exemple
>> plus de rentrer la propriété nom, renseigner la propriété longueur du
>> nom,
>> mais dans la plupart des cas nous avons
>>
>> property get Nom()
>> Nom=m_Nom
>> end property
>>
>> property set Nom(string Nom)
>> m_nom=Nom
>> end property
>>
> Bonjour Patrice,
>
> Lisant -a temps perdu- de vieux messages,
> (et apprenant avec bcp d'interet les "SOLUTIONS POUR LA FONCTION
> precedents,
> je vais rapidement te donner une "excellente" raison pratique
> pour /en objet/ TOUJORUS passer par des Methodes, et non l'accès direct
> aux
> données !
>
> Tu sais que l'objectif /l'un des../ de l'objet, est de garantir
> independance
> entre
> code interne et externe de l'objet, en d'autres terme entre utilisation
> et implementation (la façon dont c'est rtaité au niveau binaire ou...).
>
> Passer par ces "méthodes" (le nom courant en technologie objet) libère
> programmeur utilisateur
> de toute contrainte a ce niveau : un exemple => je viens de voir que
> Currency disparait avec VB.NET
> Comment vai-je choisir de le re-intercaler ?
> dans certains cas, la precision Simple suffira, dans d'autre DOUBLE ou
> meme Integer !
> - quelque soir le choix du programmeur de la classe qui va refaire
> l'implementation,
> apr exemple en utilisant une classe de "COMPLEX" (idée farfelue en
> l'occurrence),
> avec en particulier une partie réelle partielle, ton programme
> ne sera pas concerné
> du moment que tu respectes strictement l'interface de programmation.
>
> Autre solution :un exemple que j'ai tres souvent pris dans
> :
> imagine que tu doive coder "APPRENDRE" pour ton personnel !
> en anglais aucun probleme, en tre TEACH et LEARN,
> en francias, il faudra distinguer Eleve.Apprendre et
> Professeur.Apprendre...
>
> Dans le cas particulier des Noms puisque c'etait ton exemple,
> imagine que nous décidions de gérer les Noms avec un controle
> d'orthographe
> et de formattage :
> il suffit de rajouter dans le Set Nom le controle garantissant
> automatiquement
> la transformation des Espaces CHR(20) en CHR(255) pour avoir un format
> déformable, etc....
>
> Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
> questions..
> L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
>
> ydx35[NO_SAPM]at_YahOOOOOO.fr
>
>
>
Je crois après plusieurs réflexion avoir enfin compris l'intérêt des
méthodes même dasn le cas d'un set qui se contente de recopier dans une
variable privée la valeur d'un paramètre.
Je pense que si on modifie certains aspects de la classe qui nécessite que
l'affectation d'une valeur soit modifiée, on n'a besoin de ne modifier que
la classe elle-même au lieu d'avoir à récupérer toutes les affectations
se trouvent dans le projet.
Je crois que c'est ce que tu voulais dire par indépendance du code.
Merci en tout cas de ces infos.
"YannX" <ydx_nospam@yahoo.fr> a écrit dans le message de news:
eFrfKUotEHA.4040@TK2MSFTNGP09.phx.gbl...
>
> "Patrice Henrio" <patrice.henrio.pasdepub@laposte.net> a écrit dans le
> message de news:eED34v5hEHA.356@tk2msftngp13.phx.gbl...
>
>>
>> Puisque nous en sommes aux questions théoriques, en voici une sur les
>> propriétés des objets ou classes.
>> Pourquoi faut-il les déclarer private et créer des procédures de
> et
>> d'écriture ?
>> En effet, à priori je sais ce que je programme et il me semble plus
>> simple
>> décrire directement
>> objet.nom="Machin" ou if objet.condition then
>> sans que le programme fasse le détour par objet.setNom("Machin"), ou
>> objet.GetCondition.
>> Or dans les cours sur la POO (programmation orientée objet) on insiste
> bien
>> sur le fait qu'il ne faut pas manipuler directement les propriétés. Je
>> repose ma question pourquoi ?
>> Je comprends si l'affectation doit faire plusieurs chose, par exemple
>> plus de rentrer la propriété nom, renseigner la propriété longueur du
>> nom,
>> mais dans la plupart des cas nous avons
>>
>> property get Nom()
>> Nom=m_Nom
>> end property
>>
>> property set Nom(string Nom)
>> m_nom=Nom
>> end property
>>
> Bonjour Patrice,
>
> Lisant -a temps perdu- de vieux messages,
> (et apprenant avec bcp d'interet les "SOLUTIONS POUR LA FONCTION
> precedents,
> je vais rapidement te donner une "excellente" raison pratique
> pour /en objet/ TOUJORUS passer par des Methodes, et non l'accès direct
> aux
> données !
>
> Tu sais que l'objectif /l'un des../ de l'objet, est de garantir
> independance
> entre
> code interne et externe de l'objet, en d'autres terme entre utilisation
> et implementation (la façon dont c'est rtaité au niveau binaire ou...).
>
> Passer par ces "méthodes" (le nom courant en technologie objet) libère
> programmeur utilisateur
> de toute contrainte a ce niveau : un exemple => je viens de voir que
> Currency disparait avec VB.NET
> Comment vai-je choisir de le re-intercaler ?
> dans certains cas, la precision Simple suffira, dans d'autre DOUBLE ou
> meme Integer !
> - quelque soir le choix du programmeur de la classe qui va refaire
> l'implementation,
> apr exemple en utilisant une classe de "COMPLEX" (idée farfelue en
> l'occurrence),
> avec en particulier une partie réelle partielle, ton programme
> ne sera pas concerné
> du moment que tu respectes strictement l'interface de programmation.
>
> Autre solution :un exemple que j'ai tres souvent pris dans
> :
> imagine que tu doive coder "APPRENDRE" pour ton personnel !
> en anglais aucun probleme, en tre TEACH et LEARN,
> en francias, il faudra distinguer Eleve.Apprendre et
> Professeur.Apprendre...
>
> Dans le cas particulier des Noms puisque c'etait ton exemple,
> imagine que nous décidions de gérer les Noms avec un controle
> d'orthographe
> et de formattage :
> il suffit de rajouter dans le Set Nom le controle garantissant
> automatiquement
> la transformation des Espaces CHR(20) en CHR(255) pour avoir un format
> déformable, etc....
>
> Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
> questions..
> L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
>
> ydx35[NO_SAPM]at_YahOOOOOO.fr
>
>
>
Je crois après plusieurs réflexion avoir enfin compris l'intérêt des
méthodes même dasn le cas d'un set qui se contente de recopier dans une
variable privée la valeur d'un paramètre.
Je pense que si on modifie certains aspects de la classe qui nécessite que
l'affectation d'une valeur soit modifiée, on n'a besoin de ne modifier que
la classe elle-même au lieu d'avoir à récupérer toutes les affectations
se trouvent dans le projet.
Je crois que c'est ce que tu voulais dire par indépendance du code.
Merci en tout cas de ces infos.
"YannX" a écrit dans le message de news:
>
> "Patrice Henrio" a écrit dans le
> message de news:
>
>>
>> Puisque nous en sommes aux questions théoriques, en voici une sur les
>> propriétés des objets ou classes.
>> Pourquoi faut-il les déclarer private et créer des procédures de
> et
>> d'écriture ?
>> En effet, à priori je sais ce que je programme et il me semble plus
>> simple
>> décrire directement
>> objet.nom="Machin" ou if objet.condition then
>> sans que le programme fasse le détour par objet.setNom("Machin"), ou
>> objet.GetCondition.
>> Or dans les cours sur la POO (programmation orientée objet) on insiste
> bien
>> sur le fait qu'il ne faut pas manipuler directement les propriétés. Je
>> repose ma question pourquoi ?
>> Je comprends si l'affectation doit faire plusieurs chose, par exemple
>> plus de rentrer la propriété nom, renseigner la propriété longueur du
>> nom,
>> mais dans la plupart des cas nous avons
>>
>> property get Nom()
>> Nom=m_Nom
>> end property
>>
>> property set Nom(string Nom)
>> m_nom=Nom
>> end property
>>
> Bonjour Patrice,
>
> Lisant -a temps perdu- de vieux messages,
> (et apprenant avec bcp d'interet les "SOLUTIONS POUR LA FONCTION
> precedents,
> je vais rapidement te donner une "excellente" raison pratique
> pour /en objet/ TOUJORUS passer par des Methodes, et non l'accès direct
> aux
> données !
>
> Tu sais que l'objectif /l'un des../ de l'objet, est de garantir
> independance
> entre
> code interne et externe de l'objet, en d'autres terme entre utilisation
> et implementation (la façon dont c'est rtaité au niveau binaire ou...).
>
> Passer par ces "méthodes" (le nom courant en technologie objet) libère
> programmeur utilisateur
> de toute contrainte a ce niveau : un exemple => je viens de voir que
> Currency disparait avec VB.NET
> Comment vai-je choisir de le re-intercaler ?
> dans certains cas, la precision Simple suffira, dans d'autre DOUBLE ou
> meme Integer !
> - quelque soir le choix du programmeur de la classe qui va refaire
> l'implementation,
> apr exemple en utilisant une classe de "COMPLEX" (idée farfelue en
> l'occurrence),
> avec en particulier une partie réelle partielle, ton programme
> ne sera pas concerné
> du moment que tu respectes strictement l'interface de programmation.
>
> Autre solution :un exemple que j'ai tres souvent pris dans
> :
> imagine que tu doive coder "APPRENDRE" pour ton personnel !
> en anglais aucun probleme, en tre TEACH et LEARN,
> en francias, il faudra distinguer Eleve.Apprendre et
> Professeur.Apprendre...
>
> Dans le cas particulier des Noms puisque c'etait ton exemple,
> imagine que nous décidions de gérer les Noms avec un controle
> d'orthographe
> et de formattage :
> il suffit de rajouter dans le Set Nom le controle garantissant
> automatiquement
> la transformation des Espaces CHR(20) en CHR(255) pour avoir un format
> déformable, etc....
>
> Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
> questions..
> L'objet, c'est un peu mon dada, depuis 87, et malgré VB !
>
> ydx35[NO_SAPM]at_YahOOOOOO.fr
>
>
>