C'est toujours approprié, mais considérez attentivement les intentions derrière ce que vous affichez
Une meilleure question serait de demander:
Pourquoi remplacer ToString ()?
ToString () est la fenêtre dans l'état d'un objet. Accent sur l' État comme exigence. Les langages OOP tels que Java / C # abusent du modèle OOP en encapsulant tout dans une classe. Imaginez que vous codez dans un langage qui ne suit pas le modèle puissant de la POO; considérez si vous utilisez une classe ou une fonction. Si vous l'utilisez comme une fonction (c'est-à-dire un verbe, une action) et que l'état interne n'est maintenu que temporairement entre les entrées / sorties, ToString () n'ajoutera pas de valeur.
Comme d'autres l'ont mentionné, il est important de considérer ce que vous produisez avec ToString () car il pourrait être utilisé par le débogueur ou d'autres systèmes.
J'aime imaginer la méthode ToString comme le paramètre --help d'un objet. Il doit être court, lisible, évident et facile à afficher. Il doit afficher ce que l'objet n'est pas ce qu'il fait . Avec tout cela à l'esprit, considérons ...
Cas d'utilisation - Analyse d'un paquet TCP:
Pas une capture réseau au niveau de l'application uniquement, mais quelque chose avec plus de viande comme une capture pcap.
Vous souhaitez surcharger ToString () uniquement pour la couche TCP afin de pouvoir imprimer des données sur la console. Que comprendrait-il? Vous pourriez devenir fou et analyser tous les détails TCP (c'est-à-dire que TCP est complexe) ...
Qui comprend:
- Port source
- Le port de destination
- Numéro de séquence
- Numéro d'accusé de réception
- Décalage des données
- Drapeaux
- Décalage de la fenêtre
- Somme de contrôle
- Pointeur urgent
- Options (je ne vais même pas y aller)
Mais voudriez-vous recevoir tous ces déchets si vous appeliez TCP.ToString () sur 100 paquets? Bien sûr que non, ce serait une surcharge d'informations. Le choix facile et évident est aussi le plus judicieux ...
Exposez ce que les gens s'attendent à voir:
- Port source
- Le port de destination
Je préfère une sortie sensible qui est facile à analyser pour les humains, mais YMMV .
TCP:[destination:000, source:000]
Rien de complexe, la sortie n'est pas pour les machines à analyser (c'est-à-dire à moins que les gens n'abusent de votre code), le but recherché est la lisibilité humaine.
Mais qu'en est-il du reste de ces informations juteuses dont j'ai déjà parlé, n'est-ce pas utile aussi? J'y reviendrai mais d'abord ...
ToString () l'une des méthodes les plus précieuses et sous-utilisées de tous les temps
Pour deux raisons:
- Les gens ne comprennent pas à quoi sert ToString ()
- Il manque une autre méthode de chaîne, tout aussi importante, à la classe 'Object' de base.
Raison 1 - N'abusez pas de l'utilité de ToString ():
Beaucoup de gens utilisent ToString () pour extraire une simple représentation sous forme de chaîne d'un objet. Le manuel C # déclare même:
ToString est la principale méthode de mise en forme dans le .NET Framework. Il convertit un objet en sa représentation sous forme de chaîne afin qu'il soit adapté à l'affichage.
Affichage, pas de traitement ultérieur. Cela ne veut pas dire, prenez ma belle représentation sous forme de chaîne du paquet TCP ci-dessus et tirez le port source en utilisant un regex :: cringe ::.
La bonne façon de faire les choses est d'appeler ToString () directement sur la propriété SourcePort (qui BTW est un ushort donc ToString () devrait déjà être disponible).
Si vous avez besoin de quelque chose de plus robuste pour empaqueter l'état d'un objet complexe pour l'analyse de la machine, vous ferez mieux d'utiliser une stratégie de sérialisation structurée.
Heureusement, de telles stratégies sont très courantes:
- ISérialisable (C #)
- Cornichon (Python)
- JSON (Javascript ou tout autre langage qui l'implémente)
- SAVON
- etc...
Remarque: sauf si vous utilisez PHP car, herp-derp, il existe une fonction pour cela :: snicker ::
Raison 2 - ToString () ne suffit pas:
Je n'ai pas encore vu de langage qui implémente cela à la base, mais j'ai vu et utilisé des variations de cette approche dans la nature.
Certains d'entre eux incluent:
- ToVerboseString ()
- ToString (verbose = vrai)
Fondamentalement, ce désordre poilu de l'état d'un paquet TCP devrait être décrit pour la lisibilité humaine. Pour éviter de `` battre un cheval mort '' en parlant de TCP, je vais `` pointer du doigt '' le cas n ° 1 où je pense que ToString () et ToVerboseString () sont sous-utilisés ...
Cas d'utilisation - Tableaux:
Si vous utilisez principalement une langue, vous êtes probablement à l'aise avec l'approche de cette langue. Pour les gens comme moi qui sautent entre différentes langues, le nombre d'approches variées peut être irritant.
C'est-à-dire que le nombre de fois que cela m'a irrité est supérieur à la somme de tous les doigts de chaque dieu hindou combiné.
Il existe plusieurs cas où les langues communes utilisent hacks et un peu qui obtiennent ce droit . Certains nécessitent une réinvention de la roue, certains font un vidage peu profond, d'autres font un vidage profond, aucun d'entre eux ne fonctionne comme je le voudrais ...
Ce que je demande, c'est une approche très simple:
print(array.ToString());
Sorties: 'Array [x]' ou 'Array [x] [y]'
Où x est le nombre d'articles dans la première dimension et y est le nombre d'articles dans la deuxième dimension ou une valeur qui indique que la deuxième dimension est irrégulière (plage min / max peut-être?).
Et:
print(array.ToVerboseString());
Sort tout le she-bang en joli imprimé parce que j'apprécie les jolies choses.
Espérons que cela jette un peu de lumière sur un sujet qui me dérange depuis longtemps. À tout le moins, j'ai saupoudré un peu de troll-appât pour que les PHPers votent contre cette réponse.
Console.WriteLine(obj.GetToStringItemsHeadings); Console.WriteLine(obj);
ou similaire.