dziedziczenie prototypowe vs. klasowe

W JavaScript każdy obiekt jest jednocześnie instancją i klasą. Aby wykonać dziedziczenie, możesz użyć dowolnej instancji obiektu jako prototypu.

W Pythonie, C ++ itp. Istnieją klasy i instancje jako osobne pojęcia. Aby wykonać dziedziczenie, musisz użyć klasy podstawowej, aby utworzyć nową klasę, której można następnie użyć do utworzenia instancji pochodnych.

Dlaczego JavaScript poszedł w tym kierunku (orientacja obiektowa oparta na prototypach)? jakie są zalety (i wady) OO opartego na prototypach w porównaniu z tradycyjnym OO opartym na klasach?

Jest tu około stu zagadnień terminologicznych, głównie wokół kogoś (nie ciebie), który stara się, aby ich pomysł brzmiał jak najlepszy.

Wszystkie języki obiektowe muszą być w stanie poradzić sobie z kilkoma pojęciami:

1. enkapsulacja danych wraz z powiązanymi operacjami na danych, zwanymi między innymi elementami danych i funkcjami elementów, lub jako dane i metody.
2. Dziedziczenie, możliwość stwierdzenia, że ​​te obiekty są takie same, jak inny zestaw obiektów Z WYJĄTKIEM tych zmian
3. polimorfizm („wiele kształtów”), w którym obiekt sam decyduje, jakie metody mają zostać uruchomione, dzięki czemu można polegać na języku, aby poprawnie kierować żądania.

Teraz, jeśli chodzi o porównanie:

Pierwszą rzeczą jest całe pytanie „klasa” kontra „prototyp”. Pomysł pierwotnie rozpoczął się w Simula, gdzie za pomocą metody opartej na klasach każda klasa reprezentowała zestaw obiektów, które dzieliły tę samą przestrzeń stanu (czytaj „możliwe wartości”) i te same operacje, tworząc w ten sposób klasę równoważności. Jeśli spojrzysz wstecz na Smalltalk, ponieważ możesz otworzyć klasę i dodać metody, jest to faktycznie to samo, co możesz zrobić w JavaScript.

Później języki OO chciały mieć możliwość statycznego sprawdzania typów, więc otrzymaliśmy pojęcie ustalonego zestawu klas w czasie kompilacji. W wersji otwartej miałeś większą elastyczność; w nowszej wersji można było sprawdzić niektóre rodzaje poprawności w kompilatorze, które w innym przypadku wymagałyby testowania.

W języku „klasowym” kopiowanie odbywa się w czasie kompilacji. W języku prototypowym operacje są przechowywane w prototypowej strukturze danych, która jest kopiowana i modyfikowana w czasie wykonywania. Jednak abstrakcyjnie klasa jest nadal klasą równoważności wszystkich obiektów, które mają tę samą przestrzeń stanu i metody. Dodając metodę do prototypu, skutecznie tworzysz element nowej klasy równoważności.

Dlaczego to robisz? przede wszystkim dlatego, że tworzy prosty, logiczny i elegancki mechanizm w czasie wykonywania. teraz, aby utworzyć nowy obiekt lub nową klasę, wystarczy wykonać głęboką kopię, kopiując wszystkie dane i prototypową strukturę danych. Otrzymujesz dziedziczenie i polimorfizm mniej więcej za darmo: wyszukiwanie metody zawsze polega na pytaniu słownika o implementację metody według nazwy.

Powodem, dla którego skończyło się skryptem JavaScript / ECMA, jest to, że kiedy zaczynaliśmy 10 lat temu, mieliśmy do czynienia ze znacznie słabszymi komputerami i znacznie mniej zaawansowanymi przeglądarkami. Wybór metody opartej na prototypach oznaczał, że interpreter może być bardzo prosty, zachowując pożądane właściwości orientacji obiektowej.

Porównanie, które jest nieco tendencyjne w stosunku do podejścia opartego na prototypach, można znaleźć w artykule Self: The Power of Simplicity . Artykuł przedstawia następujące argumenty za prototypami:

Tworzenie przez kopiowanie . Tworzenie nowych obiektów z prototypów odbywa się poprzez prostą operację, kopiowanie, przy użyciu prostej metafory biologicznej, klonowanie. Tworzenie nowych obiektów z klas odbywa się przez tworzenie instancji, które obejmuje interpretację informacji o formacie w klasie. Tworzenie instancji jest podobne do budowania domu z planu. Kopiowanie odwołuje się do nas jako prostsza metafora niż tworzenie.

