In che modo l'eredità prototipale è praticamente diversa dall'eredità classica?

Ereditarietà, polimorfismo ed incapsulamento sono le tre caratteristiche più distinte e importanti di OOP, e da esse l'ereditarietà ha oggi statistiche di utilizzo elevato. Sto imparando JavaScript, e qui, tutti dicono che ha un'eredità prototipale, e le persone ovunque dicono che è qualcosa di molto diverso dall'eredità classica.

Tuttavia, non riesco a capire qual è la loro differenza dal punto di vista pratico? In altre parole, quando si definisce una classe base (prototipo) e quindi ne derivano alcune sottoclassi, entrambi si ha accesso alle funzionalità della propria classe base e si possono aumentare le funzioni sulle classi derivate. Se consideriamo quello che ho detto essere il risultato previsto dell'ereditarietà, allora perché dovremmo preoccuparci se stiamo usando la versione prototipo o classica?

Per chiarirmi di più, non vedo alcuna differenza nell'utilità e negli schemi di utilizzo dell'eredità prototipale e classica. Ciò non ha alcun interesse a scoprire perché sono diversi, poiché entrambi danno come risultato la stessa cosa, OOAD. In che modo l'eredità prototipale praticamente (non teoricamente) è diversa dall'eredità classica?

Post di blog recenti su JS OO

Credo che il tuo confronto sia l'emulazione OO classica in JavaScript e OO classica e ovviamente non puoi vedere alcuna differenza.

Dichiarazione di non responsabilità: sostituire tutti i riferimenti a "prototipo OO" con "prototipo OO in JavaScript". Non conosco i dettagli del Sé o di qualsiasi altra implementazione.

Tuttavia, il prototipo di OO è diverso. Con i prototipi hai solo oggetti e puoi iniettare oggetti solo nella catena di prototipi di altri oggetti. Ogni volta che si accede a una proprietà su un oggetto, si cerca quell'oggetto e tutti gli oggetti nella catena del prototipo.

Per OO prototipo non esiste una nozione di incapsulamento. L'incapsulamento è una caratteristica di ambito, chiusure e funzioni di prima classe, ma non ha nulla a che fare con il prototipo di OO. Inoltre, non esiste alcuna nozione di eredità, ciò che la gente chiama "eredità" è in realtà solo polimorfismo.

Tuttavia ha polimorfismo.

Per esempio

var Dog = {
  walk: function() { console.log("walks"); }
}

var d = Object.create(Dog);
d.walk();

Chiaramente dha accesso al metodo Dog.walke questo mostra polimorfismo.

Quindi in realtà c'è una grande differenza . Hai solo polimorfismo.

Tuttavia, come accennato, se lo desideri (non ho idea del perché lo faresti) puoi emulare OO classico in JavaScript e avere accesso all'incapsulamento e all'eredità (limitati).

L'eredità classica eredita il comportamento, senza alcuno stato, dalla classe genitore. Eredita il comportamento nel momento in cui l'oggetto viene istanziato.

L'eredità prototipica eredita il comportamento e lo stato dall'oggetto genitore. Eredita il comportamento e lo stato nel momento in cui viene chiamato l'oggetto. Quando l'oggetto genitore cambia in fase di esecuzione, lo stato e il comportamento degli oggetti figlio sono interessati.

Il "vantaggio" dell'eredità prototipica è che è possibile "patchare" lo stato e il comportamento dopo che tutti gli oggetti sono stati istanziati. Ad esempio, nel framework Ext JS è comune caricare "sostituzioni" che correggono i componenti principali del framework dopo che il framework è stato istanziato.

Primo: la maggior parte delle volte, userete oggetti, non definirli, e usare oggetti è lo stesso in entrambi i paradigmi.

Secondo: la maggior parte degli ambienti prototipo usa lo stesso tipo di divisione degli ambienti basati su classi: dati mutabili sull'istanza, con metodi ereditati. Quindi c'è ancora poca differenza. (Vedi la mia risposta a questa domanda di overflow dello stack e i programmi di auto- organizzazione senza classi . Guarda Citeseer per una versione PDF .)

Terzo: la natura dinamica di Javascript ha un'influenza molto maggiore rispetto al tipo di eredità. Il fatto di poter aggiungere un nuovo metodo a tutte le istanze di un tipo assegnandolo all'oggetto base è chiaro, ma posso fare la stessa cosa in Ruby, riaprendo la classe.

Quarto: le differenze pratiche sono minime, mentre il problema pratico dell'oblio newè molto più grande - vale a dire, è molto più probabile che tu sia influenzato dalla mancanza di newquanto tu sia influenzato dalla differenza tra il prototipo e il codice classico .

Detto questo, la differenza pratica tra eredità prototipica e classica è che i tuoi metodi cose-che-tengono (classi) sono gli stessi dei tuoi dati cose-che-tengono (istanze). Ciò significa che puoi costruire le tue classi frammentario, utilizzando tutti gli stessi strumenti di manipolazione di oggetti che utilizzeresti su qualsiasi istanza. (Questo è, in effetti, il modo in cui tutte le librerie di emulazione di classe lo fanno. Per un approccio non proprio come tutti gli altri, guarda Traits.js ). Questo è interessante soprattutto se stai metaprogrammando.

L'eredità prototipale in JavaScript è diversa dalle classi in questi importanti modi:

I costruttori sono semplicemente funzioni che puoi chiamare senza new:

function Circle (r, x, y) { 
  //stuff here
}
Var c = new Circle();
Circle.call(c, x, y, z); //This works and you can do it over and over again.

Non ci sono variabili o metodi privati, nella migliore delle ipotesi puoi farlo:

function Circle (r, x, y) {
  var color = 'red';
  function drawCircle () {
    //some code here with x, y and r
  }
  drawCircle();
  this.setX = function (x_) {
    x = x_;
    drawCircle();
  }

}
Circle.prototype.getX = function () {
   //Can't access x!
}

Nell'esempio precedente non è possibile estendere in modo significativo la classe se si ricorre a variabili e metodi privati ​​falsi e inoltre qualsiasi metodo pubblico dichiarato verrà ricreato ogni volta che viene creata una nuova istanza.