Pourquoi "éviter la surcharge des méthodes" ?

Question

Pourquoi est-ce que Jorge Ortiz conseille d'éviter la surcharge des méthodes ?

Answer 1

La surcharge rend un peu plus difficile la transformation d'une méthode en fonction :

object A {
   def foo(a: Int) = 0
   def foo(b: Boolean) = 0
   def foo(a: Int, b: Int) = 0

   val function = foo _ // fails, must use = foo(_, _) or (a: Int) => foo(a)
}

Vous ne pouvez pas importer sélectivement une méthode parmi un ensemble de méthodes surchargées.

Il y a plus de chances qu'une ambiguïté surgisse lorsqu'on essaie d'appliquer des vues implicites pour adapter les arguments aux types de paramètres :

scala> implicit def S2B(s: String) = !s.isEmpty                             
S2B: (s: String)Boolean

scala> implicit def S2I(s: String) = s.length                               
S2I: (s: String)Int

scala> object test { def foo(a: Int) = 0; def foo(b: Boolean) = 1; foo("") }
<console>:15: error: ambiguous reference to overloaded definition,
both method foo in object test of type (b: Boolean)Int
and  method foo in object test of type (a: Int)Int
match argument types (java.lang.String)
       object test { def foo(a: Int) = 0; def foo(b: Boolean) = 1; foo("") }

Il peut tranquillement rendre les paramètres par défaut inutilisables :

object test { 
    def foo(a: Int) = 0; 
    def foo(a: Int, b: Int = 0) = 1 
}

Individuellement, ces raisons ne vous obligent pas à éviter complètement la surcharge. J'ai l'impression de passer à côté de problèmes plus importants.

UPDATE

Les preuves s'accumulent.

• Il complique le spec
• Il peut rendre les implicites inadaptés à utiliser dans les limites de la vue.
• Elle vous limite à introduire des valeurs par défaut pour les paramètres sur une seule des alternatives surchargées.
• Parce que les arguments seront typés sans type attendu, vous ne pouvez pas passer des littéraux de fonction anonymes comme '_.foo' comme arguments pour les méthodes surchargées .

MISE À JOUR 2

• Vous ne pouvez pas (actuellement) utiliser des méthodes surchargées dans les objets du paquet.
• Les erreurs d'applicabilité sont plus difficile à diagnostiquer pour les appelants de votre API.

MISE À JOUR 3

• La résolution statique des surcharges peut priver une API de toute sécurité de type :

  scala> object O { def apply[T](ts: T*) = (); def apply(f: (String => Int)) = () } defined object O

  scala> O((i: String) => f(i)) // oops, I meant to call the second overload but someone changed the return type of f when I wasn't looking...

Answer 2

Gilad Bracha a publié un bon article expliquant cela il y a quelque temps :

http://gbracha.blogspot.com/2009/09/systemic-overload.html

Answer 3

Les raisons que Gilad et Jason (retronym) donnent sont toutes de très bonnes raisons d'éviter la surcharge si possible. Les raisons de Gilad se concentrent sur les raisons pour lesquelles la surcharge est problématique en général, tandis que les raisons de Jason se concentrent sur les raisons pour lesquelles elle est problématique dans le contexte d'autres fonctionnalités de Scala.

À la liste de Jason, j'ajouterais que la surcharge interagit mal avec l'inférence de type. Pensez-y :

val x = ...
foo(x)

Un changement dans le type présumé de x pourrait modifier ce qui foo est appelée. Le site valeur de x ne doit pas changer, seul le type inféré de x ce qui peut se produire pour toutes sortes de raisons.

Pour toutes les raisons citées (et quelques autres que je suis sûr d'oublier), je pense que la surcharge des méthodes doit être utilisée avec le plus de parcimonie possible.

Answer 4

Je pense que le conseil n'est pas destiné à scala en particulier, mais à l'OO en général (pour autant que je sache, scala est censé être un best-of-breed entre OO et fonctionnel).

Remplacement de c'est bien, c'est le cœur du polymorphisme et c'est central pour la conception OO.

Surcharge de travail d'autre part, est plus problématique. Avec la surcharge de méthodes, il est difficile de discerner quelle méthode sera réellement invoquée et c'est souvent une source de confusion. Il est également rare que l'on puisse justifier la nécessité de la surcharge. Le problème peut la plupart du temps être résolu d'une autre manière et je suis d'accord que la surcharge est une odeur.

Voici un article qui expliquent bien ce que je veux dire par "la surcharge est une source de confusion", ce qui, je pense, est la principale raison pour laquelle elle est déconseillée. C'est pour Java, mais je pense que cela s'applique aussi à Scala.