Discussion :

[koala01]

Je ne vois pas pourquoi un setPosition modifierait la taille de l'objet.

Je ne vois pas pourquoi elle ne le ferait pas

Si elle s'en tient à ce que l'on pense (définir une nouvelle valeur pour le coin qui correspond à sont point de départ), on n'a strictement aucune indication de ce qu'elle peut faire de son "coin opposé"

Si elle le modifie aussi, elle ment sur ce qu'elle fait car elle en fait plus que ce qu'elle ne dit.

Mais si elle ne le modifie pas, il faudrait trouver un nom qui indique le changement de l'état de l'objet, non

Pas nécessairement, il peut faire un setEnabled(true) sur un objet déjà activé.

tu peux faire un enabled sur un objet déjà activé aussi, ou serait le problème

Le code correspondant avec enable() et disable() serat proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
bool b;
while(1)
{
    if(b == true) // allez if (b)
        obj.enable();
    else
       obj.disable();
    b!=b;
}

on perd peut etre quatre lignes de code, mais on gagne en lisibilité (sans perdre en performances )

Mais dans ce cas là pour changer la taille, la font (Times new Roman, ...) on pourrait utiliser des "set" (?)

je n'ai pas réfléchi à ce point particulier Mais il devrait etre possible de trouver des noms cohérents, tu ne crois pas

Est-il vraiment censé faire que ça? La définition de "set" ne dit que c'est un "changement vers un état défini" ce qui peut impliquer d'autres opérations. Ne serait-ce pas plutôt parce qu'on pense (à tord) qu'il serait censé faire que cela ?

Qu'on le pense à tord ou à raison ne change rien...

Le problème est qu'on puisse le penser

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Le problème c'est que si un jour, <span style="font-family: monospace; padding: 2px; background: #ddd; display: inline-block">changeSize<span style="color: black;">(</span><span style="color: black;">)</span></span> devient répandu, on sera confronté au même problème qu'avec <span style="font-family: monospace; padding: 2px; background: #ddd; display: inline-block">setSize<span style="color: black;">(</span><span style="color: black;">)</span></span>, des personnes penseront qu'elle ne peut faire qu'une seule chose et n'iront pas voir la documentation.

C'est bien pour cela que j'ai parlé de resize et que j'ai bien indiqué (avec un peu de retard, je te l'accorde) que les arguments devraient etre une différence de taille et non la nouvelle taille (d'autant plus que l'auto-complétion après laquelle tu sembles pleurer donne généralement ne nom des arguments à passer )

Dès lors ne peut-on pas considérer le fait de ne pas aller voir la doc quelque soit la fonction/méthode comme une erreur aussi grave que de faire un cast_const à tout va ?

C'est sans doute aussi grave, mais on le répète assez ce RTFM, et ca n'ennuie que celui qui ne l'aura pas fait (alors que le const cast a des répercussions au niveau du code et des sécurités que l'on tente de mettre en place )

Nous ne serions alors pas responsable des erreurs que ferait un programmeur qui ne lirait pas la doc comme nous ne sommes pas responsable si un utilisateur s'amuse avec cast_const ?

Si ce n'est qu'il est beaucoup plus facile de faire quelque chose de résistant à quelqu'un qui n'a pas (ou mal) lu la doc qu'à quelqu'un qui décide d'utiliser const cast

Car c'est bien d'essayer de faire un code le plus intuitif et le plus "idiot-proof" mais en C++, dès qu'on veut faire une bêtise, rien ne peut nous en empêcher.
Par exemple rien ne m'empêche de récupérer l'adresse d'un objet stocké dans un container et de faire un delete dessus.

Nous sommes d'accord

Si quelqu'un veut se tirer dans le pied, il aura toujours moyen de le faire, meme si tu met le fusil sous clé

Mais, est-ce une raison pour le laisser faire des bêtises manifestes

[Neckara]

Je ne te suis vraiment pas sur ce coup là.

