Quelle est la manière standard d'appeler des méthodes statiques? Je peux penser à utiliser constructorou utiliser le nom de la classe elle-même, je n'aime pas ce dernier car cela ne me semble pas nécessaire. La première méthode est-elle recommandée ou y a-t-il autre chose?

Voici un exemple (artificiel):

class SomeObject {
  constructor(n){
    this.n = n;
  }

  static print(n){
    console.log(n);
  }

  printN(){
    this.constructor.print(this.n);
  }
}

Les deux méthodes sont viables, mais elles font des choses différentes lorsqu'il s'agit d'héritage avec une méthode statique remplacée. Choisissez celui dont vous attendez le comportement:

class Super {
  static whoami() {
    return "Super";
  }
  lognameA() {
    console.log(Super.whoami());
  }
  lognameB() {
    console.log(this.constructor.whoami());
  }
}
class Sub extends Super {
  static whoami() {
    return "Sub";
  }
}
new Sub().lognameA(); // Super
new Sub().lognameB(); // Sub

Faire référence à la propriété static via la classe sera en fait statique et donnera constamment la même valeur. Utiliser à la this.constructorplace utilisera la répartition dynamique et fera référence à la classe de l'instance actuelle, où la propriété statique peut avoir la valeur héritée mais peut également être remplacée.

Cela correspond au comportement de Python, où vous pouvez choisir de faire référence à des propriétés statiques via le nom de la classe ou l'instance self.

Si vous vous attendez à ce que les propriétés statiques ne soient pas remplacées (et faites toujours référence à celle de la classe actuelle), comme en Java , utilisez la référence explicite.

Je suis tombé sur ce fil à la recherche d'une réponse à un cas similaire. En gros, toutes les réponses sont trouvées, mais il est encore difficile d'en extraire l'essentiel.

Types d'accès

Supposons qu'une classe Foo soit probablement dérivée d'une ou plusieurs autres classes avec probablement plus de classes dérivées.

Puis accéder

• à partir de la méthode statique / getter de Foo
  • une méthode statique / getter probablement surchargée :
    • this.method()
    • this.property
  • une méthode d' instance / getter probablement surchargée :
    • impossible par conception
  • propre méthode statique / getter non surchargée:
    • Foo.method()
    • Foo.property
  • propre méthode / getter d' instance non surchargée:
    • impossible par conception
• à partir de la méthode d' instance / getter de Foo
  • une méthode statique / getter probablement surchargée :
    • this.constructor.method()
    • this.constructor.property
  • une méthode d' instance / getter probablement surchargée :
    • this.method()
    • this.property
  • propre méthode statique / getter non surchargée:
    • Foo.method()
    • Foo.property
  • propre méthode / getter d' instance non surchargée:
    • pas possible par intention à moins d'utiliser une solution de contournement :
      • Foo.prototype.method.call( this )
      • Object.getOwnPropertyDescriptor( Foo.prototype,"property" ).get.call(this);

Gardez à l'esprit que l'utilisation thisne fonctionne pas de cette façon lors de l'utilisation de fonctions fléchées ou de l'appel de méthodes / accesseurs explicitement liés à une valeur personnalisée.

Contexte

• Dans le contexte de la méthode ou du getter d'une instance
  • this fait référence à l'instance actuelle.
  • super fait essentiellement référence à la même instance, mais un peu les méthodes d'adressage et les getters écrits dans le contexte d'une classe actuelle s'étend (en utilisant le prototype du prototype de Foo).
  • la définition de la classe de l'instance utilisée lors de sa création est disponible par this.constructor.
• Lorsque dans le contexte d'une méthode statique ou d'un getter, il n'y a pas d '"instance actuelle" par intention et donc
  • this est disponible pour se référer directement à la définition de la classe courante.
  • super ne fait pas non plus référence à une instance, mais à des méthodes statiques et des getters écrits dans le contexte d'une classe actuelle.

Conclusion

Essayez ce code:

class A {
  constructor( input ) {
    this.loose = this.constructor.getResult( input );
    this.tight = A.getResult( input );
    console.log( this.scaledProperty, Object.getOwnPropertyDescriptor( A.prototype, "scaledProperty" ).get.call( this ) );
  }

  get scaledProperty() {
    return parseInt( this.loose ) * 100;
  }
  
  static getResult( input ) {
    return input * this.scale;
  }
  
  static get scale() {
    return 2;
  }
}

class B extends A {
  constructor( input ) {
    super( input );
    this.tight = B.getResult( input ) + " (of B)";
  }
  
  get scaledProperty() {
    return parseInt( this.loose ) * 10000;
  }

  static get scale() {
    return 4;
  }
}

class C extends B {
  constructor( input ) {
    super( input );
  }
  
  static get scale() {
    return 5;
  }
}

class D extends C {
  constructor( input ) {
    super( input );
  }
  
  static getResult( input ) {
    return super.getResult( input ) + " (overridden)";
  }
  
  static get scale() {
    return 10;
  }
}


let instanceA = new A( 4 );
console.log( "A.loose", instanceA.loose );
console.log( "A.tight", instanceA.tight );

let instanceB = new B( 4 );
console.log( "B.loose", instanceB.loose );
console.log( "B.tight", instanceB.tight );

let instanceC = new C( 4 );
console.log( "C.loose", instanceC.loose );
console.log( "C.tight", instanceC.tight );

let instanceD = new D( 4 );
console.log( "D.loose", instanceD.loose );
console.log( "D.tight", instanceD.tight );

Si vous prévoyez de faire n'importe quel type d'héritage, je vous le recommande this.constructor. Cet exemple simple devrait illustrer pourquoi:

class ConstructorSuper {
  constructor(n){
    this.n = n;
  }

  static print(n){
    console.log(this.name, n);
  }

  callPrint(){
    this.constructor.print(this.n);
  }
}

class ConstructorSub extends ConstructorSuper {
  constructor(n){
    this.n = n;
  }
}

let test1 = new ConstructorSuper("Hello ConstructorSuper!");
console.log(test1.callPrint());

let test2 = new ConstructorSub("Hello ConstructorSub!");
console.log(test2.callPrint());

• test1.callPrint()se connectera ConstructorSuper Hello ConstructorSuper!à la console
• test2.callPrint()se connectera ConstructorSub Hello ConstructorSub!à la console

La classe nommée ne traitera pas correctement l'héritage à moins que vous ne redéfinissiez explicitement chaque fonction qui fait une référence à la classe nommée. Voici un exemple:

class NamedSuper {
  constructor(n){
    this.n = n;
  }

  static print(n){
    console.log(NamedSuper.name, n);
  }

  callPrint(){
    NamedSuper.print(this.n);
  }
}

class NamedSub extends NamedSuper {
  constructor(n){
    this.n = n;
  }
}

let test3 = new NamedSuper("Hello NamedSuper!");
console.log(test3.callPrint());

let test4 = new NamedSub("Hello NamedSub!");
console.log(test4.callPrint());

• test3.callPrint()se connectera NamedSuper Hello NamedSuper!à la console
• test4.callPrint()se connectera NamedSuper Hello NamedSub!à la console

Voir tout ce qui précède en cours d'exécution dans Babel REPL .

Vous pouvez voir de cela qui test4pense toujours que c'est dans la super classe; dans cet exemple, cela peut ne pas sembler un gros problème, mais si vous essayez de référencer des fonctions membres qui ont été remplacées ou de nouvelles variables membres, vous vous retrouverez en difficulté.