• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

obiekty, programowanie obiektowe, js

VPS Starter Arubacloud
0 głosów
634 wizyt
pytanie zadane 21 listopada 2017 w JavaScript przez turtelian Obywatel (1,760 p.)

Jako ze postanowilem wyjsc na wyzszy level zaczalem bawic sie obiektami i nasunelo mi sie takie pytanie : po co robic funkcje dla obiektu jesli mozna robic funkcje osobno ?
chodzi mi o cos takiego np :

var Dice={
sides:5;
roll: function(){
return wynik*this.sides;
}
}

skoro moge ta funkcje napisac po za obiektem i bedzie dostepna wszedzie ?

function roll(x){
return wynik*x;
}
roll(Dice.sides);

Ponownie zaczalem sie gubic w obiektach mimo ze juz pare razy wydawalo mi sie ze je rozumiem :D

3 odpowiedzi

+3 głosów
odpowiedź 21 listopada 2017 przez Schizohatter Nałogowiec (39,600 p.)
wybrane 21 listopada 2017 przez turtelian
 
Najlepsza
Właśnie o to chodzi, że funkcja jest dostępna wszędzie. To jest właśnie złe. Przez to mogą powstać konflikty nazw. Mówimy o tzw. enkapsulacji kodu.

Dalej: mamy czytelniejszy kod. Grupowanie samo w sobie jest ważne dla struktury kodu. Zbiór luźnych funkcji mało mówi o działaniu kodu.

Poza tym przypięcie "roll" do "Dice" jest "naturalne". Dzięki temu mniej musisz zapamiętać. Bo skąd mam wiedzieć, co jest argumentem funkcji roll? A tak to robię tylko dice.roll i mam co chcę.

Następnie jest kwestia tego, że w ramach jednego obiektu metody mogą wchodzić między sobą w interakcję wykorzystując zmienne obiektu jako nośnik informacji. Dzięki temu w momencie wykorzystywania obiektu nieistotna jest implementacja jego metod, tylko ich końcowy rezultat. Dopiero w momencie, kiedy coś w samym obiekcie mi nie odpowiada, wchodzę w jego plik (zazwyczaj osobny plik) i edytuję co trzeba.

No i ostatecznie obiekty umożliwiają w wielu językach czytelniejszy zapis metod dzięki tzw. chainowaniu:

np. roll(createDice(6)) -> Dice.new(6).roll(); [Ruby]

Nie powstaje w ten sposób "nawias-hell".

To nie jest tak, że OOP daje większe możliwości. Ale jest pewną konwencją, która posiada swoje zalety, a do najważniejszych należą hermetyzacja (enkapsulacja), naturalność i czytelność.
0 głosów
odpowiedź 21 listopada 2017 przez Jedras Maniak (54,860 p.)
Widelcem zupę też można próbować zjeść, ale czy na dłuższą metę to ma sens? Metody to jedna z podstawowych "składowych" OOP. Powiązanie konkretnych funkcji z obiektami pomaga zwiększyć zrozumienie kodu i późniejszy rozwój aplikacji.

Musisz jeszcze jednak o OOP doczytać troszkę ;)
komentarz 21 listopada 2017 przez turtelian Obywatel (1,760 p.)
w skrocie mozesz powiedziec jaka przewage ma sposob nr 1 ?
bo poki co widze tylko 1 przewage sposobu nr 2.
0 głosów
odpowiedź 22 listopada 2017 przez kap Stary wyjadacz (11,620 p.)
edycja 22 listopada 2017 przez kap

Po pierwsze - przykład jest całkiem bez sensu, więc nie bardzo jest materiał do dyskusji.
Co to za zmienna globalna wynik? Czemu to się roll nazywa jak nie ma tam żadnej losowości? Czy w ogóle kostka może mieć inne cechy niż liczba stron?



Abstrachując od tego - zarówno podejście obiektowe jak i funkcyjne są ok - to dwa równoważne paradygmaty w JS (choć u ciebie w drugiej wersji nie ma podejścia funkcyjnego, jest jakies nie wiadomo co na globalach, no chyba, że wynik to stała).

@Schizohatter

Właśnie o to chodzi, że funkcja jest dostępna wszędzie. To jest właśnie złe. Przez to mogą powstać konflikty nazw. Mówimy o tzw. enkapsulacji kodu.

No niekoniecznie dostępna wszędzie, w dobrym kodzie ograniczona do modułu / bloku kodu, wtedy konfliktów unikasz.

Dalej: mamy czytelniejszy kod. Grupowanie samo w sobie jest ważne dla struktury kodu. Zbiór luźnych funkcji mało mówi o działaniu kodu.

To mocno subiektywne, czy jest to czytelniejsze czy nie, może na poziomie pojedynczej klasy tak jest, ale jeśli chodzi o przepływ danych to polemizowałbym. Dodatkowo grupowanie nie jest unikatową cechą obiektówki.