Si resize prend en paramètre une taille relative à l'ancienne taille on se retrouve avec le même problème que si resize prend en paramètre une taille absolue lorsqu'on souhaite redimensionner l'objet avec une taille absolue.

Exemple : je veux passer d'une taille "personnalisée" à une taille de 50x50
Ce qui est un besoin différent de : je veux réduire ma taille de 50 sur la largeur.

[koala01]

Je ne te suis vraiment pas sur ce coup là.

Si resize prend en paramètre une taille relative à l'ancienne taille on se retrouve avec le même problème que si resize prend en paramètre une taille absolue lorsqu'on souhaite redimensionner l'objet avec une taille absolue.

Exemple : je veux passer d'une taille "personnalisée" à une taille de 50x50
Ce qui est un besoin différent de : je veux réduire ma taille de 50 sur la largeur.

Peut etre faudra-t-il rajouter d'autres comportements, et envisager resizeAbsolute et resizeRelative.

Mais que ton souhait de pouvoir définir une taille absolue ne te cache pas le fait que devra aussi parfois "simplement rajouter XX" à la taille pour pouvoir rajouter un élément

Je m'explique:

Imaginons que tu aies une boite de dialogue composée de labels et de lineEdits.

tu veux qu'à chaque fois que l'utilisateur commence à écrire dans un (le dernier) lineEdit, il s'en rajoute automatiquement un, et, bien sur, que ta boite de dialogue s'agrandisse en conséquence.

Le problème est que la boite de dialogue ne pourra s'agrandir que dans certaines limites, que l'objet a au début "une taille suffisante", et que tu n'as "strictement rien à foutre" de la taille réel de l'objet: tout ce qui t'importe c'est "qu'elle reste de taille suffisante".

Si tu n'offres que la possibilité de faire un resize en fournissant des tailles absolues, tu n'as strictement aucun intérêt à passer de setSize à resize (quoi que resize pourrait déjà vérifier les contraintes de taille, chose que setSize ne pourrait pas faire).

Mais si tu remplace setSize par resizeAbsolute et resizeRelative, tu gagnes énormément en souplesse...

En outre, la taille de ton objet sera, théoriquement, définie une première fois à la création de celui-ci, à une valeur "arbitraire" clairement définie.

Qu'est ce qui t'empêcherait de te baser sur cette valeur pour déterminer les changements de taille, voire, pour imposer une taille absolue, de partir sur l'idée de prendre les tailles actuelles

Bon, tu me diras que l'on inverse alors simplement le problème

Mais c'est la raison pour laquelle je plaide pour remplacer les setXXX par "autant de comportements clairement définis que nécessaires", quitte à en donner deux qui soient "finalement très semblables"

[Neckara]

Je comprend, faire un setRelativeSize() serait très ambigüe.

