2010-02-05 23 views
2

J'ai deux méthodes d'extension qui convertissent un document MongoDB en entité/objet. Cela donne une erreur d'appel ambigu possible, donc je me demandais comment je pouvais résoudre ce problème?C# Appels ambigus - Type de retour différent

Amicalement,

Pickels

Répondre

7

fonctions ne peuvent pas être surchargées par type de retour. Vous devrez renommer vos fonctions peut-être:

ConvertToProductTemplate() et ConvertToProduct()

ou les transformer en une fonction qui retourne une classe de base commune ou de l'interface. (Mais l'appelant devra faire un casting quand ils le résultat)

+0

Merci, c'est la réponse que je cherchais. – Pickels

+0

ou si vous voulez vraiment garder le nom. vous pouvez mettre les méthodes d'extension dans différents espaces de noms, mais je suggère de coller avec la solution des noms différents, car compter sur l'ordre de vos instructions d'utilisation se traduira par très difficile à lire le code –

+0

Vérifiez la réponse de Tomas. C'est encore mieux. Dans ma vieillesse, j'oublie parfois d'utiliser des génériques. –

3

vous pouvez changer les noms:

public static ProductTemplate ConvertToProductTemplate(this Document document) 
{ 
    return null; 
} 

public static Product ConvertToProduct(this Document document) 
{ 
    return null; 
} 
+0

Ouais, en fait je pensais juste qu'il pourrait être mieux de les appeler ToProductTemplate et ToProduct. – Pickels

+0

C'est la façon .NET de nommer ces choses. Recherchez la classe statique 'Convert'. – Blindy

8

Vous pouvez faire votre méthode Convert générique:

public static T ConvertTo<T>(this Document doc) where T : SomeBaseClassOrInterface 
{ 
    return null; 
} 

utiliser ensuite comme si:

var document = new Document(); 
var temp = document.ConvertTo<ProductTemplate>(); // returns a ProductTemplate 
var prod = document.ConvertTo<Product>(); // returns a Product 
+0

+1. Bien que j'aime cette approche, elle n'est appropriée que lorsque vous avez une interface/classe de base. Et si vous avez beaucoup de dérivés et que vous ne voulez en convertir que quelques-uns, vous pourrez appeler la méthode, mais vous devrez vérifier le résultat pour null ou obtenir une exception. Je préfère le style explicite ConvertToType(). Je préférerais voir 3 méthodes que je sais utiliser, une qui fonctionne pour 3 types mais pas pour 3 autres. –

+0

Pourquoi écrire une méthode générique pour une interface commune lorsque vous pouvez retourner cette interface à partir d'une méthode non générique? S'il vous plaît voir ma réponse pour plus de détails. –

+0

@bebop: Au lieu d'écrire une méthode 'ConvertToType()' pour chaque type que vous voulez convertir, vous pouvez simplement créer une interface vide 'IConvertibleFromDocument' et l'appliquer à chaque type pertinent. Ou sautez simplement la condition sur 'T', et lancez' InvalidOperationException' s'il n'y a aucun moyen de convertir en un type donné. –

1

I avoir un sentiment que produit et classes ProductTemplate sont en quelque sorte liés (par exemple produit s'étend ProductTemplate). Si j'ai raison, vous pouvez simplement retourner la classe de base (ProductTemplate dans ce cas).

Tomas Lycken a suggéré d'utiliser la méthode générique, qui est à mon avis tout à fait une bonne idée, mais s'il y a une interface commune pour les produits et productTemplate, il vous suffit de retourner cette interface aussi bien au lieu de produit et ProductTemplate.

Exemple (par Tomas Lycken):

public static T ConvertTo<T>(this Document doc) where T : SomeBaseClassOrInterface 
{ 
    return null; 
} 

Exemple (par moi):

public static SomeBaseClassOrInterface ConvertTo(this Document doc) 
{ 
    return null; 
} 

Et s'il n'y a pas d'interface commune et vous ne voulez pas créer un nouveau, s'il vous plaît juste changer de nom :)

+0

Vous avez raison Le produit et le modèle sont liés. Je souhaite que l'utilisateur puisse concevoir ses propres produits et que ces informations soient stockées en tant que ProductTemplates. C'est une collection de propriétés que chaque produit peut avoir. Toujours en train de faire des tests pour voir quelle est la meilleure approche. Je vous remercie pour votre réponse, je vais certainement l'examiner. – Pickels

+0

n'est pas le problème avec ceci que si le produit prolonge le modèle que vous ne saurez pas si vous avez un produit sans essayer de le lancer? Si vous pouvez toujours créer un produit, vous n'avez besoin que de la méthode de conversion et si le produit étend le modèle, vous pouvez utiliser le produit partout où vous avez besoin d'un modèle. Je ne vois pas l'avantage de retourner la classe de base. éclaire-moi. –

+0

C'est intéressant. Vous avez noté la réponse de Tomas Lycken +1 et maintenant vous ne voyez pas l'avantage de retourner une classe de base. L'avantage de renvoyer une classe de base est identique à celui de renvoyer une interface. Vous pouvez évidemment avoir des tonnes d'implémentations/extensions de la classe de base et ne vous souciez pas des différents convertisseurs pour chacun d'entre eux. dans ce cas - si vous avez besoin et la mise en œuvre explicite du convertisseur - vous pouvez en écrire un. –