Compte tenu de cet exemple:
Interface CustomersDao
Function Get(ByVal Id As Integer) As Customer
Function Get(ByVal Filter As Filter) As IList(Of Customer)
End Interface
Public Sub Main()
Dim Customer As Customer = CustomersDao.Get(4)
Dim Filter As New CustomersDao.Filter
Filter.Category = 2
Dim Customers As IList(Of Customer) = CustomersDao.Get(Filter)
End Sub
6 Réponses :
Non, je dirais que cela convient parfaitement.
+1 Je suis d'accord sauf si la surcharge modifie le but de base. Par exemple, une méthode peinture () qui renvoie différents types n'est qu'un polymorphisme, mais il ne doit pas Ne pas peindre un cheval solide noir et peindre un zèbre dans des rayures.
-1. Trouvez un exemple dans la structure .NET. Je ne peux pas penser à un.
@Aliostad: Je ne suis pas sûr des méthodes d'instance, mais il existe des méthodes statiques dans CLR avec des types de rendement variable ( Activator.createInstance (chaîne, chaîne) vs Activator.createInstance (type, booléen) , par exemple). Mais je considère aussi que ce moche, surtout que l'une des surcharges renvoie un objet (code> (et le compilateur ne vous dérange pas si vous l'attribuez à un objet Objecthandle ).
@Groo Jon Skeet m'a rappelé quelques-uns. Mais ils comprennent une exception et seulement des cas où cela a du sens.
@Aliostad: D'accord, je ne vois pas le but de le faire du tout. Je m'attends à ce que ces méthodes "similaires" d'avoir des noms similaires mais différents (comme trouver et retranchées , par exemple), ce qui rend la distinction plus évidente (et intellisense leur montre un après l'autre, ils sont donc faciles à taper aussi).
Je recommanderais d'appeler le second En ce moment, il n'est pas évident que la deuxième méthode renvoie une collection. getall .
Vous devriez s'efforcer de vous assurer que vos classes sont aussi évidentes que possible et ne contiennent aucune surprise inattendue.
Cela ne répond pas vraiment à la question. Je pense que la question est mal formée mais Les méthodes surchargées renvoyant différents types ne sont pas intrinsèquement mauvaises.
1+. Je crois que c'est une mauvaise pratique.
Getall ou GetCustomers, comme si un filtre est fourni, il ne retournera probablement pas "tous" ...
Je suggérerais que ce n'est pas la meilleure pratique car il ne fournit pas de code intuitif et lisible si les déclarations variables ne sont pas immédiatement visibles. J'utiliserais généralement GetByid et GetForfilter, Getall, etc. qui décrit mieux l'action qui se déroule.
Dans votre exemple, l'API a du sens et a l'air intuitive. Surtout depuis que vous avez nommé l'identifiant des arguments de fonction et le filtre qui, IMO, impliquent une valeur unique et une collection respectivement. L'inconvénient étant que dans un scénario IntelliSense, vous devriez examiner chaque surcharge pour voir ce qu'il fait plutôt voir la méthode appropriée à appeler dans la liste suggérée. Par exemple. Je pouvais imaginer des scénarios où la surcharge et le retour de types différents pourraient rapidement devenir très déroutant. Surtout si vous commencez à introduire des hacks pour travailler autour d'une utilisation établie de l'API. Getinglele (int ID) vs. code> getallall () vs. code> getubset (filtre à chaîne)
Oui, je crois que c'est une mauvaise pratique essayez de trouver une surcharge dans .NET Framework qui renvoie un type différent, je ne peux pas penser à un .
Il existe des méthodes dans la framework .NET en tant que telle DateTime.Subrent () mais ils sont l'exception et non la règle et seuls cas où
Mise à jour
Il existe un certain nombre de méthodes qui renvoient une interface
TimezoneInfo.Convertitime. msdn.microsoft.com/en-us/library/bb383497.aspx Certaines méthodes retournent DateTetime, certains DateTimeOffset.
@Jon a accepté. Également dans DateTime Nous avons Soustraire et Ajouter mais ils comprennent moins de 1% des cas et dans ces cas, je peux accepter une exception.
@Aliostad: Je suis généralement d'accord pour dire que c'est une mauvaise idée. Je voulais juste donner un exemple du cadre :)
Merci @jon. C'était mon jour de chance aujourd'hui, avait le plaisir / l'honneur d'une brève conversation avec vous.
Est-ce qu'ils donnent un badge pour ça?
Ils doivent faire. Il peut s'agir d'une demande de fonctionnalité :)
Désolé de cogner les morts, mais j'ai remarqué aujourd'hui que diverses méthodes dans l'espace de noms Math le font.
Les interfaces de retour sont appropriées car (pratiques sonores-autorisation) Une interface liera différentes classes à un domaine problématique similaire et garantir un ensemble de méthodes cohérentes.
Différents types, cependant, méritent une vérification de l'odeur, car il est plus facile de se souvenir des différents arguments que vous pouvez utiliser pour obtenir des données que de se souvenir des différents types renvoyés ou de brancher votre propre code pour accueillir ces types même lorsque Vous vous en souvenez.
L'alternative manquante que personne n'a fourni ici est de surcharger à la fois comme renversant une liste, même s'il semble idiot pour ID ne renvoie qu'une liste d'une seule page. Il est excellent pour JQuery, qui est l'équivalent JavaScript d'une fonction massivement surchargée.
Les retours cohérents signifient que je n'ai que de me souvenir de ce que votre API fait pour moi plutôt que ce que je dois faire pour cela.