Klasy nie czynią JavaScriptu bardziej obiektowym. Kropka.
Po raz kolejny czytam, że ktoś uważa jakoby klasy w ES6 były jakąś super zmianą, która z JavaScriptu czyniła w pełni obiektowy język.
This is wrong on some many levels...
JavaScript był obiektowy już dawno. Może nie w pełni obiektowy i dalej nie jest w pełni obiektowy w takim stopniu jak Python (choćby dlatego, że w JS liczby nie są prawdziwymi obiektami tak do końca - w Pythonie są), jednak jest obiektowy enough, prawie wszystko jest obiektem (łącznie z funkcjami - w wielu niby to obiektowych językach funkcja nie jest obiektem), można stosować polimorfizm, kompozycję, dziedziczenie, enkapsulację danych (przez domknięcia).
Owszem, klasy są pewną formalizacją patternów, które użytkownicy już dawno stosowali. Jeśli ktoś stosował składnię typu:
function Foo() {... }
Foo.prototype.meth = function () {
};
to pewnie się ucieszy, że używając klas składnia jest prostsza. Klasy ukrócą również partyzantkę, że każdy framework tworzy własną implementację pseudoklas (React.createClass, OtherFramework.inherits etc.)
Problem tylko w tym, że definiowanie klas to nie jedyna metoda na "zarządzanie obiektówką w JS".
równie dobrze możemy stworzyć literał obiektu i mamy to samo, a nawet więcej.
Załóżmy wpierw sytuację, kiedy mamy jeden obiekt danego typu. Czy na pewno warto tworzyć klasę? Załóżmy, że potrzebny nam obiekt aplikacji (który na początek będzie ładował jej logo i wywoływał callback po załadowaniu). Po co pisać tak?
skoro można tak:
Dużo prościej i czytelniej. Keep it simple, stupid. Potrzebujesz jednego obiektu, po kiego grzyba ci klasa?
No dobra, ale jeśli tych obiektów będzie więcej? Też nie problem, po prostu wydzielasz logikę tworzenia do osobnej funkcji i masz fabrykę. Wow. Wzorzec fabryki. To brzmi równie cool i profesjonalnie co klasa, prawda?
W sumie... przez moment, kiedy zacząłem odkrywać klasy, ES6 itp. to pisząc fabryki czułem się trochę do tyłu i nawet miałem poczucie, że coś źle robię, że może piszę zbyt amatorsko, że jednak "powinno się" popakować to "ładnie" w klasy.
Chociaż widziałem, że Douglas Crockford też stosuje takie podejście, więc nie jestem osamotniony.
Widziałem też kody, które były na klasach, a które były zamotane i nieczytelne aż do granic możliwości, że szybko zwątpiłem w sens stosowania klas.
Można powiedzieć, że toporność symulowania klas w poprzednich wersjach JavaScript była wielką zaletą. Dzięki temu każde tworzenie "klasy" było świętem. Przy braku doświadczenia w pisaniu prototypów można było się łatwo pomylić i człowiek musiał przystanąć i pomyśleć dlaczego coś nie działa.
A teraz? Ludzie ładują klasy niemal bez sensu, bo przecież klasy każdy umie napisać, bo to jak w Javie co była przecież na studiach. Klasy ES6 są jak żarcie z McDonalda. Smaczne, bo smaczne (na serio, rzadko jem w McD, ale jak coś zjem to mi bardzo smakuje), ale nie jest to zbyt zdrowe (dlatego nie jem często w McD).
No dobra a dziedziczenie? No więc tak - jeśli potrzebujemy dziedziczenia, to wpierw powinniśmy się zastanowić - czy na pewno? (w 90% przypadków nie potrzebujemy dziedziczenia, bo to antypattern - w pozostałych 10% mamy do wyboru w JS dziedziczenie klasowe, na prototypach (Object.create służy pomocą), za pomocą mixinów, dekoratorów itp.). Można pisać więc bez klas i mieć to dziedziczenie, jeśli komuś koniecznie potrzebne.
Podsumowując - to nie chcę negować samych klas, ale uważam, że ludzie złapali te klasy i wrzucają wszędzie bez wyraźnej potrzeby, nie widzą, że nawet w OOP są lepsze podejścia niż klasy (nie mówiąc już o innych paradygmatach niż OOP, choćby programowanie funkcyjne - nawet w React da się zrobić przecież komponent za pomocą 1 funkcji).
This is wrong on some many levels...
JavaScript był obiektowy już dawno. Może nie w pełni obiektowy i dalej nie jest w pełni obiektowy w takim stopniu jak Python (choćby dlatego, że w JS liczby nie są prawdziwymi obiektami tak do końca - w Pythonie są), jednak jest obiektowy enough, prawie wszystko jest obiektem (łącznie z funkcjami - w wielu niby to obiektowych językach funkcja nie jest obiektem), można stosować polimorfizm, kompozycję, dziedziczenie, enkapsulację danych (przez domknięcia).
Owszem, klasy są pewną formalizacją patternów, które użytkownicy już dawno stosowali. Jeśli ktoś stosował składnię typu:
function Foo() {... }
Foo.prototype.meth = function () {
};
to pewnie się ucieszy, że używając klas składnia jest prostsza. Klasy ukrócą również partyzantkę, że każdy framework tworzy własną implementację pseudoklas (React.createClass, OtherFramework.inherits etc.)
Problem tylko w tym, że definiowanie klas to nie jedyna metoda na "zarządzanie obiektówką w JS".
równie dobrze możemy stworzyć literał obiektu i mamy to samo, a nawet więcej.
Załóżmy wpierw sytuację, kiedy mamy jeden obiekt danego typu. Czy na pewno warto tworzyć klasę? Załóżmy, że potrzebny nam obiekt aplikacji (który na początek będzie ładował jej logo i wywoływał callback po załadowaniu). Po co pisać tak?
skoro można tak:
Dużo prościej i czytelniej. Keep it simple, stupid. Potrzebujesz jednego obiektu, po kiego grzyba ci klasa?
No dobra, ale jeśli tych obiektów będzie więcej? Też nie problem, po prostu wydzielasz logikę tworzenia do osobnej funkcji i masz fabrykę. Wow. Wzorzec fabryki. To brzmi równie cool i profesjonalnie co klasa, prawda?
W sumie... przez moment, kiedy zacząłem odkrywać klasy, ES6 itp. to pisząc fabryki czułem się trochę do tyłu i nawet miałem poczucie, że coś źle robię, że może piszę zbyt amatorsko, że jednak "powinno się" popakować to "ładnie" w klasy.
Chociaż widziałem, że Douglas Crockford też stosuje takie podejście, więc nie jestem osamotniony.
Widziałem też kody, które były na klasach, a które były zamotane i nieczytelne aż do granic możliwości, że szybko zwątpiłem w sens stosowania klas.
Można powiedzieć, że toporność symulowania klas w poprzednich wersjach JavaScript była wielką zaletą. Dzięki temu każde tworzenie "klasy" było świętem. Przy braku doświadczenia w pisaniu prototypów można było się łatwo pomylić i człowiek musiał przystanąć i pomyśleć dlaczego coś nie działa.
A teraz? Ludzie ładują klasy niemal bez sensu, bo przecież klasy każdy umie napisać, bo to jak w Javie co była przecież na studiach. Klasy ES6 są jak żarcie z McDonalda. Smaczne, bo smaczne (na serio, rzadko jem w McD, ale jak coś zjem to mi bardzo smakuje), ale nie jest to zbyt zdrowe (dlatego nie jem często w McD).
No dobra a dziedziczenie? No więc tak - jeśli potrzebujemy dziedziczenia, to wpierw powinniśmy się zastanowić - czy na pewno? (w 90% przypadków nie potrzebujemy dziedziczenia, bo to antypattern - w pozostałych 10% mamy do wyboru w JS dziedziczenie klasowe, na prototypach (Object.create służy pomocą), za pomocą mixinów, dekoratorów itp.). Można pisać więc bez klas i mieć to dziedziczenie, jeśli komuś koniecznie potrzebne.
Podsumowując - to nie chcę negować samych klas, ale uważam, że ludzie złapali te klasy i wrzucają wszędzie bez wyraźnej potrzeby, nie widzą, że nawet w OOP są lepsze podejścia niż klasy (nie mówiąc już o innych paradygmatach niż OOP, choćby programowanie funkcyjne - nawet w React da się zrobić przecież komponent za pomocą 1 funkcji).
Komentarze
Prześlij komentarz