Quand j'ai commencé le c++, dans mon bô livre, ils conseillaient de
n'utiliser que des fonctions accesseurs/mutateurs pour intervenir sur
les variables membres.
Bon, dans certains cas, je suis bien d'accord, car si on change
l'implémentation, cela peut éviter de tout recoder.
Quand j'ai commencé le c++, dans mon bô livre, ils conseillaient de n'utiliser que des fonctions accesseurs/mutateurs pour intervenir sur les variables membres. Bon, dans certains cas, je suis bien d'accord, car si on change l'implémentation, cela peut éviter de tout recoder. Mais de manière générale, est-ce bien utile?
Avis perso : si ce n'est pour pouvoir faire plus facilement du multithread et du controle d'acces par la suite. S'il y a Get et Set pour un membre, alors il n'y a pas grand interet (si ce membre est simple).
Si il y a pleins de verification a faire pour ce qu'on passe ca peut se justifier...
Donc ma reponse serait : ca depend ! Si tu as un entier a lire/ecrire sans aucun controle dessus, je vois pas l'interet...
Doms.
BOnjour,
Quand j'ai commencé le c++, dans mon bô livre, ils conseillaient de
n'utiliser que des fonctions accesseurs/mutateurs pour intervenir sur
les variables membres.
Bon, dans certains cas, je suis bien d'accord, car si on change
l'implémentation, cela peut éviter de tout recoder.
Mais de manière générale, est-ce bien utile?
Avis perso : si ce n'est pour pouvoir faire plus facilement
du multithread et du controle d'acces par la suite. S'il y a Get
et Set pour un membre, alors il n'y a pas grand interet (si
ce membre est simple).
Si il y a pleins de verification a faire pour ce qu'on passe
ca peut se justifier...
Donc ma reponse serait : ca depend ! Si tu as un entier
a lire/ecrire sans aucun controle dessus, je vois pas l'interet...
Quand j'ai commencé le c++, dans mon bô livre, ils conseillaient de n'utiliser que des fonctions accesseurs/mutateurs pour intervenir sur les variables membres. Bon, dans certains cas, je suis bien d'accord, car si on change l'implémentation, cela peut éviter de tout recoder. Mais de manière générale, est-ce bien utile?
Avis perso : si ce n'est pour pouvoir faire plus facilement du multithread et du controle d'acces par la suite. S'il y a Get et Set pour un membre, alors il n'y a pas grand interet (si ce membre est simple).
Si il y a pleins de verification a faire pour ce qu'on passe ca peut se justifier...
Donc ma reponse serait : ca depend ! Si tu as un entier a lire/ecrire sans aucun controle dessus, je vois pas l'interet...
Doms.
JM
Si il y a pleins de verification a faire pour ce qu'on passe ca peut se justifier...
Donc ma reponse serait : ca depend ! Si tu as un entier a lire/ecrire sans aucun controle dessus, je vois pas l'interet...
Merci, c'était un peu ce à quoi je pensais
Si il y a pleins de verification a faire pour ce qu'on passe
ca peut se justifier...
Donc ma reponse serait : ca depend ! Si tu as un entier
a lire/ecrire sans aucun controle dessus, je vois pas l'interet...
Si il y a pleins de verification a faire pour ce qu'on passe ca peut se justifier...
Donc ma reponse serait : ca depend ! Si tu as un entier a lire/ecrire sans aucun controle dessus, je vois pas l'interet...
Merci, c'était un peu ce à quoi je pensais
Sylvain
JM wrote on 25/09/2006 18:15:
Mais en pratique?
peut être justement cette pratique !
l'utilisation du code lui même dicte souvent les règles pertinentes qui le gouvernent.
si c'est une classe légère, relativement figée (n'ayant aucune raison de changer fortement) et dont vous êtes le quasi seul utilisateur, utilisez les données membre directement.
si par contre vous mettez cette classe à dispo d'autres développeurs tout en ayant la responsabilité de son bon fonctionnement dans le temps, si certains choix sont susceptibles d'être modifiés (pour enrichir ou modifier l'algorithmie), alors définissez plutôt une interface d'accès.
et en pratique mixez un peu les deux car aucun code n'a strictement les mêmes exigences qu'un autre.
Sylvain.
JM wrote on 25/09/2006 18:15:
Mais en pratique?
peut être justement cette pratique !
l'utilisation du code lui même dicte souvent les règles pertinentes qui
le gouvernent.
si c'est une classe légère, relativement figée (n'ayant aucune raison de
changer fortement) et dont vous êtes le quasi seul utilisateur, utilisez
les données membre directement.
si par contre vous mettez cette classe à dispo d'autres développeurs
tout en ayant la responsabilité de son bon fonctionnement dans le temps,
si certains choix sont susceptibles d'être modifiés (pour enrichir ou
modifier l'algorithmie), alors définissez plutôt une interface d'accès.
et en pratique mixez un peu les deux car aucun code n'a strictement les
mêmes exigences qu'un autre.
l'utilisation du code lui même dicte souvent les règles pertinentes qui le gouvernent.
si c'est une classe légère, relativement figée (n'ayant aucune raison de changer fortement) et dont vous êtes le quasi seul utilisateur, utilisez les données membre directement.
si par contre vous mettez cette classe à dispo d'autres développeurs tout en ayant la responsabilité de son bon fonctionnement dans le temps, si certains choix sont susceptibles d'être modifiés (pour enrichir ou modifier l'algorithmie), alors définissez plutôt une interface d'accès.
et en pratique mixez un peu les deux car aucun code n'a strictement les mêmes exigences qu'un autre.
Sylvain.
kanze
JM wrote:
Quand j'ai commencé le c++, dans mon bô livre, ils conseillaient de n'utiliser que des fonctions accesseurs/mutateurs pour intervenir sur les variables membres.
Bon, dans certains cas, je suis bien d'accord, car si on change l'implémentation, cela peut éviter de tout recoder.
Mais de manière générale, est-ce bien utile?
P't-êt' ben. Ça dépend de la contexte.
J'utilise très peu des fonctions accesseurs/mutateurs à l'intérieur de l'implémentation (dans des fonctions membres) ; seulement quand il s'agit vraiment de s'assurer la modification de plusieurs éléments en parallel, pour les garder synchronisés (mais alors, il n'y a que mutateur, et il mute tous ces éléments dans la même fonction), ou quand je veux une initialisation paresseuse, ou quelque chose du genre.
Dans l'interface publique, en revanche : si la classe n'est qu'une collection de données, sans comportement particulier, je rends les données (toutes) publiques -- c'est une struct à la C, avec éventuellement des constructeurs ou des fonctions de commodité, mais l'interface de base, c'est bien celle d'une struct. Sinon -- et c'est le cas de loin le plus fréquent -- toutes les données sont privées. Si le client a accès à un champ, je fournis les accesseurs qu'il faut. Mais dans l'ensemble, ce n'est pas si fréquent que ça -- quand je vois une classe avec des accesseurs et des mutateur pour chaque donnée membre, je me pose la question pourquoi. Qu'est-ce qu'on encapsule, dans ce cas-là ? Quel est le comportement ? Si l'interface consiste réelement en juste une collection de données, les accesseurs et les mutateurs apportent en fait pas grand chose. On a une struct à la C, et je ne vois pas la raison de la maquiller en autre chose. Et si toutes les classes sont comme ça, je me pose la question si l'auteur a compris l'orientation objet ou non (ou si l'orientation objet convient à l'application particulière).
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
JM wrote:
Quand j'ai commencé le c++, dans mon bô livre, ils
conseillaient de n'utiliser que des fonctions
accesseurs/mutateurs pour intervenir sur les variables
membres.
Bon, dans certains cas, je suis bien d'accord, car si on change
l'implémentation, cela peut éviter de tout recoder.
Mais de manière générale, est-ce bien utile?
P't-êt' ben. Ça dépend de la contexte.
J'utilise très peu des fonctions accesseurs/mutateurs à
l'intérieur de l'implémentation (dans des fonctions membres) ;
seulement quand il s'agit vraiment de s'assurer la modification
de plusieurs éléments en parallel, pour les garder synchronisés
(mais alors, il n'y a que mutateur, et il mute tous ces éléments
dans la même fonction), ou quand je veux une initialisation
paresseuse, ou quelque chose du genre.
Dans l'interface publique, en revanche : si la classe n'est
qu'une collection de données, sans comportement particulier, je
rends les données (toutes) publiques -- c'est une struct à la
C, avec éventuellement des constructeurs ou des fonctions de
commodité, mais l'interface de base, c'est bien celle d'une
struct. Sinon -- et c'est le cas de loin le plus fréquent --
toutes les données sont privées. Si le client a accès à un
champ, je fournis les accesseurs qu'il faut. Mais dans
l'ensemble, ce n'est pas si fréquent que ça -- quand je vois
une classe avec des accesseurs et des mutateur pour chaque
donnée membre, je me pose la question pourquoi. Qu'est-ce qu'on
encapsule, dans ce cas-là ? Quel est le comportement ? Si
l'interface consiste réelement en juste une collection de
données, les accesseurs et les mutateurs apportent en fait pas
grand chose. On a une struct à la C, et je ne vois pas la raison
de la maquiller en autre chose. Et si toutes les classes sont
comme ça, je me pose la question si l'auteur a compris
l'orientation objet ou non (ou si l'orientation objet convient à
l'application particulière).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Quand j'ai commencé le c++, dans mon bô livre, ils conseillaient de n'utiliser que des fonctions accesseurs/mutateurs pour intervenir sur les variables membres.
Bon, dans certains cas, je suis bien d'accord, car si on change l'implémentation, cela peut éviter de tout recoder.
Mais de manière générale, est-ce bien utile?
P't-êt' ben. Ça dépend de la contexte.
J'utilise très peu des fonctions accesseurs/mutateurs à l'intérieur de l'implémentation (dans des fonctions membres) ; seulement quand il s'agit vraiment de s'assurer la modification de plusieurs éléments en parallel, pour les garder synchronisés (mais alors, il n'y a que mutateur, et il mute tous ces éléments dans la même fonction), ou quand je veux une initialisation paresseuse, ou quelque chose du genre.
Dans l'interface publique, en revanche : si la classe n'est qu'une collection de données, sans comportement particulier, je rends les données (toutes) publiques -- c'est une struct à la C, avec éventuellement des constructeurs ou des fonctions de commodité, mais l'interface de base, c'est bien celle d'une struct. Sinon -- et c'est le cas de loin le plus fréquent -- toutes les données sont privées. Si le client a accès à un champ, je fournis les accesseurs qu'il faut. Mais dans l'ensemble, ce n'est pas si fréquent que ça -- quand je vois une classe avec des accesseurs et des mutateur pour chaque donnée membre, je me pose la question pourquoi. Qu'est-ce qu'on encapsule, dans ce cas-là ? Quel est le comportement ? Si l'interface consiste réelement en juste une collection de données, les accesseurs et les mutateurs apportent en fait pas grand chose. On a une struct à la C, et je ne vois pas la raison de la maquiller en autre chose. Et si toutes les classes sont comme ça, je me pose la question si l'auteur a compris l'orientation objet ou non (ou si l'orientation objet convient à l'application particulière).
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Dominique Vaufreydaz wrote:
Quand j'ai commencé le c++, dans mon bô livre, ils conseillaient de n'utiliser que des fonctions accesseurs/mutateurs pour intervenir sur les variables membres. Bon, dans certains cas, je suis bien d'accord, car si on change l'implémentation, cela peut éviter de tout recoder. Mais de manière générale, est-ce bien utile?
Avis perso : si ce n'est pour pouvoir faire plus facilement du multithread et du controle d'acces par la suite. S'il y a Get et Set pour un membre, alors il n'y a pas grand interet (si ce membre est simple).
Tout à fait d'accord, mais...
Si l'interface se mappe à un ensemble de get et de set sur des variables membres, est-ce qu'on ne serait pas en train de faire du C, maquillé. Si je régarde mon propre code, les getter et les setter sont assez rares -- quand j'ai besoin d'une struct à la C, je me sers d'une struct à la C, et sinon (la plupart du temps), la classe présente un comportement, et non une collection d'éléments, à l'utilisateur.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Dominique Vaufreydaz wrote:
Quand j'ai commencé le c++, dans mon bô livre, ils conseillaient de
n'utiliser que des fonctions accesseurs/mutateurs pour intervenir sur
les variables membres.
Bon, dans certains cas, je suis bien d'accord, car si on change
l'implémentation, cela peut éviter de tout recoder.
Mais de manière générale, est-ce bien utile?
Avis perso : si ce n'est pour pouvoir faire plus facilement
du multithread et du controle d'acces par la suite. S'il y a Get
et Set pour un membre, alors il n'y a pas grand interet (si
ce membre est simple).
Tout à fait d'accord, mais...
Si l'interface se mappe à un ensemble de get et de set sur des
variables membres, est-ce qu'on ne serait pas en train de faire
du C, maquillé. Si je régarde mon propre code, les getter et les
setter sont assez rares -- quand j'ai besoin d'une struct à la
C, je me sers d'une struct à la C, et sinon (la plupart du
temps), la classe présente un comportement, et non une
collection d'éléments, à l'utilisateur.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Quand j'ai commencé le c++, dans mon bô livre, ils conseillaient de n'utiliser que des fonctions accesseurs/mutateurs pour intervenir sur les variables membres. Bon, dans certains cas, je suis bien d'accord, car si on change l'implémentation, cela peut éviter de tout recoder. Mais de manière générale, est-ce bien utile?
Avis perso : si ce n'est pour pouvoir faire plus facilement du multithread et du controle d'acces par la suite. S'il y a Get et Set pour un membre, alors il n'y a pas grand interet (si ce membre est simple).
Tout à fait d'accord, mais...
Si l'interface se mappe à un ensemble de get et de set sur des variables membres, est-ce qu'on ne serait pas en train de faire du C, maquillé. Si je régarde mon propre code, les getter et les setter sont assez rares -- quand j'ai besoin d'une struct à la C, je me sers d'une struct à la C, et sinon (la plupart du temps), la classe présente un comportement, et non une collection d'éléments, à l'utilisateur.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Alain Gaillard
variables membres, est-ce qu'on ne serait pas en train de faire du C, maquillé.
A moins que ça ne soit du vrai Java ;-)
-- Alain
variables membres, est-ce qu'on ne serait pas en train de faire
du C, maquillé.
