La section 6.3 de la spécification du langage TypeScript parle de surcharge de fonctions et donne des exemples concrets sur la façon de l'implémenter. Cependant, si j'essaye quelque chose comme ça:

export class LayerFactory { 

    constructor (public styleFactory: Symbology.StyleFactory) { }

    createFeatureLayer (userContext : Model.UserContext, mapWrapperObj : MapWrapperBase) : any {           
         throw "not implemented";
    }                 

    createFeatureLayer(layerName : string, style : any) : any {
        throw "not implemented";
     }        

}

J'obtiens une erreur du compilateur indiquant l'identificateur en double même si les paramètres de fonction sont de types différents. Même si j'ajoute un paramètre supplémentaire à la deuxième fonction createFeatureLayer, j'obtiens toujours une erreur de compilation. Des idées, s'il vous plaît.

Cela peut être dû au fait que, lorsque les deux fonctions sont compilées en JavaScript, leur signature est totalement identique. Comme JavaScript n'a pas de types, nous finissons par créer deux fonctions en prenant le même nombre d'arguments. Ainsi, TypeScript nous empêche de créer de telles fonctions.

TypeScript prend en charge la surcharge en fonction du nombre de paramètres, mais les étapes à suivre sont un peu différentes si l'on compare aux langages OO. En réponse à une autre question SO, quelqu'un l'a expliqué avec un bel exemple: surcharge de méthode? .

Fondamentalement, ce que nous faisons, c'est que nous créons une seule fonction et un certain nombre de déclarations afin que TypeScript ne donne pas d'erreurs de compilation. Lorsque ce code est compilé en JavaScript, la fonction concrète seule sera visible. Comme une fonction JavaScript peut être appelée en passant plusieurs arguments, cela fonctionne simplement.

Lorsque vous surchargez dans TypeScript, vous n'avez qu'une seule implémentation avec plusieurs signatures.

class Foo {
    myMethod(a: string);
    myMethod(a: number);
    myMethod(a: number, b: string);
    myMethod(a: any, b?: string) {
        alert(a.toString());
    }
}

Seules les trois surcharges sont reconnues par TypeScript comme des signatures possibles pour un appel de méthode, pas l'implémentation réelle.

Dans votre cas, j'utiliserais personnellement deux méthodes avec des noms différents car il n'y a pas suffisamment de points communs dans les paramètres, ce qui rend probable que le corps de la méthode devra avoir beaucoup de "si" pour décider quoi faire.

TypeScript 1.4

À partir de TypeScript 1.4, vous pouvez généralement supprimer la nécessité d'une surcharge à l'aide d'un type d'union. L'exemple ci-dessus peut être mieux exprimé en utilisant:

myMethod(a: string | number, b?: string) {
    alert(a.toString());
}

Le type de aest "soit stringou number".

Vous pouvez déclarer une fonction surchargée en déclarant la fonction comme ayant un type qui a plusieurs signatures d'invocation:

interface IFoo
{
    bar: {
        (s: string): number;
        (n: number): string;
    }
}

Ensuite, ce qui suit:

var foo1: IFoo = ...;

var n: number = foo1.bar('baz');     // OK
var s: string = foo1.bar(123);       // OK
var a: number[] = foo1.bar([1,2,3]); // ERROR

La définition réelle de la fonction doit être singulière et effectuer la répartition appropriée en interne sur ses arguments.

Par exemple, utiliser une classe (qui pourrait implémenter IFoo, mais ne doit pas):

class Foo
{
    public bar(s: string): number;
    public bar(n: number): string;
    public bar(arg: any): any 
    {
        if (typeof(arg) === 'number')
            return arg.toString();
        if (typeof(arg) === 'string')
            return arg.length;
    }
}

Ce qui est intéressant ici, c'est que le anyformulaire est masqué par les remplacements plus spécifiquement saisis.

var foo2: new Foo();

var n: number = foo2.bar('baz');     // OK
var s: string = foo2.bar(123);       // OK
var a: number[] = foo2.bar([1,2,3]); // ERROR

Qu'est-ce que la surcharge de fonctions en général?

La surcharge de fonctions ou la surcharge de méthodes est la possibilité de créer plusieurs fonctions du même nom avec différentes implémentations ( Wikipedia )

Qu'est-ce que la surcharge de fonctions dans JS?

Cette fonctionnalité n'est pas possible dans JS - la dernière fonction définie est prise en cas de déclarations multiples:

function foo(a1, a2) { return `${a1}, ${a2}` }
function foo(a1) { return `${a1}` } // replaces above `foo` declaration
foo(42, "foo") // "42"

... et en TS?

Les surcharges sont une construction à la compilation sans impact sur le runtime JS:

function foo(s: string): string // overload #1 of foo
function foo(s: string, n: number): number // overload #2 of foo
function foo(s: string, n?: number): string | number {/* ... */} // foo implementation

Une erreur d'implémentation en double est déclenchée si vous utilisez le code ci-dessus (plus sûr que JS). TS choisit la première surcharge de montage dans l'ordre descendant, de sorte que les surcharges sont triées du plus spécifique au plus large.

Surcharge de méthode dans TS: un exemple plus complexe

Les types de méthode de classe surchargés peuvent être utilisés de manière similaire pour surcharger les fonctions:

class LayerFactory {
    createFeatureLayer(a1: string, a2: number): string
    createFeatureLayer(a1: number, a2: boolean, a3: string): number
    createFeatureLayer(a1: string | number, a2: number | boolean, a3?: string)
        : number | string { /*... your implementation*/ }
}

const fact = new LayerFactory()
fact.createFeatureLayer("foo", 42) // string
fact.createFeatureLayer(3, true, "bar") // number

Les surcharges très différentes sont possibles, car l'implémentation de la fonction est compatible avec toutes les signatures de surcharge - imposées par le compilateur.

Plus d'infos:

• Échantillon de terrain de jeu
• À faire et à ne pas faire en cas de surcharge

Pour en savoir plus sur les autres, j'ai observé qu'au moins tel que manifesté par TypeScript compilé par WebPack pour Angular 2, vous obtenez tranquillement overWRITTEN au lieu de méthodes overLOADED.

myComponent {
  method(): { console.info("no args"); },
  method(arg): { console.info("with arg"); }
}

Appel:

myComponent.method()

semble exécuter la méthode avec des arguments, ignorant silencieusement la version sans argument, avec une sortie:

with arg

Surcharge de fonction en tapuscrit:

Selon Wikipedia, (et de nombreux livres de programmation), la définition de la surcharge de méthode / fonction est la suivante:

Dans certains langages de programmation, la surcharge de fonctions ou la surcharge de méthodes est la possibilité de créer plusieurs fonctions du même nom avec différentes implémentations . Les appels à une fonction surchargée exécuteront une implémentation spécifique de cette fonction appropriée au contexte de l'appel, permettant à un appel de fonction d'effectuer différentes tâches selon le contexte.

En tapuscrit, nous ne pouvons pas avoir différentes implémentations de la même fonction qui sont appelées en fonction du nombre et du type d'arguments. En effet, lorsque TS est compilé en JS, les fonctions de JS ont les caractéristiques suivantes:

• Les définitions de fonction JavaScript ne spécifient pas les types de données pour leurs paramètres
• Les fonctions JavaScript ne vérifient pas le nombre d'arguments lorsqu'elles sont appelées

Par conséquent, au sens strict, on pourrait affirmer que la surcharge de la fonction TS n'existe pas. Cependant, il y a des choses que vous pouvez faire dans votre code TS qui peuvent parfaitement imiter la surcharge de fonctions.

Voici un exemple:

function add(a: number, b: number, c: number): number;
function add(a: number, b: number): any;
function add(a: string, b: string): any;

function add(a: any, b: any, c?: any): any {
  if (c) {
    return a + c;
  }
  if (typeof a === 'string') {
    return `a is ${a}, b is ${b}`;
  } else {
    return a + b;
  }
}

Les documents TS appellent cette surcharge de méthode, et ce que nous avons essentiellement fait est de fournir plusieurs signatures de méthode (descriptions des paramètres et types possibles) au compilateur TS. Maintenant, TS peut déterminer si nous avons appelé notre fonction correctement pendant la compilation et nous donner une erreur si nous avons appelé la fonction de manière incorrecte.