Przykłady istniejących modułów . Prototypy są bardziej konkretne niż klasy, ponieważ są to przykłady obiektów, a nie opisy formatu i inicjalizacji. Te przykłady mogą pomóc użytkownikom w ponownym użyciu modułów, ułatwiając ich zrozumienie. System oparty na prototypach pozwala użytkownikowi zbadać typowego przedstawiciela, zamiast wymagać od niego sensownego opisu.

Obsługa jedynych w swoim rodzaju obiektów . Self zapewnia platformę, która z łatwością może zawierać jedyne w swoim rodzaju obiekty z własnym zachowaniem. Ponieważ każdy obiekt ma nazwane gniazda, a gniazda mogą zawierać stan lub zachowanie, każdy obiekt może mieć unikalne gniazda lub zachowanie. Systemy oparte na klasach są zaprojektowane do sytuacji, w których istnieje wiele obiektów o takim samym zachowaniu. Nie ma wsparcia językowego, aby obiekt posiadał własne unikalne zachowanie, i niewygodne jest stworzenie klasy, która ma zagwarantowaną tylko jedną instancję [ pomyśl singleton wzorzec ]. Jaźń nie cierpi na żadną z tych wad. Każdy obiekt można dostosować za pomocą własnego zachowania. Unikalny obiekt może przechowywać unikalne zachowanie i osobna „instancja” nie jest potrzebna.

Eliminacja meta-regresji . Żaden obiekt w systemie klasowym nie może być samowystarczalny; inny obiekt (jego klasa) jest potrzebny do wyrażenia jego struktury i zachowania. Prowadzi to do konceptualnie nieskończonej meta-regresji: a pointjest instancją klasy Point, która jest instancją metaklasy Point, która jest instancją metametaklasy Point, ad infinitum. Z drugiej strony w systemach opartych na prototypach obiekt może zawierać własne zachowanie; żaden inny przedmiot nie jest potrzebny, aby tchnąć w nie życie. Prototypy eliminują meta-regres.

Self jest prawdopodobnie pierwszym językiem do implementacji prototypów (był także pionierem innych interesujących technologii, takich jak JIT, które później trafiły do ​​JVM), więc czytanie innych dokumentów Self powinno być również pouczające.

Powinieneś sprawdzić świetną książkę o JavaScript autorstwa Douglasa Crockforda . Zapewnia bardzo dobre wyjaśnienie niektórych decyzji projektowych podjętych przez twórców JavaScript.

Jednym z ważnych aspektów projektowania JavaScript jest prototypowy system dziedziczenia. Obiekty są pierwszorzędnymi obywatelami JavaScript, do tego stopnia, że ​​zwykłe funkcje są również implementowane jako obiekty (a dokładniej obiekt „Funkcja”). Moim zdaniem, kiedy pierwotnie został zaprojektowany do działania w przeglądarce, miał służyć do tworzenia wielu obiektów singletonowych. W przeglądarce DOM znajdziesz to okno, dokument itp. Wszystkie pojedyncze obiekty. JavaScript to także dynamiczny język luźno wpisany (w przeciwieństwie do silnie napisanego języka Python, język dynamiczny), w wyniku czego za pomocą właściwości „prototyp” zaimplementowano koncepcję rozszerzenia obiektu.

Myślę więc, że istnieją pewne zalety dla OO opartego na prototypach, zaimplementowanego w JavaScript:

1. Odpowiedni w środowiskach o luźnym typie, nie ma potrzeby definiowania wyraźnych typów.
2. Sprawia, że ​​niezwykle łatwo jest wdrożyć wzorzec singletonu (porównaj JavaScript i Java pod tym względem, a będziesz wiedział, o czym mówię).
3. Zapewnia sposoby zastosowania metody obiektu w kontekście innego obiektu, dynamicznego dodawania i zastępowania metod z obiektu itp. (Rzeczy, które nie są możliwe w silnie typowanych językach).

Oto niektóre z wad prototypowego OO:

1. Nie ma łatwego sposobu na implementację zmiennych prywatnych. Jego możliwe do wykonania przy użyciu prywatnych vars Crockforda czarów „s za pomocą zamknięć , ale jego na pewno nie tak trywialne, jak za pomocą zmiennych prywatnych powiedzmy Java lub C #.
2. Nie wiem jeszcze, jak zaimplementować wielokrotne dziedziczenie (o ile jest to warte) w JavaScript.