Mais dans le cas d'un setState(State s), est-ce que l'utilisateur voit vraiment une différence avec changeState(State s) ou modifyState(State s) voir même ????State1() (pas d'inspiration désolé ) ?
Est-ce que ces différents noms de méthodes ne font pas pour lui exactement la même chose ?

[koala01]

Le fait est que, lorsque tu agis sur un état, tu passe "simplement" à l'état suivant...

Cet état peut éventuellement être déterminé en fonction de la transition que tu applique à l'objet.

Le nom de a fonction serait donc sans doute proche de nextState, mais, de manière générale, tu ne devrais pas l'appeler depuis l'extérieur de ton objet: l'utilisateur ne devrait pouvoir accéder qu'aux transitions (qui s'occuperaient elles de définir ce qu'est "l'état suivant" )

[EDIT]Et s'il faut vraiment donner la possibilité de définir un état particulier, je te conseillerais de fournir une fonction qui indique clairement l'état recherché, et donc "autant de fonctions que d'états dans lesquels tu veux pouvoir mettre ton objet".

A charge pour ces fonctions de s'assurer que le nouvel état soit cohérent avec l'état précédent
[EDIT 2]Toi qui sembles aimer les fonctions "toXXX", que penserais tu de toStateMachinChose en cas d'absolue nécessité

[Neckara]

Le problème c'est que si on veut se passer du "set", il faut tout de même réussir à trouver un voir le meilleur nom.

C'est loin d'être simple mais je suppose qu'il doit y avoir quelques astuces.
Il faudrait rechercher s'il n'existe pas des "cours de nommage de méthodes" sur internet

EDIT :

Toi qui sembles aimer les fonctions "toXXX", que penserais tu de toStateMachinChose en cas d'absolue nécessité

J'utilise plutôt to pour "convertir" les données de l'instance mais oui c'est une très bonne idée

[germinolegrand]

Faire une fonction resize(offset) c'est juste suicidaire parce qu'on fait une signification différente de la norme (si si, regardez la STL...). C'est la garantie que la fonction sera mal utilisée .

extend, expand, enlarge, ... je sais bien que le vocabulaire anglais est plus limité que le français, mais bon en fonction du contexte y'a quand même du choix pour agrandir avec un offset...

[koala01]

EDIT : J'utilise plutôt to pour "convertir" les données de l'instance mais oui c'est une très bonne idée

... ou passToMachinChose

Mais, de toutes manières, le but de la machine à états est, théoriquement, de faire en sorte que l'état lui indique ce qu'elle peut ou ne peut pas faire, que l'utilisateur n'aie vraiment à s'inquiéter de l'état dans lequel se trouve la machine.

Il peut décider de mettre en place une logique qui se base sur l'état actuel de la machine pour savoir quelle action entreprendre, mais, en théorie, la machine vérifiera quand même si l'action peut etre entreprise selon l'état courent

Et, quoi qu'il en soit, l'état courent de la machine ne sera modifié que par les transitions, qui devront savoir exactement à quel état elles mènent lorsqu'elles sont entreprises au départ d'un état particulier

Tu ne devrais donc pas exposer de manière publique de fonction, autres que les transitions s'entend, permettant de modifier l'état de la machine

[koala01]

Faire une fonction resize(offset) c'est juste suicidaire parce qu'on fait une signification différente de la norme (si si, regardez la STL...). C'est la garantie que la fonction sera mal utilisée .

extend, expand, enlarge, ... je sais bien que le vocabulaire anglais est plus limité que le français, mais bon en fonction du contexte y'a quand même du choix pour agrandir avec un offset...

En fait, ici, on parlait, surtout, d'un objet de type widget, qui a une taille d'affichage, non d'un conteneur dont il faudrait redéfinir le nombre d'éléments qu'il peut contenir.

Le contexte est donc, de toutes manières, tout autre

Maintenant, je t'accorde le fait que, comme nous risquons d'avoir des widgets qui agissent comme des conteneurs, il est peut etre intéressant de assurer une certaine cohérence vis à vis de la SL.

Mais ce n'est ici qu'un détail, étant donné que l'on parle, de toutes manières, que d'un point de vue tout à fait théorique dans le sens où ma thèse est surtout que "tout vaut mieux qu'un setXXX" (ce qui est le vrai sens du débat )

[germinolegrand]

Y'a des fois (et ça arrive plus souvent dans un système de GUI qu'ailleurs !) où set est vraiment le verbe approprié. setText(newText) à part changeText() y'a pas de nom plus approprié.

[white_tentacle]

Les objets GUI sont un peu bâtards.

Ils ont pleins de propriétés publiques simple, pas de vrais comportements autre que celui de s’afficher, et doivent pouvoir s’adapter à plein de besoins différents. Et il faut rajouter à ça les problèmes de performance (par exemple, les fontes) qui tordent un peu les interfaces.

Du coup, ces contraintes font que ce n’est pas un modèle à appliquer ailleurs (là où on n’a pas les contraintes). L’idée c’est plutôt :
- on essaie de s’approcher du mieux possible du modèle
- on le tord là où on en a besoin.

Enfin, les mutateurs sont supers pour la gui pour la génération automatique d’outils de design (cf qtdesigner).

Tout ceci pour dire que l’argument « les bibliothèques GUI l’utilisent » est à mettre en relation avec les raisons qui font qu’elles l’utilisent, et qu’il ne faut surtout pas l’utiliser pour transposer ça tel quel aux objets plus « métier ».

[koala01]

Y'a des fois (et ça arrive plus souvent dans un système de GUI qu'ailleurs !) où set est vraiment le verbe approprié. setText(newText) à part changeText() y'a pas de nom plus approprié.

Je trouve quelque part que changeText serait sommes toutes pas plus mal

Les objets GUI sont un peu bâtards.

Ils ont pleins de propriétés publiques simple, pas de vrais comportements autre que celui de s’afficher, et doivent pouvoir s’adapter à plein de besoins différents. Et il faut rajouter à ça les problèmes de performance (par exemple, les fontes) qui tordent un peu les interfaces.

Du coup, ces contraintes font que ce n’est pas un modèle à appliquer ailleurs (là où on n’a pas les contraintes). L’idée c’est plutôt :
- on essaie de s’approcher du mieux possible du modèle
- on le tord là où on en a besoin.

Mais je suis intimement convaincu qu'il y aurait tout à fait moyen d'éviter de tordre le modèle y compris pour une GUI

Enfin, les mutateurs sont supers pour la gui pour la génération automatique d’outils de design (cf qtdesigner).

Beaucoup de widget doivent, effectivement présenter une interface commune, mais est ce pour autant qu'il faut obligatoirement que les accesseurs commencent par get et les mutateur par set

Je suis loin d'en être persuadé, même s'il s'agit de mettre en place un système cmme QtDesigner...

Après tout, dés le moment où tu as une interface identique pour les propriétés similaires et la possibilité de sérialiser des différents objets, il ne te faut pas grand chose de plus, hormis le système de rendu

Tout ceci pour dire que l’argument « les bibliothèques GUI l’utilisent » est à mettre en relation avec les raisons qui font qu’elles l’utilisent, et qu’il ne faut surtout pas l’utiliser pour transposer ça tel quel aux objets plus « métier ».

Ca, par contre, je suis tout à fait d'accord

[oodini]

Je trouve quelque part que changeText serait sommes toutes pas plus mal

Sauf qu'il se peut très bien que la nouvelle valeur soit identique à l'ancienne.
Et dans ce cas, ta fonction ment.

[white_tentacle]

Sauf qu'il se peut très bien que la nouvelle valeur soit identique à l'ancienne.
Et dans ce cas, ta fonction ment.

Le fond du problème, pour moi, c’est la dissymétrie get/set.

S’il y a symétrie, get/set est probablement une mauvaise encapsulation, mais pas sûr qu’il y ait mieux.

S’il y a dissymétrie, là, c’est très mal .

[oodini]

Tu bloques, comme cela t'arrive régulièrement, sur un détail et tu laisses encore une fois l'arbre cacher la forêt.

Et toi, tu as tendance à raser la forêt un peu trop facilement.

Pour répondre à ce qui suit, je vais utiliser l'exemple que j'avais donné : une portion de route avec une longueur donnée, et une vitesse statistique susceptible d'être changée une fois par mois par un set, alors que le get a lieu plusieurs dizaines de fois par jour.

Cela oblige l'utilisateur à connaitre un type utilisé par l'objet sur lequel il agit, contrevenant à la loi demeter

Non. Je redonne une nouvelle vitesse statistique en km/h, en me conformant pour cela à l'interface de la fonction. La vitesse peut être sauvegardée en m/s ou en verges/heures, peu me chaut.

Cela donne à l'utilisateur de l'objet qui expose cette fonction des responsabilité qu'il ne devrait pas avoir (calculer la valeur à initialiser, vérifier que cette valeur soit cohérente,...)

La classe en question a pour rôle de modéliser une portion de route et toutes ses caractéristiques. On peut considérer que la vitesse statistique constatée sur cette portion de route fait partie de ses caractéristiques.
Qui d'autre aurait la responsabilité de détenir cette caractéristique, et de s'assurer de sa validité ?

