Discussion :

[Mat007]

Salut,

Des fois c'est pratique mais souvent, quand on n'a que des classes avec 3 données membres et 5 méthodes, faut pas exagérer quand même, 'oublier' de tester un pointeur a peu de chance d'arriver...
Compliquer le code (un visiteur sur un Boost.Variant ça complique un poil) pour une garantie de cet ordre bien souvent je ne considère pas vraiment que ça vaut le coup.

Je sais que c'est un peu hors sujet, mais je n'ai pas encore trouvé d'explication suffisament convaincante de cette affaire liée aux pointeurs NULL (comme quoi, avoir à en gérer serait un code smell...). Est-ce que quelqu'un maitrise bien le sujet ?

Peut-être parce qu'on peut sans doute toujours remanier pour soit séparer en deux classes (une avec une référence et l'autre sans rien du tout), soit utiliser un Null Object, soit un Composite, etc.. ?

MAT.

[Emmanuel Deloget]

Peut-être parce qu'on peut sans doute toujours remanier pour soit séparer en deux classes (une avec une référence et l'autre sans rien du tout), soit utiliser un Null Object, soit un Composite, etc.. ?

MAT.

Je ne vois pas de problème pour imaginer des solutions (y compris l'utilisation du pattern Null Object) mais pour être franc, je ne vois pas ce que ça apporte à une implémentation.

J'ai regardé depuis hier si je trouvais quelque chose sur le sujet caché au coeur de l'intraweb, et je n'ai trouvé que des discussions confuses. Je vais regarder dans les bouquins qu'on a u boulot si j'y vois quelque chose.

En gros, la seule chose que j'ai retenu de ce que j'ai lu jusqu'à présent, c'est que l'utilisation d'un pointeur qui peut être NULL entraîne
1) l'implémentation de cas particuliers.
2) de fortes duplications de code.
Le Refactoring de Fowler introduit une courte discussion à propos de ces deux problèmes, dans la partie consacrée au refactoring "introduce null object". Il cite Ron Jeffries:

We first started using the null object pattern when Rich Garzaniti found that lots of code in the system would check objects for presence before sending a message to the object. We might ask an object for its person, then ask the result whether it was null. If the object was present, we would ask it for its rate. We were doing this in several places, and the resulting duplicate code was getting annoying.

So we implemented a missing-person object that answered a zero rate
(we call our null objects missing objects). Soon missing person knew a
lot of methods, such as rate. Now we have more than 80 null-object
classes.

Personnellement, j'ai déjà travaillé sur des projets ou le nombre d'objets pouvant être null était énorme, et même si je conçois que le pattern null object aurait pu être un pattern relativement interessant dans ce cadre, je ne vois toujours pas en quoi le problème est sévère (peut être qu'il ne l'est pas en fait; Fowler et Beck (Refactoring...) ne cite pas de bad smell concernant ce point. Je ne pense pas que ça soit une ommission, car ils introduisent quand même ce refactoring particulier.
Pour continuer avec la description de Jeffries:

Our most common use of null objects is in the display of information. When we display, for example, a person, the object may or may not have any of perhaps 20 instance variables. If these were allowed to be null, the printing of a person would be very complex. Instead we plug in various null objects, all of which know how to display themselves in an orderly way. This got rid of huge amounts of procedural code.

Soit. Je pense que d'autres approches étaient disponibles (comme par exemple encapsuler le code d'affichage de l'information dans plusieurs objets, capable de traiter des pointeurs NULL).

J'ai vaguement regardé dans le Meyer, mais je n'ai pas trouvé grand chose sur le sujet. Il y a encore quelques livres ici que je dois regarder avant d'avoir une vision plus claire du problème, donc si entre temps vous avez des idées sur la question, n'hésitez pas !

[Mat007]

(...) je ne vois toujours pas en quoi le problème est sévère (...)

Si en effet un accesseur renvoie un pointeur, qui donc peut être nul, ça veut dire que tous les utilisateurs vont devoir tester le pointeur avant de l'utiliser, d'où duplication de code et risque tout de suite beaucoup plus élevé d'oublier de tester (c'est exactement ce que décrit Jeffries).

En fait je viens de réaliser (je n'utilise jamais d'accesseurs) que le problème ne se pose pas tellement lorsqu'un pointeur est encapsulé et reste un détail d'implémentation, mais plus à partir du moment où il est se promène à l'extérieur.
Du coup le fait de devoir beaucoup tester des pointeurs révélerait des problèmes d'encapsulation, ou de sur-utilisation d'accesseurs ?

MAT.

[Mat007]

Dans "Refactoring to Patterns" le problème est listé dans les différentes formes que peut prendre le code smell "Conditional Complexity" :

Dealing with null cases often leads to the creation of conditional logic. If the same null conditional logic is duplicated throughout your system, you can clean it up by using Introduce Null Object.

Et globalement "Conditional Complexity" est introduit par :

