meilleures pratiques Surcharger

Question

Dire que j'ai une méthode qui retourne un objet métier:

public static MyObject GetObject() 
{ 
    return Blah.Blah(); 
} 

Maintenant, je besoin d'une autre méthode qui fait la même chose, mais retourne MyObject dans un format XML:

public static string GetObject(bool returnXml) 
{ 
    return Blah.Blah.Xml(); 
} 

J'ai commencé avec cette approche, mais je me suis vite rendu compte que l'appelant pouvait spécifier false pour returnXml.

Est-ce que ma seule option est de renommer ma méthode en quelque chose comme GetObjectAsXml?

---

Mise à jour ... merci à tous.

Mes méthodes d'origine ressemblent à ceci.

public static MyObject GetObject() 
{ 
    return ConvertToMyObject(GetResponseAsXML()); 
} 

J'ai juste besoin d'une nouvelle série de méthodes qui ressemblent à ceci:

public static string GetObject() 
{ 
    return GetResponseAsXML(); 
} 

D'après les réponses, il semble que la meilleure façon est d'avoir une deuxième série de méthodes qui sont nommés GetObjectAsXML, droit ? Je ne veux pas vraiment faire GetObject(). ToXml() parce que je veux retourner la réponse originale.

Answer 1

Je ne sais pas pourquoi vous surchargez la même méthode ici.

L'un renvoie l'objet, l'autre renvoie une représentation/sérialisation XML de cet objet. J'utiliserais deux méthodes différentes.

Quoi de plus intéressant est ce que vous faites avec ces objets et sérialisations XML; le consommateur voudra probablement 2 surcharges qui prennent n'importe quel type comme paramètre, mais cela dépend de vos besoins.

Answer 2

Il existe plusieurs façons de procéder: certaines de vos décisions dépendront de votre système. Cependant, si je concevais un système dans lequel les informations devaient être renvoyées différemment en fonction de qui en avait besoin, je ne rendrais pas l'objet responsable de la mise en forme correcte, car cela viole le principe du maintien d'un coefficient élevé. le système ne fait qu'une chose). Au lieu de cela, je voudrais créer un sous-système qui peut prendre dans votre objet métier et a la connaissance de la façon de le convertir en XML, fichier plat, YAML, tout ce que vous avez besoin d'être. Et, si vous avez d'autres objets métier issus de la même "classe de base d'objet métier", ce sous-système fonctionnera également pour tous ces objets, créant ainsi un système plus réutilisable.

Answer 3

public static MyType GetObject() 
{ 
    return Blah.Blah(); 
} 

public static string GetObjectAsXml() 
{ 
    return Blah.Blah().Xml(); 
} 

Answer 4

Je ne sais pas si vous avez besoin d'une surcharge du tout dans cette situation. Vous avez

public static MyObject GetObject() 
{ 
    return Blah.Blah(); 
} 

pour obtenir l'objet. Obtenir le XML pour l'objet semble être une fonction d'exemple, et non pas une fonction statique, et vous pourriez obtenir le XML avec cet appel:

string xmlStuff = GetObject().Xml(); 

Answer 5

Les meilleures pratiques? Que diriez-vous d'une meilleure pratique, en particulier le principe de la responsabilité unique? Votre approche combine les tâches d'obtention de votre objet et de sérialisation.SRP dicte que ce sont deux responsabilités complètement différentes. En outre, qui est-ce que vous voulez le sérialisé en utilisant le XmlSerializer, le XamlSerializer, ou même le NetDataContractSerializer?

Je laisserais le type qui doit avoir l'objet sérialisé faire la sérialisation. Je désignerais un type comme sérialiseur, je l'aurais injecté dans le cadre d'un framework d'injection de dépendances, et je l'utiliserais partout pour effectuer ma sérialisation. Ou, si le type ayant besoin de l'objet à sérialiser était en charge à la fois de la sérialisation et de la désérialisation, je lui laisserais la responsabilité de choisir le sérialiseur lui-même.