Les méthodes surchargées dans l'interface

ma question pour aujourd'hui: la surcharge des méthodes dans l'interface mauvais? Vous savez, le "omettre les paramètres si vous ne vous inquiétez pas, nous allons trouver les valeurs par défaut" genre de méthodes surchargées.
Comme ça:

void Add(object item); 
void Add(object item, bool shouldDoSomething); 
void Add(object item, bool shouldDoSomething, IUltraObscureDeviceContext context);

Dans ce cas, j'ai tendance à penser que seul celui-ci appartient à une interface et d'autres devraient être mis en œuvre dans la classe abstraite sur le dessus de cela. Mais là encore, je ne suis pas sûr.

Aussi, il ya des moments où vous voulez juste différentes surcharges faire légèrement différents travaux (arrêtez-moi là en cas de surcharge des méthodes ne doit jamais être utilisé pour cela). Ou parfois, vous ne pouvez pas juste des trucs valeurs null à la place de certains paramètres, vous voulez l'exception levée si quelque chose est nul. Ne dois-je pas utiliser la surcharge dans ce cas?

Donc, fondamentalement, je suis à la recherche de quelques lignes directrices sur les méthodes surchargées dans les interfaces vs méthodes surchargées dans les classes abstraites mise en œuvre de ces interfaces et ainsi de suite.
Merci d'avance

Si le contrat que vous êtes approvisionnement promet d'offrir 3 versions de cette méthode, vous devez inclure ces surcharges.
Six de l'un, une demi-douzaine. La vraie question est de savoir s'ils devraient être en défaut de interface, pas la façon dont ces valeurs par défaut sont exprimés.
Parce que les paramètres par défaut ne sont pas certains de la balle magique qui signifie maintenant surcharges sont obsolètes. Par exemple, les valeurs par défaut doit être constante, et peut-être la surcharge va passer d'une variable à la deuxième ou troisième surcharge. Juste parce que vous avez un tout nouveau jouet ne signifie pas que c'est une bonne idée de l'utiliser partout.
par défaut passionnés: blogs.infosupport.com/blogs/ernow/archive/2010/04/03/...
Un blunt estimation: si tout le monde de lire les specs, stackoverflow pourrait chuter de plus de la moitié de ses serveurs, des disques et de la bande passante.

OriginalL'auteur Dyppl | 2011-01-26

  1. 8

    Si les valeurs par défaut dépendent du récepteur de l'appel de méthode, de les déclarer comme des méthodes d'interface.

    Si les valeurs par défaut sont simplement les valeurs par défaut quel que soit le récepteur, de créer les différents réduite-argument-liste des surcharges que les méthodes d'extension et d'enregistrer des réalisateurs les maux de tête d'avoir à fournir tous les surcharges eux-mêmes.

    Si vous avez affaire à une sorte de nitty-gritty règle des 80/20 exceptions, où la mise en œuvre indépendante par défaut sont presque mais pas tout à fait toujours suffisant, vous avez quelques options, dont aucun n'est que du bon:

    • Traiter avec elle comme si ils sont toujours différents, de les déclarer comme des méthodes d'interface, et réimplémenter partout. Pas très SÈCHE.
    • Traiter avec elle comme si ils sont toujours différents, de les déclarer comme des méthodes d'interface, et d'hériter d'une classe de base qui fournit 80% de la valeur par défaut de mise en œuvre. Un peu maladroit, et pas bon si votre seul de la classe de base logement est déjà occupé.
    • Créer une interface contenant ces méthodes spécifiques. Déclarer les méthodes d'extension avec signature correspondante à l'encontre de l'interface d'origine. Dans les méthodes d'extension, as-cast le this argument de la nouvelle interface de type, et si elle correspond, appelons là, autrement remplir en stock par défaut. Très funky, reposant sur une dynamique de casting afin de ne pas génial dans une boucle interne, mais il dissocie les paramètres par défaut de la fois réalisateur et appelant sans sacrifier la flexibilité pour des réalisateurs qui ne peuvent pas prendre le "par défaut valeurs par défaut".
    La dernière option est en effet très funky, mais les sons comme une bonne solution pour un mauvais problème. Réponse solide dans l'ensemble, merci.
    Comment avoir l'interface comprend un masque de bits-enum paramètre qui indique les autres paramètres sont spécifiés, et de la mise en indépendant wrappers appeler le "réel" de routine avec les valeurs appropriées dans les paramètre supplémentaire? Si j'avais tenait qu'à moi, il y aurait un moyen de le faire automatiquement, mais même sans un mécanisme automatique, il pourrait encore être une bonne approche.

    OriginalL'auteur Jeffrey Hantin

  2. 1

    Méthodes surchargées dans une interface peut-être Ok si le design de l'interface de bons de souscription. Je n'ai personnellement jamais nécessaire pour ce faire.

    Je n'aurais pas de définir les paramètres par défaut des valeurs dans une interface. C'est un détail d'implémentation que la mise en œuvre des classes qui choisissent de surface.

    - vous faire un commentaire sur le fait d'avoir différentes implémentations pour les surcharges....

    Ne pas le faire. Pensez à la mise en œuvre de ces méthodes surchargées comme l'appel à une méthode qui a tous les paramètres définis avec certaines valeurs par défaut. C'est la façon dont les utilisateurs de votre code d'attendre que les choses à être.

    Si vous avez besoin d'comportement différent alors utiliser le polymorphisme. C'est ce son là pour.

    Le polymorphisme ne vais pas vous donner deux implémentations dans une instance. Je suppose, c'est ce que les méthodes avec des noms différents sont là pour
    Oui, indirectement ce que je disais, que la mise en œuvre de la classe doit être différent et de ne pas mélanger les choses en ayant différentes surcharges de mettre en œuvre des choses différentes, mais pour utiliser le polymorphisme à la place.

    OriginalL'auteur Shiv Kumar

  3. 0

    De l'OMI, si l'interface de contrat et/ou des sorts, il devrait y avoir aucun problème. Cependant, l'objectif est de simplifier les choses quand on expose une interface et masquer les détails. Et c'est là que facultatif params venir dans maniable.Tout les langages orientés objets comme le Python n'ont même pas de surcharge autant que je sache

    D'autres parfaitement adéquate des langages orientés objet comme Objective-C n'ont pas d'interfaces (ObjC a des protocoles qui sont plus ou moins liés) qui serait aussi couper la question.

    OriginalL'auteur Perpetualcoder