Conditional logic is innocent in its infancy, when it is simple to understand and contained within a few lines of code. Unfortunately, it rarely ages well. For example, you implement several new features ans suddenly you conditional logic becomes complicated and expansive.

Il y a un peu plus de contenu dans la description du remaniement "Introduce Null Object" mais globalement ça tourne toujours autour de la même chose...

MAT.

[wiztricks]

Si en effet un accesseur renvoie un pointeur, qui donc peut être nul, ça veut dire que tous les utilisateurs vont devoir tester le pointeur avant de l'utiliser, d'où duplication de code et risque tout de suite beaucoup plus élevé d'oublier de tester (c'est exactement ce que décrit Jeffries).

Grosso modo si on a un objet qui implémente null object, on peut remplacer

Code :

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

1
2
3
objet <- assignation
si (objet != NULL)
   // faire qqc.

par :

Code :

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

1
2
objet <- assignation
// faire qqc.

Une des implications est, qu'à chaque fois, il faudra tester le comportement du code dans le cas "null" et le cas "non null". (Bien sûr, on peut aussi "oublier" de faire le test dans le code et de tester l'oubli...)

Implémenter un nul object dans ce cas, permet de réduire les "cas" possibles... et donc la complexité à un coût plus que raisonnable.

En fait je viens de réaliser (je n'utilise jamais d'accesseurs) que le problème ne se pose pas tellement lorsqu'un pointeur est encapsulé et reste un détail d'implémentation, mais plus à partir du moment où il est se promène à l'extérieur.
Du coup le fait de devoir beaucoup tester des pointeurs révélerait des problèmes d'encapsulation, ou de sur-utilisation d'accesseurs ?
MAT.

Je pencherais plutôt pour une question d'interface.
La classe X définit l'accesseur A qui retourne

• un objet ou nul
• un objet (qui pourra être un null object).

Le client ne pourra peut être pas utiliser le null object comme un object normal dans tous les cas (quoique) mais on essaie bien de limiter les variations dans le code client pour traiter les différents cas.
- W

[loufoque]

Mais plus le fait de devoir appliquer un visiteur, devoir écrire une classe et la faire hériter de boost::static_visitor<>, et tout le tralala qui va avec quoi.

Hériter de static_visitor ça sert juste à définir le typedef result_type.
En fait, le problème c'est qu'il faut faire des fonctions. Avec un DSEL pour expression lambda, ça s'écrit plus concisement.

Et les histoires de faux objet vide, ça c'est vraiment un hack.

[yan]

boost::optional<T>, j'aime pas trop, la valeur est ajoutée est pas énorme, dans le sens où le typage ne te force pas à vérifier si l'objet est nul ou non.

Alors qu'à l'inverse boost::variant<T, null_type> ou le type Option de ML t'oblige à vérifier si l'objet est valide.

si je comprend bien,boost::optional<T> c'est grosso modo comme tester un pointeur.
boost::variant<T, null_type>, faut tester. ou est la différence??

En tout cas, je pense comprendre mieux le problème que vous pose d'avoir un pointeur NULL, si j'ai bien compris, il faut mieux avoir un objet qui ne fait rien et correspond au null, que d'avoir ce pointeur où l'on peut oublier un teste. C'est bien cela?

[wiztricks]

En tout cas, je pense comprendre mieux le problème que vous pose d'avoir un pointeur NULL, on si j'ai bien compris, il faut mieux avoir un objet qui ne fait rien et correspond au null, que d'avoir ce pointeur où l'on peut oublier un teste. C'est bien cela?

Oui! Plus de tests if ( x!=0 ) dans le code et plus besoin de tester que le code n'a pas oublié de faire le test.

- W

[HanLee]

boost::variant<T, null_type>, faut tester. ou est la différence??

Avec boost::variant, la différence c'est que tu ne peux pas oublier de tester, dans les conditions normales d'utilisation.

Si t'oublies de traiter le cas null_type, le compilateur t'envoie chier tout simplement.

------

Evidemment, ça ne marche que si tu ne contournes pas le typage, avec les pointeurs par exemple.

Supposons que ça te fasse chier de faire un visiteur, parce que tu sais que l'objet n'est pas nul. Tu vas te faire une fonction get() qui te retourne une référence vers l'objet variant.

Tu dois faire 2 fonctions membres, un qui prend en paramètre le type null_type, et l'autre de type T.
Pourquoi ? Sinon ça compile pas.

Pour traiter le type T, c'est évident, tu retournes le paramètre d'entrée.
Et quand tu traites le type null ?
Bah t'as pas d'autre choix que lancer une exception, si tu veux pas contourner le typage.

Et au final, on a rien gagné, autant écrire la fonction intéressante dans le visiteur, non ?

[loufoque]

Si dans le cas nul tu lances une exception ou que tu génères une erreur, c'est que ton état nul n'a pas de raison d'être...

[HanLee]

Si dans le cas nul tu lances une exception ou que tu génères une erreur, c'est que ton l'état nul n'a pas de raison d'être...

Et c'est ce qui rend la situation encore plus absurde avec ce get().