J'aimerai savoir quelle est le meilleur procédé, c'est à dire fiable et
évolutif, pour configurer un objet avec un certain nombre de parametres,
sachant que ces parametres doivent être validés et modifiés, utilisés
pour configurer d'autres propriétés privées et stockés durant
l'utilisation du script et que la valeur validée et modifiée de certain
d'entre eux doit pouvoir être lue :
1. en lui envoyant un tableau
$parametres = array (
'truc' => 54,
'machin' => false,
'chose' => 'my name is Raphael'
);
superbeObjet->set($parametres);
2. en utilisant une méthode set pour chaque parametre :
superbeObjet->setTruc(54);
superbeObjet->setMachin(false);
superbeObjet->setChose('my name is Raphael');
3. en utilisant une méthode set unique avec le nom et la valeur du
parametre :
superbeObjet->set('truc', 54);
superbeObjet->set('machin', false);
superbeObjet->set('chose', 'my name is Raphael');
--
Raphaël
http://www.r-wils.com
« Don't mean a thing if you ain't got that swing ! »
Ni _chars, ni _len (ni même _set_chars) ne sont masqués. Il y a pourtant encapsulation. Tu me diras que l'utilisateur de la classe peut tout casser en accédant directement à _char ou _len. C'est vrai. Mais c'est son problème.
Là je ne suis pas d'accord avec toi.
C'est ton problème !-)
Je pense que c'est le problème de la classe de faire en sorte de rester intègre. En C++,
avec l'utilisation de pointeurs, c'est le segmentation fault assuré, et donc une classe qui fait tout planter à tout bout de champs car n'effectuant pas les verifs necessaires, elle propage ses propres problèmes d'intégrité.
En C++, oui. Là, on parlait PHP et accessoirement Python. Qui sont des langages très différents de C++, du fait de la gestion manuelle de la mémoire.
BTW, accéder à des attributs privés en C++ est on ne peut plus simple, il suffit d'un #define pour ça. Je connais peu de développeurs C++ qui utilisent cette possibilité, et quand ils le font, c'est généralement avec de bonnes raisons et en pleine connaissance de cause. Bref, dans la pratique, je ne vois pas où est la différence fondamentale. Tant que la bibliothèque/le module/la classe est utilisé normalement (-> via l'API officielle), tout va bien. Si le programmeur commence à faire joujou avec les détails d'implémentation, c'est *son* problème. Mais je ne vois pas de raison de l'en empêcher.
Et dans le cas de classes derivées? si la classe de base ne gère pas correctement ses variables qui sont private, quand est-il pour les classes dérivées: le bordel.
Si la classe de base ne fait pas correctement son travail, c'est le bordel de toutes façons. Mais il est notoire que les langages à typage statique donnent naissance à des hiérarchies d'héritage bien plus profondes et bien plus complexes que les langages à typage dynamique (ou ceux à inférence de type). Bref, ce qui est supposé résoudre - ou du moins limiter - certains problèmes en génère d'autres.
Mon expérience (certes limitée) est que le "bordel" vient le plus souvent des complexités (AMHA) inutiles introduites au nom de la "sûreté" (typage statique[1], modificateurs d'accès etc).
[1] dont le but premier est de donner des indices au compilo pour des optimisations possibles, pas de garantir la correction du code...
Sachant que le ratio LOC/bug est à peu près constant, moins il faut de lignes de code pour exprimer quelque chose, moins il y a de risques de bugs. Donc, éradiquons sans complexes tout ce qui relève de la complexité arbitraire et tout ce qui rend un langage inutilement verbeux !-)
De plus, et pour en revenir à du PHP, si la modif d'une variable de classe necessite un update en BD par exemple, une mauvaise utilisation (qui ne fait d'erreur) de la classe peux aussi mettre en l'air la BD.
Oui, tout à fait. Que veux tu que je te dise ? Si tu prend ton gros marteau de chantier et que tu te tape très fort sur la tête avec, tu va bien évidemment te faire très mal. Faut-il pour autant interdire les gros marteaux de chantier ? Ou obliger tout le monde à vivre en permanence avec un casque de chantier sur la tête, dès fois que ?
Si un programmeur est assez stupide pour ne pas lire la doc des bibliothèques/modules/classes/etc qu'il utilise, s'il est assez stupide pour ne pas respecter les règles du langage - que ces règles soient formelles ou non -, tant pis pour lui. Après, tu peux rendre le langage aussi psycho-rigide que possible, il ne sera *jamais* à l'épreuve de la stupidité. Regarde ADA, et regarde ce qui est arrivé à Ariane.
Cela fait bientôt quinze ans que Python se base sur des conventions pour distinguer l'API de l'implémentation, et ça ne semble pas poser de problème. Cela fait bientôt quinze ans que Python se base sur des conventions pour distinguer une variable d'une (pseudo) constante symbolique, et ça semble fonctionner très bien aussi.
AMHA, dans leur grande majorité, les programmeurs ne sont pas masochistes au point de se mettre des coups de marteau sur la tête.
C'est pour çà que j'aime bien __get et __set car ils permettent d'utiliser la classe comme si de rien n'était tout en pouvant mettre du code derrière pour agir en conséquence. Et cela evite d'avoir une ribembelle de get_truc(),get_machin(), set_truc($truc), set_machin($machin).
Là dessus, je suis tout à fait d'accord. Je suis pour l'encapsulation. Je suis pour les attributs calculés. Je suis pour tout ce qui rend le langage aussi expressif que possible. Et je suis contre les limitations arbitraires qui ne font que rendre les choses plus compliquées qu'elles ne le devrait.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
clifden wrote:
Ni _chars, ni _len (ni même _set_chars) ne sont masqués. Il y a pourtant
encapsulation. Tu me diras que l'utilisateur de la classe peut tout
casser en accédant directement à _char ou _len. C'est vrai. Mais c'est
son problème.
Là je ne suis pas d'accord avec toi.
C'est ton problème !-)
Je pense que c'est le problème de la classe de faire en sorte de rester
intègre. En C++,
avec l'utilisation de pointeurs, c'est le segmentation
fault assuré, et donc une classe qui fait tout planter à tout bout de
champs car n'effectuant pas les verifs necessaires, elle propage ses
propres problèmes d'intégrité.
En C++, oui. Là, on parlait PHP et accessoirement Python. Qui sont des
langages très différents de C++, du fait de la gestion manuelle de la
mémoire.
BTW, accéder à des attributs privés en C++ est on ne peut plus simple,
il suffit d'un #define pour ça. Je connais peu de développeurs C++ qui
utilisent cette possibilité, et quand ils le font, c'est généralement
avec de bonnes raisons et en pleine connaissance de cause. Bref, dans la
pratique, je ne vois pas où est la différence fondamentale. Tant que la
bibliothèque/le module/la classe est utilisé normalement (-> via l'API
officielle), tout va bien. Si le programmeur commence à faire joujou
avec les détails d'implémentation, c'est *son* problème. Mais je ne vois
pas de raison de l'en empêcher.
Et dans le cas de classes derivées? si la classe de base ne gère pas
correctement ses variables qui sont private, quand est-il pour les
classes dérivées: le bordel.
Si la classe de base ne fait pas correctement son travail, c'est le
bordel de toutes façons. Mais il est notoire que les langages à typage
statique donnent naissance à des hiérarchies d'héritage bien plus
profondes et bien plus complexes que les langages à typage dynamique (ou
ceux à inférence de type). Bref, ce qui est supposé résoudre - ou du
moins limiter - certains problèmes en génère d'autres.
Mon expérience (certes limitée) est que le "bordel" vient le plus
souvent des complexités (AMHA) inutiles introduites au nom de la
"sûreté" (typage statique[1], modificateurs d'accès etc).
[1] dont le but premier est de donner des indices au compilo pour des
optimisations possibles, pas de garantir la correction du code...
Sachant que le ratio LOC/bug est à peu près constant, moins il faut de
lignes de code pour exprimer quelque chose, moins il y a de risques de
bugs. Donc, éradiquons sans complexes tout ce qui relève de la
complexité arbitraire et tout ce qui rend un langage inutilement verbeux !-)
De plus, et pour en revenir à du PHP, si la modif d'une variable de
classe necessite un update en BD par exemple, une mauvaise utilisation
(qui ne fait d'erreur) de la classe peux aussi mettre en l'air la BD.
Oui, tout à fait. Que veux tu que je te dise ? Si tu prend ton gros
marteau de chantier et que tu te tape très fort sur la tête avec, tu va
bien évidemment te faire très mal. Faut-il pour autant interdire les
gros marteaux de chantier ? Ou obliger tout le monde à vivre en
permanence avec un casque de chantier sur la tête, dès fois que ?
Si un programmeur est assez stupide pour ne pas lire la doc des
bibliothèques/modules/classes/etc qu'il utilise, s'il est assez stupide
pour ne pas respecter les règles du langage - que ces règles soient
formelles ou non -, tant pis pour lui. Après, tu peux rendre le langage
aussi psycho-rigide que possible, il ne sera *jamais* à l'épreuve de la
stupidité. Regarde ADA, et regarde ce qui est arrivé à Ariane.
Cela fait bientôt quinze ans que Python se base sur des conventions pour
distinguer l'API de l'implémentation, et ça ne semble pas poser de
problème. Cela fait bientôt quinze ans que Python se base sur des
conventions pour distinguer une variable d'une (pseudo) constante
symbolique, et ça semble fonctionner très bien aussi.
AMHA, dans leur grande majorité, les programmeurs ne sont pas
masochistes au point de se mettre des coups de marteau sur la tête.
C'est pour çà que j'aime bien __get et __set car ils permettent
d'utiliser la classe comme si de rien n'était tout en pouvant mettre du
code derrière pour agir en conséquence. Et cela evite d'avoir une
ribembelle de get_truc(),get_machin(), set_truc($truc),
set_machin($machin).
Là dessus, je suis tout à fait d'accord. Je suis pour l'encapsulation.
Je suis pour les attributs calculés. Je suis pour tout ce qui rend le
langage aussi expressif que possible. Et je suis contre les limitations
arbitraires qui ne font que rendre les choses plus compliquées qu'elles
ne le devrait.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Ni _chars, ni _len (ni même _set_chars) ne sont masqués. Il y a pourtant encapsulation. Tu me diras que l'utilisateur de la classe peut tout casser en accédant directement à _char ou _len. C'est vrai. Mais c'est son problème.
Là je ne suis pas d'accord avec toi.
C'est ton problème !-)
Je pense que c'est le problème de la classe de faire en sorte de rester intègre. En C++,
avec l'utilisation de pointeurs, c'est le segmentation fault assuré, et donc une classe qui fait tout planter à tout bout de champs car n'effectuant pas les verifs necessaires, elle propage ses propres problèmes d'intégrité.
En C++, oui. Là, on parlait PHP et accessoirement Python. Qui sont des langages très différents de C++, du fait de la gestion manuelle de la mémoire.
BTW, accéder à des attributs privés en C++ est on ne peut plus simple, il suffit d'un #define pour ça. Je connais peu de développeurs C++ qui utilisent cette possibilité, et quand ils le font, c'est généralement avec de bonnes raisons et en pleine connaissance de cause. Bref, dans la pratique, je ne vois pas où est la différence fondamentale. Tant que la bibliothèque/le module/la classe est utilisé normalement (-> via l'API officielle), tout va bien. Si le programmeur commence à faire joujou avec les détails d'implémentation, c'est *son* problème. Mais je ne vois pas de raison de l'en empêcher.
Et dans le cas de classes derivées? si la classe de base ne gère pas correctement ses variables qui sont private, quand est-il pour les classes dérivées: le bordel.
Si la classe de base ne fait pas correctement son travail, c'est le bordel de toutes façons. Mais il est notoire que les langages à typage statique donnent naissance à des hiérarchies d'héritage bien plus profondes et bien plus complexes que les langages à typage dynamique (ou ceux à inférence de type). Bref, ce qui est supposé résoudre - ou du moins limiter - certains problèmes en génère d'autres.
Mon expérience (certes limitée) est que le "bordel" vient le plus souvent des complexités (AMHA) inutiles introduites au nom de la "sûreté" (typage statique[1], modificateurs d'accès etc).
[1] dont le but premier est de donner des indices au compilo pour des optimisations possibles, pas de garantir la correction du code...
Sachant que le ratio LOC/bug est à peu près constant, moins il faut de lignes de code pour exprimer quelque chose, moins il y a de risques de bugs. Donc, éradiquons sans complexes tout ce qui relève de la complexité arbitraire et tout ce qui rend un langage inutilement verbeux !-)
De plus, et pour en revenir à du PHP, si la modif d'une variable de classe necessite un update en BD par exemple, une mauvaise utilisation (qui ne fait d'erreur) de la classe peux aussi mettre en l'air la BD.
Oui, tout à fait. Que veux tu que je te dise ? Si tu prend ton gros marteau de chantier et que tu te tape très fort sur la tête avec, tu va bien évidemment te faire très mal. Faut-il pour autant interdire les gros marteaux de chantier ? Ou obliger tout le monde à vivre en permanence avec un casque de chantier sur la tête, dès fois que ?
Si un programmeur est assez stupide pour ne pas lire la doc des bibliothèques/modules/classes/etc qu'il utilise, s'il est assez stupide pour ne pas respecter les règles du langage - que ces règles soient formelles ou non -, tant pis pour lui. Après, tu peux rendre le langage aussi psycho-rigide que possible, il ne sera *jamais* à l'épreuve de la stupidité. Regarde ADA, et regarde ce qui est arrivé à Ariane.
Cela fait bientôt quinze ans que Python se base sur des conventions pour distinguer l'API de l'implémentation, et ça ne semble pas poser de problème. Cela fait bientôt quinze ans que Python se base sur des conventions pour distinguer une variable d'une (pseudo) constante symbolique, et ça semble fonctionner très bien aussi.
AMHA, dans leur grande majorité, les programmeurs ne sont pas masochistes au point de se mettre des coups de marteau sur la tête.
C'est pour çà que j'aime bien __get et __set car ils permettent d'utiliser la classe comme si de rien n'était tout en pouvant mettre du code derrière pour agir en conséquence. Et cela evite d'avoir une ribembelle de get_truc(),get_machin(), set_truc($truc), set_machin($machin).
Là dessus, je suis tout à fait d'accord. Je suis pour l'encapsulation. Je suis pour les attributs calculés. Je suis pour tout ce qui rend le langage aussi expressif que possible. Et je suis contre les limitations arbitraires qui ne font que rendre les choses plus compliquées qu'elles ne le devrait.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Marc
Là dessus, je suis tout à fait d'accord. Je suis pour l'encapsulation. Je suis pour les attributs calculés. Je suis pour tout ce qui rend le langage aussi expressif que possible. Et je suis contre les limitations arbitraires qui ne font que rendre les choses plus compliquées qu'elles ne le devrait.
j'aime bien ces echanges de point de vue. Y'a différentes ecoles qui essaient de faire partager point-de-vue et souvent expériences.
allez continuez ;-)
Bruno, je suis avec toi de tout coeur ;-)
Là dessus, je suis tout à fait d'accord. Je suis pour l'encapsulation.
Je suis pour les attributs calculés. Je suis pour tout ce qui rend le
langage aussi expressif que possible. Et je suis contre les limitations
arbitraires qui ne font que rendre les choses plus compliquées qu'elles
ne le devrait.
j'aime bien ces echanges de point de vue. Y'a différentes ecoles
qui essaient de faire partager point-de-vue et souvent expériences.
Là dessus, je suis tout à fait d'accord. Je suis pour l'encapsulation. Je suis pour les attributs calculés. Je suis pour tout ce qui rend le langage aussi expressif que possible. Et je suis contre les limitations arbitraires qui ne font que rendre les choses plus compliquées qu'elles ne le devrait.
j'aime bien ces echanges de point de vue. Y'a différentes ecoles qui essaient de faire partager point-de-vue et souvent expériences.
