ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 150
Numărul 149 Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 59
Abonament PDF

Șabloane uzuale de moștenire clasică în Javascript

Alexey Grinko
Front End Developer @ Crossover for Work



PROGRAMARE


Există o opinia că programarea front-end este mai puțin expusă modelelor și șabloanelor arhitecturale, cât mai degrabă o vânătoare de add-onuri cât mai stabile. De vreme ce aceasta este o abordare evident superficială, vom folosi acest articol pentru a arunca puțină lumină asupra moștenirii clasice în JavaScript, șabloanele lui uzuale, feature-uri și greșeli frecvente în aplicarea lor. Vom lua în considerare exemple de moștenire în Babel, Backbone JS și Ember JS, și vom încerca să derivăm principiile cheie ale moștenirii orientate-obiect pentru crearea implementării personalizate folosind EcmaScript 5.

Sub denumirea de "clasic", înțelegem moștenirea în stilul OOP. Este de notat faptul că nu există moștenire clasică în JavaScript pur. Mai mult, îi lipsește complet noțiunea de clase. Deși specificațiile recente de EcmaScript adaugă construcții sintactice pentru lucrul cu clase, aceasta nu schimbă faptul că la bază folosește de fapt funcții constructor și prototipare. În consecință, această tehnică este adesea denumită moștenire "pseudo-clasică". Urmărește, probabil, singurul scop - de a reprezenta cod într-un stil familiar OOP.

Există numeroase tehnici de moștenire, pe lângă cea clasică: funcțională, pur prototipală, structurală, folosind mixinuri. Adevăratul concept de moștenire, care a câștigat o largă popularitate printre programatori, este criticată și contrastată cu alternativă rezonabilă - compoziția. Deși moștenirea, mai ales în stilul clasic, nu este un panaceu. Utilitatea ei depinde de o situație concretă specifică proiectului. Oricum, în acest articol, nu vom intra în detaliile legate de avantajele și dezavantajele acestei abordări, ci mai degrabă ne vom concentra pe modalitățile corecte de aplicarea ei.

Așadar, am decis să folosim OOP și moștenirea clasică în limbajul pe care nu o permite în esență. Această soluție este adesea adoptată în proiecte de mari dimensiuni de către programatorii obișnuiți cu OOP în alte limbaje. Este de asemenea folosită în multe frameworkuri majore: Backbone JS, Ember JS, etc. , dar și în specificarea recentă a EcmaScript.

Cel mai bun sfat în utilizarea moștenirii ar fi să fie folosită conform descrierii din EcmaScript 6, prin cuvintele cheie class, extends, constructor, s.a.m.d. Dacă există o astfel de opțiune, este cea mai bună din punct de vedere al interpretării codului și a performanței. Toate descrierile care urmează vor fi utile pentru cazul specificațiilor vechi, atunci când proiectul a fost deja pornit conform ES5, iar tranziția spre noua versiune nu pare disponibilă.

Criteriile de evaluare

Iată câteva exemple populare de realizare a moștenirii clasice, pe care le analizăm prin următoarele cinci aspecte:

În primul rând, evident, trebuie să ne asigurăm că șablonul este eficient din punctul de vedere al performanței și eficienței memoriei. Din acest considerent, nu există cerințe speciale de la următoarele exemple din frameworkuri populare. Dar, în practică, adeseori apar exemple eronate care duc la memory leaks și saturarea stackului, pe care le vom discuta mai jos.

Celelalte criterii din listă sunt legate de utilizarea și lizibilitatea codului. Vor fi mai "utilizabile" implementările care sunt strâns legate ca sintaxă și funcționalitate de moștenirea clasică din alte limbaje. De exemplu, referința la clasa de bază (cuvântul cheie super) este opțional, dar prezența lui este de dorit pentru o emulare completă a moștenirii clasice. Prin "detalii cosmetice" înțelegem designul general al codului, ușurința operațiunii de depanare, utilizarea operatorului instanceof, s.a.m.d.

Funcția "_inherits" în Babel

Luăm în considerare moștenirea EcmaScript 6 și rezultatele pe care le obținem când compilăm codul în ES5 cu Babel. Observați mai jos un exemplu de extinderea clasei în ES6:

class BasicClass {
    static staticMethod() {}
    constructor(x) {
        this.x = x;
    }

    someMethod() {}
}

class DerivedClass extends BasicClass {
    static staticMethod() {}
    constructor(x) {
        super(x);
    }
    someMethod() {
        super.someMethod();
    }
}