Poza tym przypięcie "roll" do "Dice" jest "naturalne". Dzięki temu mniej musisz zapamiętać.

Kolejne subiektywne stwierdzenie, naturalne dla kogoś, kto ma do czynienia głównie z obiektówką, być może naturalne dla niektórych przpadków, niekoniecznie dla wszystkich, polecam: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

Bo skąd mam wiedzieć, co jest argumentem funkcji roll? A tak to robię tylko dice.roll i mam co chcę.

Dokładnie z tego samego miejsca jak w przypadku metod przyjmujących argumenty - z czytelnej nazwy parametu i dokumentacji typów (+ ewentualnego komentarza) w JSDoc
 

Następnie jest kwestia tego, że w ramach jednego obiektu metody mogą wchodzić między sobą w interakcję wykorzystując zmienne obiektu jako nośnik informacji.

Równie dobrze można komponować funkcje przekazując informacje przez parametry.

Dzięki temu w momencie wykorzystywania obiektu nieistotna jest implementacja jego metod, tylko ich końcowy rezultat. Dopiero w momencie, kiedy coś w samym obiekcie mi nie odpowiada, wchodzę w jego plik (zazwyczaj osobny plik) i edytuję co trzeba.

W podejściu funkcyjnym też nieistotna jest implementacja funkcji, ba - jest kładziony mocny nacisk na to, by funkcja była "czysta" - czarna skrzynka bez efektów ubocznych, idealna do testowania. Zbiór powiązanych funkcji też zwykle znajduje się w jednym pliku-module.

 

No i ostatecznie obiekty umożliwiają w wielu językach czytelniejszy zapis metod dzięki tzw. chainowaniu:

np. roll(createDice(6)) -> Dice.new(6).roll(); [Ruby]

Nie powstaje w ten sposób "nawias-hell".

W JSie (a o nim mówimy), gdzie funkcje można przekazywać jako argumenty nie ma to większego znaczenia, bo funkcje można komponować równie czytelnie, co chainowac obiekty:

Zamiast pisać tak:
 

const doComplexThing = item => doBaz(doBar(doFoo(item))))

można użyć flow/pipe/compose:
 

const doComplexThing = compose(
  doFoo,
  doBar,
  doBaz
)

To nie jest tak, że OOP daje większe możliwości. Ale jest pewną konwencją, która posiada swoje zalety, a do najważniejszych należą hermetyzacja (enkapsulacja), naturalność i czytelność.

Ma też trochę wad w stosunku do podejścia funkcyjnego, na szybko przychodzą mi do głowy:
- jest mniej komponowalne,
- często jest bardziej rozwlekłe,
- opieranie się o obiekty (dane + zachowanie) utrudnia dzielenie i rozpraszanie programu w porównaniu z operowaniem na strukturach danych,
- ciężej jest przeprowadzać generyczne operacje,
- flow programu jest skomplikowany.

Co do naturalności i czytelności - tak jak mówiłem - kwestia przyzwyczajeń i preferencji.

Twój post tak trochę wygląda, jakbyś porównywał obiektówkę z kiepskim proceduralnym spaghetti na globalach, a to nie jedyne opcje w JS ;)
 

Podobne pytania

0 głosów
2 odpowiedzi 176 wizyt
0 głosów
1 odpowiedź 1,775 wizyt
pytanie zadane 7 maja 2018 w Java przez Tytanohinoid Początkujący (370 p.)
0 głosów
2 odpowiedzi 421 wizyt
pytanie zadane 27 października 2018 w JavaScript przez kameleon Użytkownik (590 p.)

92,451 zapytań

141,261 odpowiedzi

319,073 komentarzy

61,853 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Akademia Sekuraka

Akademia Sekuraka 2024 zapewnia dostęp do minimum 15 szkoleń online z bezpieczeństwa IT oraz dostęp także do materiałów z edycji Sekurak Academy z roku 2023!

Przy zakupie możecie skorzystać z kodu: pasja-akademia - użyjcie go w koszyku, a uzyskacie rabat -30% na bilety w wersji "Standard"! Więcej informacji na temat akademii 2024 znajdziecie tutaj. Dziękujemy ekipie Sekuraka za taką fajną zniżkę dla wszystkich Pasjonatów!

Akademia Sekuraka

Niedawno wystartował dodruk tej świetnej, rozchwytywanej książki (około 940 stron). Mamy dla Was kod: pasja (wpiszcie go w koszyku), dzięki któremu otrzymujemy 10% zniżki - dziękujemy zaprzyjaźnionej ekipie Sekuraka za taki bonus dla Pasjonatów! Książka to pierwszy tom z serii o ITsec, który łagodnie wprowadzi w świat bezpieczeństwa IT każdą osobę - warto, polecamy!

...