Salut
Y a t il moyen d'eviter/alleger ce genre de code
Thx
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 if (a != null && a.b != null && a.b.c != null && a.b.c.d != null) { a.b.c.d.Test(); }
Salut
Y a t il moyen d'eviter/alleger ce genre de code
Thx
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 if (a != null && a.b != null && a.b.c != null && a.b.c.d != null) { a.b.c.d.Test(); }
A ma connaissance, non.
Je mets une baffe au premier qui propose ça :
Code : Sélectionner tout - Visualiser dans une fenêtre à part try{ a.b.c.d.Test(); } catch {}
Besoin d'un MessageBox amélioré ? InformationBox pour .NET 1.1, 2.0, 3.0, 3.5, 4.0 sous license Apache 2.0.
Bonnes pratiques pour les accès aux données
Débogage efficace en .NET
LINQ to Objects : l'envers du décor
Mon profil LinkedIn - MCT - MCPD WinForms - MCTS Applications Distribuées - MCTS WCF - MCTS WCF 4.0 - MCTS SQL Server 2008, Database Development - Mon blog - Twitter
c'est très laid comme code quand même
"Ne parlez pas aux inconnus - ne parlez qu'à vos amis immédiats"
Il faut être attentif pour chaque objet au nombre de classes avec lesquelles il interagit. Ce principe évitela création de classes fortement couplées.
Concrétement, si tu considères un objet; à partir de n'importe quelle méthode de cet objet tu ne dois appeler que des méthodes qui appartiennent:
Il faut éviter les a.GetObjet.GetObjet.GetObjet etc.
- à cet objet
- aux objets transmis en arguments à la méthode
- aux objets que la méthode crée
- aux composants de l'objet
Ici ton objet n'a des référence qu'à "a". Il ne doit donc pas connaitre b, c ou d. Si tu veux executer la méthode Test, demande le à "a" c'est tout. Et c'est "a" qui se chargera d'appeler b etc.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 if (a != null) { a.AppelerTest(); }
Les règles du forum
Le trio magique : FAQ + Cours + fonction rechercher
Mes articles
Pas de questions par messages privés svp
Software is never finished, only abandoned.
Le Null object pattern est ce dont tu as besoin Google !
Exemple : (attention, bidouille, mais jolie bidouille )
J'avais trouvé ça sur le net, je sais plus où. Sur CodeProject probablement.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12 public class Address { private static Address Empty = new Address(); public string StreetName = null; public static Address operator +(Address address) { return address ?? Empty; } } Console.WriteLine("The street name is "+ (+address).StreetName ?? "n/a" + ".");
ಠ_ಠ
Encore un fana de ce genre de code, faut savoir que tout le monde ne comprends pas
Code : Sélectionner tout - Visualiser dans une fenêtre à part return address ?? Empty;
Je ne comprends pas
Peux tu s'il te plait m'expliquer ce que font les ??
Pourquoi faire compliqué lorsque l'on peut faire encore plus compliqué.
Thomas LEBRUN: MCAD.NET, MCTS (Win et Web), MCPD(Win et Web) & Microsoft MVP Client Application Development
WPF par la pratique, mon livre sur WPF ! (également disponible ici ou là)
A la découverte de .NET
Besoin d'un MessageBox amélioré ? InformationBox pour .NET 1.1, 2.0, 3.0, 3.5, 4.0 sous license Apache 2.0.
Bonnes pratiques pour les accès aux données
Débogage efficace en .NET
LINQ to Objects : l'envers du décor
Mon profil LinkedIn - MCT - MCPD WinForms - MCTS Applications Distribuées - MCTS WCF - MCTS WCF 4.0 - MCTS SQL Server 2008, Database Development - Mon blog - Twitter
Personnellement, je trouve cela particuliérement inélégant (pas tant la définition que la syntaxe d'appel (+address), mais on a le droit de le qualifier de "jolie bidouille"; en premiére lecture, et, en imaginant que je trouve cela dans un code, je le qualifierais plutôt d'inutilement abscon.
Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...
Une réponse vous a aidé ? utiliser le bouton
"L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel
Pas forcement, pour une question de lisibilité et de maintenabilité je pense que l'utilisation de ?? n'est pas térrible.
Ecrire le test c'est mieux.
Ne me raconter pas que c'est une histoire d'optimisation, on ne gagne pas grand chose avec cela, et en dehors du monde de l'embarqué, ce n'est pas très utile.
je trouve que c'est plus un truc de codeur qu'autre chose.
Mais le codeur tend à disparaître
Comme écrire en français sans faire de faute d'orthographe, de conjugaison, et de grammaire
Pourquoi faire compliqué lorsque l'on peut faire encore plus compliqué.
Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...
Une réponse vous a aidé ? utiliser le bouton
"L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel
Ce qui ne veut pas dire qu'il faut éradiquer cet usage au détriment du sens.
C'est incohérent, parce que selon ton raisonnement si tu veux appeler a.b.c.d.méthode tu dois implémenter a.appelMéthode->b.appelMéthode->c.appelMéthode->d.méthode, ce qui implique que c fait tout ce que fait d, b tout ce que fait c, et a fait tout ce que fait b, donc a connait le comportement de b, c et d ! Et d'un point de vue sémantique c'est une erreur car cela ajoute un comportement dans a qui n'a pas lieu d'être.Ici ton objet n'a des référence qu'à "a". Il ne doit donc pas connaitre b, c ou d. Si tu veux executer la méthode Test, demande le à "a" c'est tout. Et c'est "a" qui se chargera d'appeler b etc.
Franckintosh, penseur différent.
Moi non plus j'utiliserai jamais ça dans un projet hein
Ce que je voulais montrer, c'est que le null pattern object pourrait être plus intégré au langage. Ca vous gonfle pas, vous, de devoir tester la nullité d'une référence avant d'effectuer une opération, alors qu'on voudrait simplement ne rien faire si l'objet est null ? Il serait intéressant d'avoir une syntaxe permettant d'indiquer simplement que faire quand une référence est nulle UNE BONNE FOIS POUR TOUTES plutôt que de faire des if (machin == null).
Par exemple :
L'idéal serait un "anti-nullable" : une notation pour des références qui ne peuvent pas être null. Ca nécessiterait de codifier la notion de "valeur par défaut", mais ça serait intéressant et virerait des tas de tests relous. Et le bout de code que j'ai filé dans mon précédent post n'est qu'une façon bidouillatrice de représenter le concept
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10 // bouh, bavard, j'aime pas ! foreach(Machin machin in listMachin) { if (machin != null) machin.Update(); } // mieux ! MachinNull machinparDefaut = new MachinNull(); // MachinNull hérite de Machin, avec une fonction Update qui fait rien foreach(Machin machin in listMachin) (machin ?? machinparDefaut).Update();
@ced600 : par contre, le ?? n'est pas une bidouille ni un délire d'esthète, il permet au contraire de clarifier le code... Va dire aux BDA que la coalescence sert à rien
Machin machin = GetMachinInCache(42) ?? GetMachinSurUnServeur(42);
est plus simple et plus lisible que
Machin machin = GetMachinInCache(42);
if (machin == null)
machin = GetMachinSurUnServeur(42);
M'en sers tout le temps.
ಠ_ಠ
C'est au contraire très cohérent. En fait, si on prend un exemple de la vraie vie, c'est plus simple à comprendre. Prenons une entreprise de peinture en batiment. Cette entreprise sait faire de la peinture en batiment parce que ses employés savent faire de la peinture en batiment.
Un client va embaucher la société car il sait que celle-ci dans sa globalité sait faire de la peinture en batiment. Ce client se fiche de savoir si c'est Néness ou Dédé qui sait peindre. Il ne voit que la société.
Pour revenir à notre exemple, la société de peinture serait la classe A qui contient/emploie des peintres B qui savent peindre (méthode appelée).
Au final, la classe utilisatrice (celle qui fait le if) ne devrait faire que A.méthode(). Après, peu lui importe que ce soit B ou C ou D qui peigne (appelle la méthode).
Besoin d'un MessageBox amélioré ? InformationBox pour .NET 1.1, 2.0, 3.0, 3.5, 4.0 sous license Apache 2.0.
Bonnes pratiques pour les accès aux données
Débogage efficace en .NET
LINQ to Objects : l'envers du décor
Mon profil LinkedIn - MCT - MCPD WinForms - MCTS Applications Distribuées - MCTS WCF - MCTS WCF 4.0 - MCTS SQL Server 2008, Database Development - Mon blog - Twitter
Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...
Une réponse vous a aidé ? utiliser le bouton
"L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel
Je vais quand même donner mon avis sur ce code :
C'est pas très beau certes, mais en plus ça ne devrait pas exister.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 if (a != null && a.b != null && a.b.c != null && a.b.c.d != null) { a.b.c.d.Test(); }
Soit b, c et d sont passés en paramètres dans le constructeur de a, et dans ce cas si il y a un null, tu ne peux t'en prendre qu'à toi-même. Sous-entendu que c'est bien avant que le test doit s'effectuer, pas sur l'appel.
Soit b, c et d sont entièrement à la charge de a, et tu devrais te manger une exception directement à l'instanciation de a si quelque chose cloche pour charger b, c et d !
Devoir tester un tel arbre d'appel ça a une bonne tête d'anti-pattern quand même
In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.
Je suis d'accord avec tout ce qui viens de ce dire.
D'ailleurs un exemple simple l'utilisation du patron de conception état pour un langage de programmation objet.
Lorsque tu veux gérer les états de ta classe, tu vas créer une classe d'état abstraite et faire faire plein de classe dérivé de celle-ci qui représente les états.
Ta classe de départ se fou royalement de savoir s'il elle va appellé la méthode de telle ou telle état, après il y une variable et une méthode qui s'occupe de gérer l'état courant.
Ta classe de départ appel la méthode de la classe abstraite.
Ce genre d'encapsulation te permet de faire des choses beaucoup plus fine, c'est plus lisible, et plus facilement maintenable.
@ Guulh :
je ne vois aps en koi c plus simple et plus lisible, je dirais même l'inverse.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7 Machin machin = GetMachinInCache(42) ?? GetMachinSurUnServeur(42); est plus simple et plus lisible que Machin machin = GetMachinInCache(42); if (machin == null) machin = GetMachinSurUnServeur(42);
C'est comme tout ce qui est hérité du langage c++, les i++ i+=3, ...
C'est moins lisible, on si fait à force car on les rencontre tout le temps et on les utilise.
Mais ce genre de syntaxe n'est pas utilisé de la même façon partout, alors n'est pas facilement maintenable partout.
Et puis désolé mais : i = i +1 -> clair et compréhensible dès la première fois que tu le vois.
i++ -> lorsque tu le vois pour la première fois tu ne le comprends qu'après que l'on t'ai dit ue c'est la même chose que i = i + 1 !!!!!
Pourquoi faire compliqué lorsque l'on peut faire encore plus compliqué.
AMHA, c'est comme beaucoup de choses produisant in fine le meme effet, à savoir une question de gout. ??, ca reste quand meme tres 'Geek-code', j'ai du le rencontrer une fois dans une source, alors que les operateurs d'incrementation, c'est quand meme globalement tres utilisé. C'est un peu pareil pour les operateurs ternaires, les methodes anonymes etc , certains trouvent ca clair, d'autres pas, toujours la meme chose, affaire de gout. =)
1) C'est pas la même chose d'un point de vue processeur, incrémenter va nettement plus vite, même si nous on s'en fout parce que les compilos unpoil optimisés remplacent automatiquement i = i+1 en i++.
2) T'abuses quand même, tu le vois une fois, tu l'apprends et c'est bon... C'est dans les 3/4 des langages. Je sais pas si t'as déjà fait du C++, mais avec les surcharges d'opérateurs de partout, tu prendrais peur
3) monIcone = estContent ? "Content.ico" : "pasContent.ico", je trouve ça clair et élégant. Les blocs if then else sont tellement courants qu'il se conçoit très bien d'en simplifier la syntaxe pour les cas les plus simples.
ಠ_ಠ
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager