Czym właściwie dziedziczenie prototypowe różni się od dziedziczenia klasycznego?

Dziedziczenie, polimorfizm i enkapsulacja to trzy najbardziej wyraźne, ważne cechy OOP, a od nich dziedziczenie ma obecnie wysoką statystykę użytkowania. Uczę się JavaScript, a tutaj wszyscy mówią, że ma on dziedzictwo prototypowe, a ludzie na całym świecie mówią, że jest to coś zupełnie innego niż klasyczne dziedzictwo.

Nie rozumiem jednak, jaka jest ich różnica z praktycznego punktu widzenia? Innymi słowy, kiedy zdefiniujesz klasę bazową (prototyp), a następnie wyprowadzisz z niej niektóre podklasy, oboje masz dostęp do funkcjonalności swojej klasy bazowej i możesz rozszerzyć funkcje na klasy pochodne. Jeśli weźmiemy pod uwagę to, co powiedziałem, jako zamierzony wynik dziedziczenia, to dlaczego powinniśmy się przejmować, jeśli używamy wersji prototypowej lub klasycznej?

Aby wyjaśnić siebie bardziej, nie widzę różnicy w zakresie użyteczności i wzorców użytkowania prototypowego i klasycznego dziedziczenia. Powoduje to, że nie jestem zainteresowany dowiedzeniem się, dlaczego się różnią, ponieważ oba skutkują tym samym, OOAD. Czym praktycznie (nie teoretycznie) dziedziczenie prototypowe różni się od dziedziczenia klasycznego?

Ostatni post na blogu o JS OO

Uważam, że porównujesz klasyczną emulację OO w JavaScript i klasyczną OO i oczywiście nie widać żadnej różnicy.

Zastrzeżenie: zamień wszystkie odniesienia do „prototypowego OO” na „prototypowy OO w JavaScript”. Nie znam specyfiki Self ani żadnej innej implementacji.

Jednak prototypowy OO jest inny. Dzięki prototypom masz tylko obiekty i możesz tylko wstrzykiwać obiekty do łańcucha prototypów innych obiektów. Ilekroć uzyskujesz dostęp do właściwości obiektu, przeszukujesz ten obiekt i dowolne obiekty w łańcuchu prototypów.

W przypadku prototypowego OO nie ma pojęcia enkapsulacji. Hermetyzacja jest cechą zakresu, zamknięć i funkcji pierwszej klasy, ale nie ma nic wspólnego z prototypowym OO. Nie ma też pojęcia dziedziczenia, to, co ludzie nazywają „dziedziczeniem”, jest po prostu polimorfizmem.

Ma jednak polimorfizm.

Na przykład

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

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

Wyraźnie dma dostęp do tej metody Dog.walki wykazuje polimorfizm.

Tak naprawdę jest duża różnica . Masz tylko polimorfizm.

Jak jednak wspomniano, jeśli chcesz to zrobić (nie mam pojęcia, dlaczego), możesz emulować klasyczne OO w JavaScript i mieć dostęp do (ograniczonej) enkapsulacji i dziedziczenia.

Dziedziczenie klasyczne dziedziczy zachowanie, bez żadnego stanu, od klasy nadrzędnej. Dziedziczy zachowanie w momencie tworzenia instancji obiektu.

Dziedziczenie prototypowe dziedziczy zachowanie i stan z obiektu nadrzędnego. Dziedziczy zachowanie i stan w momencie wywołania obiektu. Gdy obiekt nadrzędny zmienia się w czasie wykonywania, wpływa to na stan i zachowanie obiektów potomnych.

„Zaletą” dziedziczenia prototypowego jest to, że można „załatać” stan i zachowanie po utworzeniu instancji wszystkich obiektów. Na przykład w frameworku Ext JS często ładuje się „przesłonięcia”, które łatają główne komponenty frameworku po utworzeniu instancji frameworka.

Po pierwsze: przez większość czasu będziesz używać obiektów, a nie ich definiować, a używanie obiektów jest takie samo w obu paradygmatach.

Po drugie: Większość środowisk prototypowych używa tego samego rodzaju podziału co środowiska klasowe - zmienne dane instancji z odziedziczonymi metodami. Więc znów jest bardzo mała różnica. (Zobacz moją odpowiedź na to pytanie o przepełnienie stosu oraz programy samoorganizacji bez klas . Zajrzyj do Citeseer, aby uzyskać wersję PDF .)

Po trzecie: Dynamiczna natura Javascript ma znacznie większy wpływ niż dziedziczenie. Fakt, że mogę dodać nową metodę do wszystkich instancji typu, przypisując ją do obiektu podstawowego, jest zgrabny, ale mogę zrobić to samo w Ruby, ponownie otwierając klasę.

Po czwarte: Praktyczne różnice są niewielkie, podczas gdy praktyczna kwestia zapominania o użyciu newjest znacznie większa - to znaczy, że znacznie bardziej prawdopodobne jest, że będziesz odczuwać brakujące newniż różnicę między kodem prototypowym a klasycznym .

Wszystko, co powiedziano, praktyczną różnicą między dziedziczeniem prototypowym a klasycznym jest to, że twoje rzeczy, które przechowują metody (klasy) są takie same, jak twoje rzeczy, które przechowują dane (instancje). Oznacza to, że możesz budować swoje klasy fragmentarycznie, przy użyciu tych samych narzędzi do manipulacji obiektami, których można użyć w dowolnej instancji. (Tak właśnie robią wszystkie biblioteki emulujące klasy. Aby uzyskać podejście nie do końca podobne do innych, zajrzyj na Traits.js ). Jest to szczególnie interesujące w przypadku metaprogramowania.

Dziedziczenie prototypowe w JavaScript różni się od klas pod następującymi ważnymi względami:

Konstruktory to po prostu funkcje, które można wywoływać bez 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.

Nie ma prywatnych zmiennych ani metod, w najlepszym wypadku możesz to zrobić:

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!
}

W poprzednim przykładzie nie można znacząco rozszerzyć klasy, jeśli uciekamy się do fałszywych zmiennych prywatnych i metod, a ponadto wszelkie zadeklarowane metody publiczne będą odtwarzane przy każdym utworzeniu nowej instancji.