Așa cum se poate observa, sintaxa este similar cu alte limbaje OOP, cu excepția tipurilor și a modificatorilor de acces. Aceasta este unicitatea utilizării ES6 cu compilator: ne putem permite sintaxa confortabilă și obținerea codului ES5 funcțional, în același timp. Niciunul din exemplele următoare nu se pot lăuda cu același nivel de simplitate sintactică, deoarece funcția de moștenire este gata creată, fără transformări de sintaxă.

Compilatorul Babel implementează moștenirea folosind o simplă funcție denumită _inherits:

function _inherits(subClass, superClass) {
  if (typeof superClass !== "function" 
    && superClass !== null) {
      throw new TypeError("Super expression must" + 
        "either be null or a function, not " 
        + typeof superClass);
  }
  subClass.prototype = Object.create(superClass 
    && superClass.prototype, {
      constructor: {

         value: subClass,
         enumerable: false,
         writable: true,
         configurable: true
       }
  });
  if (superClass) Object.setPrototypeOf 
     ? Object.setPrototypeOf(subClass, superClass) 
     : subClass.__proto__ = superClass;
}

Cheia, în acest caz, este utilizarea următoarei linii:

subClass.prototype = Object.create(superClass.prototype);

Acest apel creează un obiect cu prototipul specificat. Proprietatea prototype a constructorului subclass referă un obiect nou al cărui prototip este superclass.prototype. Prin urmare, aceasta este o moștenire prototipală simplă, deghizată ca o formă clasică a codului sursa.

Moștenirea câmpurilor statice se realizează cu ajutorul următoarei linii:

Object.setPrototypeOf
  ? Object.setPrototypeOf(subClass, superClass)
  : subClass.__proto__ = superClass;

Constructorul clasei de bază (i.e. funcției) este chiar prototipul constructorului noii clase (i.e. o altă funcție). În acest fel, toate funcțiile și proprietățile statice ale clasei de bază devin accesibile din sub-clasă. În absența setPrototypeOf, Babel asigură atribuirea directă a prototipului spre proprietatea ascunsă __proto__ - această metodă nu este recomandată, dar este potrivită pentru cazul marginal de utilizare a browserelor vechi.

Atribuirea metodelor, atât statice cât și dinamice, intervine separat, după apelarea _inherits prin simpla copiere a referințelor în constructor sau în propriul prototip. La scrierea implementării personalizate a moștenirii, putem folosi acest exemplu ca bază și să-i adăugăm obiecte cu proprietăți dinamice și statice ca parametri suplimentari.

Cuvântul cheie "super" este înlocuit în timpul compilării cu apelul direct al prototipului. De exemplu, invocarea super-constructorului din exemplul de mai sus este înlocuită cu următoarea linie:

return _possibleConstructorReturn(this
  , (DerivedClass.__proto__ 
    || Object.getPrototypeOf(DerivedClass))
    .call(this, x));

Babel folosește multe funcții ajutătoare despre care nu vom vorbi aici. Concluzia este că interpretorul primește prototipul constructorului clasei curente, care este însuși constructorul clasei de bază (vezi mai sus), și îl apelează cu contextul actual.

Într-o implementare personalizată cu ES5 pur, putem adăuga manual câmpul _super în constructor și prototip, pentru a beneficia de o referință inteligentă a clasei de bază, de exemplu:

function extend(subClass, superClass) {
    // ...
    subClass._super = superClass;
    subClass.prototype._super = superClass.prototype;
}

Funcția "extend" în Backbone JS

Backbone JS oferă funcția extend pentru extinderea claselor librăriei: Model, View, Collection, etc. Dacă se dorește, poate fi împrumutată propriilor scopuri. Puteți vedea mai jos codul funcției extend din Backbone JS versiunea 1.3.3.

var extend = function(protoProps, staticProps) {
  var parent = this;
  var child;
  // The constructor function for the new subclass 
  // is either defined by you
  // (the "constructor" property in your `extend` 
  // definition), or defaulted
  // by us to simply call the parent constructor.

  if (protoProps && _.has(protoProps,'constructor')){
    child = protoProps.constructor;
  } else {
    child = function(){ return parent.apply(this,
     arguments); };
  }

  // Add static properties to the constructor 
  // function, if supplied.

  _.extend(child, parent, staticProps);
  // Set the prototype chain to inherit from 
  // `parent`, without calling
  // `parent`'s constructor function and add 
  // the prototype properties.

  child.prototype = _.create(parent.prototype, 
    protoProps);

  child.prototype.constructor = child;
  // Set a convenience property in case the parent's  
  // prototype is needed later.

  child.__super__ = parent.prototype;

  return child;
}
;

Un exemplu de utilizare arată după cum urmează:

var MyModel = Backbone.Model.extend({
  constructor: function() {
  // your constructor; its usage is optional,
  // but when used it requires the super-constructor 
  // to be called:

    Backbone.Model.apply(this, arguments);
    },
    toJSON: function() {

  // the method is overridden, but the original 
  // method can be called via "__super_"

   MyModel.__super__.toJSON.apply(this, arguments);
  }
}, {
    staticMethod: function() {}
});

Această funcție implementează extensia clasei de bază susținând propriul constructor și propriile câmpuri statice. Ea returnează funcția constructor a clasei. Adevărata moștenire se realizează folosind următoarea linie, similară exemplului din Babel:

child.prototype = _.create(parent.prototype, 
  protoProps);

Funcția _.create() este similară cu Object.create() din ES6, dar implementată de librăria Underscore JS. Cel de-al doilea parametru permite scrierea de proprietăți și metode protoProps, primite la apelul extend, imediat după prototip.

Moștenirea câmpurilor statice este implementată prin simpla copiere a referințelor (sau a valorilor) din clasa de bază și din obiectul cu câmpuri statice primit ca parametru secundar al funcției extend:

_.extend(child, parent, staticProps);

Specificarea constructorului este opțională. Se realizează înăuntrul declarației clasei sub forma de funcție "constructor". Când folosim constructori, este obligatoriu să apelăm constructorul clasei de bază (exact ca în alte limbaje), deci programatorii obișnuiesc să folosească funcția initialize() în schimb.

Cuvântul cheie __super__ este doar o adăugare convenabilă, deoarece apelul spre funcția de bază încă mai are loc prin numele funcției respective și prin transmiterea contextului this. Fără aceasta, un astfel de apel ar conduce la un ciclu în cazul unui lanț de moștenire multi-nivel. Funcția clasei de bază, al cărei nume este cunoscut de obicei în contextul curent, poate fi apelat direct, deci cuvântul cheie this este doar o scurtătură:

Backbone.Model.prototype.toJSON.apply(this,arguments);

Din punctul de vedere al codului, extensia claselor în Backbone este destul de clară. Nu trebuie creați manual constructorii de clasă și asociați cu clasa părinte pe o linie diferită. Acest confort are prețul lui - dificultatea depanării. În debuggerul browserului, toate instanțele de clase moștenite în acest fel au același nume de constructor declarat în funcția extend - "copil". Acest dezavantaj poate părea nesemnificativ până când îl întâlnești în practică, atunci când depanezi un lanț de clase. Devine dificil de înțeles ce clasă instanțiază un anumit obiect și ce clasă derivează. Aveți aici un exemplu din consola Google Chrome:

Mult mai convenabil pare acest lanț când folosim moștenirea din Babel:

O altă carență este faptul că proprietatea constructor este un enumerabil, i.e. listată la parcurgerea unei instanțe de clasă într-un ciclu "for-in". Este irelevant, dar Babel are grijă și de aceasta, declarând constructorul cu lista de modificatori necesară. Nu face nicio diferență, dar Babel a ținut cont și de el, listând toți modificatorii necesari pentru declararea constructorului.

Referențierea clasei de bază în Ember JS

Ember JS folosește atât funcția inherits implementată de Babel, cât și propria implementare de extend - una foarte complicată și încărcată, care suportă mixinuri, etc.. Pur și simplu nu este suficient spațiu în acest articol pentru a-i prezenta tot codul aici. Și exact acest fapt deja ridică întrebări legate de performanța acestei implementări, atunci când cineva vrea să-l folosească pentru propriile scopuri, în afara frameworkului.

Este de un interes aparte implementarea cuvântului cheie "super" în Ember. El permite apelarea unei funcții de bază fără specificarea concretă a numelui metodei, de exemplu:

var MyClass = MySuperClass.extend({
    myMethod: function (x) {
        this._super(x);
    }
});

Cum funcționează aceasta? Cum știe Ember ce funcție să invoce când apelează versatila funcție _super, fără să transforme codul? Secretul este în procesarea complexă a claselor și o funcție inteligentă _wrap, al cărei cod îl afișăm mai jos:

function _wrap(func, superFunc) {
  function superWrapper() {
    var orig = this._super;
    this._super = superFunc; // the magic is here
    var ret = func.apply(this, arguments);
    this._super = orig;
    return ret;
  }
  // some irrelevant piece of code is omitted here

  return superWrapper;
}