Afin de pouvoir fournir une valeur correcte, l'utilisateur devra très régulièrement récupérer la "valeur d'origine"

Non.

du (2) découle le fait que la logique se trouve (sans doute) dupliquée à différents endroits, ce qui, en cas de correction ne tardera pas à provoquer des incohérences (le chemin A occasionnant un résultat différent du chemin B)

Argument probabiliste, et donc sans vocation à être généraliste.

Si la fonction fait plus que simplement initialiser la valeur, le nom de la fonction "ment" à l'utilisateur de l'objet quant ce qui est effectivement effectué

Primo, nous avons là affaire à un paralogisme in dictione.
Secundo, une fonction fait toujours plus que ce suggère son nom.

Quand tu donnes des directives à un codeur pour coder une classe, lui précises-tu à chaque fois de l'ajouter au projet Visual ou au makefile, de la tester, de la rajouter sur SVN/Git ?

"set" donne une impression "d'instantanéité" qui n'est pas *forcément* juste

Je ne sais ce qui te donne cette impression. Je te renvoie à un dictionnaire anglais.
Ce n'est pas parce que c'est court à écrire que c'est court à exécuter.

les mutateurs correspondent régulièrement à un ensemble de comportements plus restreints mais inversés (setEnabled(bool) qui correspond aussi bien à enable qu'à disable ou setFont qui va modifier aussi bien la police de caractères que sa taille, son état "gras","souligné", "italique", etc )

Tu n'arriveras pas à disqualifier une méthode en l'illustrant par des exemples de mauvaise utilisation flagrante.
Cela serait comme proscrire l'utilisation des voitures parce que certains ont des accidents.

Le fait de remplacer le mutateur par d'autres comportements corrige tous ces problèmes

Le fait est qu'il y a de bonnes et mauvaises utilisations.

[Neckara]

Le fond du problème, pour moi, c’est la dissymétrie get/set.

S’il y a symétrie, get/set est probablement une mauvaise encapsulation, mais pas sûr qu’il y ait mieux.

S’il y a dissymétrie, là, c’est très mal .

Qu'entends-tu pas dissymétrie ?
Qu'il y ai un set mais pas de get ou inversement ?
Ou alors que le set et le get n'effectuent pas des "actions symétriques" ie si get divise ce qu'il reçoit par deux alors set multiplie ce qu'il retourne par deux ?

[white_tentacle]

Qu'entends-tu pas dissymétrie ?
Qu'il y ai un set mais pas de get ou inversement ?
Ou alors que le set et le get n'effectuent pas des "actions symétriques" ie si get divise ce qu'il reçoit par deux alors set multiplie ce qu'il retourne par deux ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
objet.setValue("toto");
assert(objet.getValue() == "toto");

C’est ça que j’entends pas symétrie.

[koala01]

Et toi, tu as tendance à raser la forêt un peu trop facilement.

Non, j'applique des principes simples et éprouvés avant de penser à la ligne de code qui traduira ce que je veux exprimer

Il n'y en a que six auxquels je tiens, mais j'y tiens absolument.

Ce sont les cinq SOLID et la loi demeter (qui permet sommes toutes de respecter une bonne partie de SOLID)

Non. Je redonne une nouvelle vitesse statistique en km/h, en me conformant pour cela à l'interface de la fonction. La vitesse peut être sauvegardée en m/s ou en verges/heures, peu me chaut.

Mais cela t'oblige à connaitre la classe qui représente le tronçon (avec toute l'interface qu'il comporte) pour pouvoir changer la vitesse (ou le temps de parcours).

Si tu sépares correctement la responsabilité de maintenir les différentes vitesses (ou temps de parcours) de celle de représenter un tronçon de route, tu n'as absolument plus besoin de disposer de toute l'interface de ton tronçon pour aller modifier cette information: tu as mis un temps Xou Y pour effectuer un trajet, ou tu as roulé à une vitesse moyenne de A ou B pour ce faire, le reste n'a aucune espèce d'importance.

Tu arrives donc à garder des petits objets simples et autonome beaucoup plus facilement

La classe en question a pour rôle de modéliser une portion de route et toutes ses caractéristiques. On peut considérer que la vitesse statistique constatée sur cette portion de route fait partie de ses caractéristiques.
Qui d'autre aurait la responsabilité de détenir cette caractéristique, et de s'assurer de sa validité ?

Une classe à créer, qui met en relation un tronçon (son identifiant unique) et les différentes vitesses constatées (ou temps de parcours), tout simplement

Argument probabiliste, et donc sans vocation à être généraliste.

Très certainement probabiliste, mais constaté à de nombreuses reprises

Et je peux t'assurer que quand tu est confronté à ce problème, ca devient vite casse pied

Primo, nous avons là affaire à un paralogisme in dictione.
Secundo, une fonction fait toujours plus que ce suggère son nom.

Elle ne devrait pas

Quand tu donnes des directives à un codeur pour coder une classe, lui précises-tu à chaque fois de l'ajouter au projet Visual ou au makefile, de la tester, de la rajouter sur SVN/Git ?

Ne compares pas quelqu'un qui a (ou du moins qui est censé avoir) une réflexion propre avec une fonction en développement s'il te plait...

De manière générale, toute application, tout type de donnée, toute fonction n'auras jamais que la logique et l'intelligence que l'on aura pu / su / voulu lui donner, et c'est le rôle du développeur de donner cette logique et cette intelligence.

La "chose intelligente", a priori, c'est sensé (!!! ) être le développeur, pas ce qu'il développe, n'inversons pas les rôles

Je ne sais ce qui te donne cette impression. Je te renvoie à un dictionnaire anglais.
Ce n'est pas parce que c'est court à écrire que c'est court à exécuter.

Je ne dis pas que c'est court à écrire et donc court à exécuter.

Je dis que l'on a tellement l'habitude de voir setXXX sous la forme de m_XXX = newValue; que l'on va partir de l'a priori selon lequel c'est immédiat.

Le fait de choisir un terme plus en rapport avec le résultat obtenu (le fait de déplacer un widget par exemple, vu que c'est l'exemple qu'on a utilisé pas mal de fois, ou d'en modifier la taille) ne présente pas ce genre d'a priori

Tu n'arriveras pas à disqualifier une méthode en l'illustrant par des exemples de mauvaise utilisation flagrante.
Cela serait comme proscrire l'utilisation des voitures parce que certains ont des accidents.

Le problème, c'est que, quel que soit le mutateur que je choisirai, ce sera un exemple flagrant de mauvaise utilisation qui pourrait très bien être remplacer par un (ou plusieurs) comportements autrement plus clairs et explicites

Le fait est qu'il y a de bonnes et mauvaises utilisations.

S'agissant des mutateur, il n'y a que des mauvaises utilisations...

C'est, du moins, mon avis perso. Si tu tiens à me prouver que je me trompes, n'hésites pas à m'en proposer qui te semblent corrects, et j'en discuterai avec plaisir

[germinolegrand]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
objet.setValue("toto");
assert(objet.getValue() == "toto");

Ça c'est typiquement le genre de code que j'évite totalement car je le suppose possiblement faux.

[white_tentacle]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
objet.setValue("toto");
assert(objet.getValue() == "toto");

Ça c'est typiquement le genre de code que j'évite totalement car je le suppose possiblement faux.

Le fait qu’il soit faux est, pour moi… faux . Du moins, c’est une rupture de contrat. J’attends d’un couple get/set qu’il ait ce comportement. Si ce n’est pas le cas, il y a violation du contrat implicite.

C’est un peu comme si j’appelais length() une fonction sur une chaîne de caractère qui me renvoie, non pas la longueur (nombre de caractère), mais la taille en pixel à l’écran nécessaire pour l’afficher. Ah, oui, c’est une longueur aussi, mais ce n’est clairement pas celle que j’attends.