Când derivăm o clasă, Ember parcurge toate funcțiile și invocă acest wrapper pentru fiecare. El înlocuiește fiecare funcție originală cu superWrapper. Fiți atenți la linia marcată prin comentariu. Proprietatea _super conține acum o referință la funcția părinte corespunzătoare numelui de metodă care este apelată (toată activitatea de determinare a corespondențelor a apărut în timpul creării clasei prin apelarea extend). Pe linia următoare se apelează funcția originală, din interiorul căreia se poate invoca _super ca funcție părinte. Proprietatea _super este atunci resetată înapoi la valoarea ei inițială. Aceasta permite să fie folosită în apeluri profund înlănțuite.

Ideea este fără dubiu, interesantă și poate fi aplicată într-o implementare personalizată de moștenire. Dar există un avertisment important: complexitatea acestei funcții îi afectează performanța. Fiecare metodă a clasei (cel puțin printre cele care au metode părinte omonime), indiferent dacă metoda _super este folosită sau nu, este împachetată într-o funcție separată. Cu o profunzime mare a lanțului de apeluri ale metodelor aceleiași clase, ne conduce la o explozie a stackului. Aceasta este cu atât mai crucial pentru metodele care sunt apelate regulat într-un ciclu sau la afișarea UI-ului. Deci, putem spune că această implementare este prea împovărătoare și nu justifică avantajul sub forma notației abreviate.

Cea mai frecventă greșeală

Una dintre cele mai frecvente și periculoase greșeli în practică este crearea unei instanțe a clasei părinte în timpul extinderii ei. Aveți mai jos un astfel de exemplu de cod care ar trebui evitat întotdeauna:

function BasicClass() {
    this.x = this.initializeX();
    this.runSomeBulkyCode();
}
// ...declaration of BasicClass methods 
// in prototype...

function SubClass() {
    BasicClass.apply(this, arguments);
    this.y = this.initializeY();
}

// the inheritance
SubClass.prototype = new BasicClass();
SubClass.prototype.constructor = SubClass;

// ...declaration of SubClass methods in prototype...

new SubClass(); // instantiating

Acest cod ar trebui să funcționeze. El va permite SubClass să deriveze proprietăți și metode ale clasei părinte. Dar asociind clasele prin prototype, s-a creat o instanță a clasei părinte, iar constructorul ei este invocat. Aceasta conduce la alte acțiuni, în special dacă funcția constructor execută multă activitate în timp ce inițializează un obiect (runSomeBulkyCode). Aceasta ar putea de asemenea să conducă la erori greu de detectat atunci când proprietățile inițializate în constructorul părinte (this.x) sunt scrise în prototipul tuturor instanțelor clasei SubClass în locul instanțelor înseși. Mai mult, același constructor BasicClass este apelat din nou din constructorul sub-clasei.

În cazul în care constructorul părinte necesită anumiți parametri atunci când este apelată, această greșeală este greu de realizat, dar altfel este extrem de probabilă.

În schimb, un obiect gol ar trebui creat de fiecare dată și al cărui prototip este proprietatea prototype a clasei părinte:

SubClass.prototype = Object.create(
  BasicClass.prototype);

Concluzii

Am oferit câteva exemple de implementare de moștenire pseudo-clasică în compilatorul Babel (din ES6 spre ES5) și în frameworkuri cum ar fi Backbone JS și Ember JS. Aveți mai jos un tabel comparativ al tuturor celor trei implementări structurate după criteriul descris mai sus. Performanța a fost evaluată nu în unități absolute, ci în valori relative între ele, în baza unui număr de operațiuni și cicluri în fiecare exemplu. În general, diferența de performanță nu este semnificativă, deoarece moștenirea se aplică o singură dată la nivelul inițial al aplicației și nu se mai repetă.

Toate exemplele de mai sus au propriile argumente pro și contra, dar cel mai practic poate fi considerat implementarea folosind Babel. Așa cum am menționat mai sus, dacă este posibil, ar trebui folosită moștenirea specificată în EcmaScript 6 cu compilarea în ES5. În absența unei asemenea oportunități, se recomandă scrierea unei implementări personalizate a funcției extend, bazată pe exemplul din compilatorul Babel, luând în considerare remarcile de mai sus și feature-urile din alte exemple. Prin urmare, moștenirea poate fi implementată în cel mai flexibil și potrivit mod pentru orice proiect specific.

- utilizarea Babel este perfectă când se combină cu ES6; la scrierea unei implementări personalizate pentru ES5 pornind de la aceasta, câmpurile statice și referința la clasa de bază ar trebui implementată manual.

References

  1. JavaScript.ru

  2. David Shariff. JavaScript Inheritance Patterns

  3. Eric Elliott. 3 Different Kinds of Prototypal Inheritance: ES6+ Edition.

  4. Wikipedia - Composition over inheritance

  5. Mozilla Developer Network

  6. Babel (source code)

  7. Backbone JS (source code)

  8. Ember JS (source code)

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects