Strategia w programowaniu obiektowym

KamilAdam napisał(a):

Riddle napisał(a):

@KamilAdam: No więc jaki jest Twój input? Strategia jest obiektowa czy nie?

Ale ja już pisałem:

• nie znam się na obiektowości i nawet nie chcę się znać bo swoją przyszłość widzę bardziej w programowaniu funkcyjnym
• IMHO jeśli strategia nie jest wzorcem obiektowy to tym lepiej dla strategii. Pozostaje pytanie czym wzorcem jest strategia, bo PF jej odpowiednikiem jest Higher Order Functions (dla strategii z jedną metodą publiczną, dla strategii z większą ilością metod publicznych trzeba bardziej pokombinować)

BTW wydaje się że jakbyś oczekiwał że każdy obiekt w programowaniu obiektowym będzie enkapsulować, ale dlaczego nie wymagasz spełnienia trzech pozostałych punktów? Np że każdy obiekt będzie dziedziczyć. W Javie jest to oczywiście spełnione, bo każdy obiekt dziedziczy po klasie Object, ale np w C++ chyba można stworzyć klase/obiekt tkóry nie dziedziczy po niczym? Czy w takim razie to jest OOP skoro nie ma dziedziczenia?

Z prostego powodu.

Dlatego że część obiektów nie musi dziedziczyć z niczego. W normalnej aplikacji OOP, część obiektów będzie dziedziczyć z czegoś, ale część nie. Więc to jest normalne że obiekty z niczego nie dziedziczą.

Albo czy VO to OOP skoro nie enkapsulują, Albo Integer w Javie? Cały stan jest na wierzchu. Albo ArrayList/HashMap? Też cały stan jest na wierzchu?

W programowaniu obiektowym mamy obiekty i nie obiekty. Jeśli coś ma mieć w sobie logikę, to lepiej żeby coś enkapsulowało (żeby było obiektem). Ale takie wartości jak gołe inty, gołe recordy lub gołe kolekcje mogą być sobie (jeśli nie mają w sobie logiki żadnej). Gołe bajty też są spoko.

Na nieszczęscie w większości języków obiekty oraz VO robi się uzywają tej samej konstrukcji class - co prowadzi do fatalnego niezrozumienia czym jest OOP.

piotrpo napisał(a):

Moim zdaniem uczepiłeś się trochę tej enkapsulacji i uważasz ją za warunek konieczny do uznania czegoś za OOP. Ale niech będzie.

Jeśli obiekt niczego nie enkapsuluje, to równie dobrze mogłby być funkcją bez klasy. (I jak mi zaraz powiesz że w Javie nie można zrobić funkcji bez klasy, to ja odpowiem co z tego. Piszę w kotlinie, robię strategię która nic nie enkapsuluje. Ona równie dobrze mogłaby być globalną funkcją).

Enkapsulacja to w skrócie tyle, że masz jakąś klasę z jakimś interface'm zewnętrznym, składającym się z iluś tam metod i definicja tego interface'u powinna być wszystkim co jest ci potrzebne do użycia go.

yyy... nie prawda.

Jak w tym interfejsie będę miał same gettery i settery to znaczy że zaenkapsulowałem dane w środku?

Brednie.

Enkapsulacja to uniezależnienie implementacji polegającej na jakichś danych od klientów tej implementacji.

Riddle napisał(a):

KamilAdam napisał(a):

Albo czy VO to OOP skoro nie enkapsulują, Albo Integer w Javie? Cały stan jest na wierzchu. Albo ArrayList/HashMap? Też cały stan jest na wierzchu?

W programowaniu obiektowym mamy obiekty i nie obiekty. Jeśli coś ma mieć w sobie logikę, to lepiej żeby coś enkapsulowało (żeby było obiektem). Ale takie wartości jak gołe inty, gołe recordy lub gołe kolekcje mogą być sobie (jeśli nie mają w sobie logiki żadnej). Gołe bajty też są spoko.

Hm, jak dużo musi być tej logiki żebyś uznał ją za Logikę? No bo czy equals to logika? Albo size(). Spójrz na Javadoca dla HashMapy. IMHO Zawierają całkiem sporo logiki, a HashMapa zawiera dane bez enkapsulacji. Czy to jest jeszcze OOP?

KamilAdam napisał(a):

Riddle napisał(a):

KamilAdam napisał(a):

Albo czy VO to OOP skoro nie enkapsulują, Albo Integer w Javie? Cały stan jest na wierzchu. Albo ArrayList/HashMap? Też cały stan jest na wierzchu?

W programowaniu obiektowym mamy obiekty i nie obiekty. Jeśli coś ma mieć w sobie logikę, to lepiej żeby coś enkapsulowało (żeby było obiektem). Ale takie wartości jak gołe inty, gołe recordy lub gołe kolekcje mogą być sobie (jeśli nie mają w sobie logiki żadnej). Gołe bajty też są spoko.

Hm, jak dużo musi być tej logiki żebyś uznał ją za Logikę? No bo czy equals to logika? Albo size(). Spójrz na Javadoca dla HashMapy. IMHO Zawierają całkiem sporo logiki, a HashMapa zawiera dane bez enkapsulacji. Czy to jest jeszcze OOP?

Ciężko powiedzieć, nie chcę odpowiadać definitywnie w jedną lub drugą stronę.

Jaki jest sens używania hashmapy, zamiast for na array'u? Chyba tylko performance.

Riddle napisał(a):

Jak w tym interfejsie będę miał same gettery i settery to znaczy że zaenkapsulowałem dane w środku?

Gettery i Settery to też jest jakaś enkapsulacja. No bo przecież taki setter w cale nie musi zapisywac do pola.
Setter może zapisywać do HashMapy (żeby było smieszniej). Setter może zapisywac do bazy (jak w enchach JPA (w zasadzie to tam jest śledzenie zmian, a nie od razu zapisywanie do bazy). Setter może przesyłać dane na zdalny serwer.
Getter może istnieć dla pola które w ogóle nie istnieje (getter wyliczany z innych pól). Getter może leniwie łądować dane

Update

Jaki jest sens używania hashmapy, zamiast for na array'u? Chyba tylko performance.

Racja, chociaż nie wiem co to ma w temacie enkapsulacji. BTW można owrapować tablice Tupli (po scalowemu Array[Tuple2[KEY, VALUE]) tak żeby spełniała interfejs mapy (po scalowemu Map[Key, Value]), ale nie wiem jak to ma się do tego czy Map czy Array jest OOP

KamilAdam napisał(a):

Riddle napisał(a):

Jak w tym interfejsie będę miał same gettery i settery to znaczy że zaenkapsulowałem dane w środku?

Gettery i Settery to też jest jakaś enkapsulacja.
No bo przecież taki setter w cale nie musi zapisywac do pola.
Setter może zapisywać do HashMapy (żeby było smieszniej). Setter może zapisywac do bazy (jak w enchach JPA (w zasadzie to tam jest śledzenie zmian, a nie Od razu zapisywanie do bazy). Setter może przesyłać dane na zdalny serwer.
Getter może istnieć dla pola które w ogóle nie istnieje (getter wyliczany z innych pól). Getter może leniwie łądować dane

Zależy co masz na myśli mówiąc setter i getter.

Powiem tak:

Jeśli zadam obiektowi pytanie: "dlaczego dana funkcja ma taki interfejs", a ten obiekt odpowie, jakikolwiek argument związany z tym jak jego dane wyglądają, to to nie jest enkaspulacja.

Innymi słowy, jeśli operuję na jakimś interfejsie, to chcę móc dowolnie zmienić jego wewnętrzną implementację, dowolnie. I może się tak zdarzyć, ktoś zaprojektuje taki interfejs, że zmiana implementacji będzie musiała skutkować zmianą interfejsu. Wtedy wiem że to nie jest prawdziwa enkapsulacja. Dla mnie rule of thumb jest takie "nie myśl o metodach jak o property'sach" - bo to jest dobra droga do tego żeby złamać eknapsulację.

Przykład.

Według mnie, to nie jest złamana enkapsulacja (mimo że niektórzy powiedzą że to settery i gettery):

interface { isVisible(): bool; setVisible(bool v); }

Z kolei takie coś już jest złamaniem

interface ( getUsers(): User[]; setUsers(User[] u); }

Dlaczego? Dlatego, że jak mam te metody isVisible() oraz setVisible(), to nie wyobrażam sobie zmiany implementacji chowania i pokazywania która wypłynęłaby na zmianę tych funkcji. Ale z setUsers()/getUsers() już tak, chociażby paginacja.

Odbiegamy od tematu.

Moim zdaniem, jeśli obiekt nie dostaje żadnej wartości "z góry" (jak np new MyService()) to równie dobrze jego metody mogłyby być funkcjami. Ergo nie uważam że są obiektowe. To po prostu zlepek metod włożonych do jednego "namespace'a", do klasy.

Riddle napisał(a):

Jeśli obiekt niczego nie enkapsuluje, to równie dobrze mogłby być funkcją bez klasy. (I jak mi zaraz powiesz że w Javie nie można zrobić funkcji bez klasy, to ja odpowiem co z tego. Piszę w kotlinie, robię strategię która nic nie enkapsuluje. Ona równie dobrze mogłaby być globalną funkcją).

Jeżeli ta strategia ma być strategią, to nadal musisz wstrzyknąć coś do obiektu. Czy to co wstrzykujesz jest, lub nie jest zapakowane w obiekt ma małe znaczenie moim zdaniem. Z punktu widzenia gospodarza, to nadal dostaje obiekt. W Kotlinie deklarując miejsce na przyjęcie tego zewnętrznego algorytmu wstawisz parametr określający interface, nawet jeżeli ten interface będzie w formie szczątkowej (Int) -> Int, to nadal wiesz, że dostaniesz tam obiekt, który posiada jedną metodę, przyjmującą jeden parametr Int i zwracającą Int, której nazwa jest nieistotna, bo jest tylko jedna. To, czy wskażesz tam funkcję globalną, czy dowolną implementację funkcyjnego interface'u pozwalającego na takie mapowanie nie ma znaczenia.
Zresztą omawianie wzorców projektowych w kontekście języków hybrydowych trochę traci sens, bo jednym z powodów ich rozwoju, jest właśnie łatwiejsze rozwiązywanie problemów, na które kiedyś odpowiadały wzorce.

Enkapsulacja to w skrócie tyle, że masz jakąś klasę z jakimś interface'm zewnętrznym, składającym się z iluś tam metod i definicja tego interface'u powinna być wszystkim co jest ci potrzebne do użycia go.

yyy... nie prawda.

Jak w tym interfejsie będę miał same gettery i settery to znaczy że zaenkapsulowałem dane w środku?

Nie, jak masz getPies():Pies to jedyne co wiesz, to że po wywołaniu tej metody dostaniesz psa. Nie wiesz, czy obiekt, który tę metodę udostępnia faktycznie posiada w środku dane, czy może wyłącznie wiedzę jak te dane pozyskać i zwrócić.

Brednie.

Może idź na jakiegoś bootcampa z soft skilli?

Enkapsulacja to uniezależnienie implementacji polegającej na jakichś danych od klientów tej implementacji.

Dlaczego ograniczasz enkapsulację do "danych"? Moim zdaniem to dużo szersze pojęcie, które oznacza, że wiesz co jakiś obiekt jest w stanie dla ciebie zrobić, ale nie wiesz, nie chcesz wiedzieć i nie musisz wiedzieć jak tę deklarowaną funkcjonalność realizuje.

@piotrpo: Wypowiadasz się nie na temat. Pozwól że zadam pytanie z wątku jeszcze raz, licząc że może teraz zrozumiesz o co chodzi.

Przykładowy kod używający strategi

interface Collection {
  int size();
  bool empty();
  sort(SortStrategy strategy);
}

interface SortStrategy {
  public sort(Collection c);
}

i jej użycie

c = new ArrayCollection();
c.sort(new BubbleSort()); // sortowanie bąbelkowe
c.sort(new QuickSort()); // sortowanie quick-sort

Ktoś użył wzorca Strategy, żeby dostarczyć dwie implementacje sortowania do kolekcji. Całą intencją istnienia tego interfejsu jest to, żeby dostarczyć różne implementacje, i zostały zaprojektowane z myślą o tym żeby te strategie były niczym innym jak tylko implementacją algorytmu bez niczego w środku.

Nie ma żadnego powodu zeby uważać że obiekty new BubbleSort() i new QuickSort() faktycznie są w paradygmacie obiektowym. Równie dobrze mogłyby być funkcjami.

@Riddle: No właśnie trochę nie wiem czego się czepiasz.
Te strategie nie są "bez niczego w środku". W środku mają wiedzę jak zrealizować obiecywaną funkcjonalność.
W tym konkretnym przypadku, faktycznie mogłyby być funkcjami. Tylko to niczego nie zmienia, bo:

• nie każda implementacja strategii, to 1 pure funkcja
• dyskutowanie czy jakiś wzorzec jest obiektowy, jeżeli się go realizuje w języku nieobiektowym, albo nieobiektowo w języku hybrydowym jest podejściem trochę dziwnym/absurdalnym. Trochę takie rozważanie, czy jak cioci urosną wąsy, to wciąż jest ciocią, czy może już wujkiem.

piotrpo napisał(a):

W tym konkretnym przypadku, faktycznie mogłyby być funkcjami. Tylko to niczego nie zmienia, bo:

• nie każda implementacja strategii, to 1 pure funkcja
• dyskutowanie czy jakiś wzorzec jest obiektowy, jeżeli się go realizuje w języku nieobiektowym, albo nieobiektowo w języku hybrydowym jest podejściem trochę dziwnym/absurdalnym. Trochę takie rozważanie, czy jak cioci urosną wąsy, to wciąż jest ciocią, czy może już wujkiem.

Jasno widać że nie rozumiesz dylematu.

Piszę program funkcyjnie, wiec dodam sobie funkcje/callbacki i rozwiązałem problem.
Teraz piszę program w paradygmacie obiektowym, i zastanawiam się jak ugryść strategię.

Wierz lub nie, ale Twój post mi w niczym nie pomaga, w niczym całkowicie mnie nie przybliża do odpowiedzi. Przyszedłeś i mówisz

1. Enkapsulacja to nie enkapsulacja
2. OOP nie wymaga enkapsulacji
3. Strategia nie musi mieć jednej funkcji

I co z tego, jak Twoje posty są oderwane od pytania z wątku.

Powtarzam jeszcze raz, czwarty chyba raz licząc że może zrozumiesz o co chodzi.

1. Jestem zdania, że w obiektowym świecie (paradygmacie obiektowym), należy tworzyć obiekty które dostają jakiś parametr (np przez konstruktor) - nazywaj to jak chcesz, ja to nazwałem enkapsulacją, ale jeśli Ty masz inne określenie na enkapsulacje, to nie chce użyć tego słowa. Chodzi dokłądnie o to co napisałem: "ze instancje dostają coś przez parametr". To moim zdaniem jest potrzebne, żeby móc nazwać program napisany w paradygmacie obiektowym (nie ważne w jakim języku piszesz).
2. Jestem też swiadom, że w sercu strategii, 90% przypadków to instancje obiektów mające jedną metodę i nie przyjmują nic w parametrze.

Pytanie z wątku (nie wierzę że muszę je zadawać jeszcze raz): Czy z tego wynika że strategia nie jest obiektowa, czy coś mi umyka?

Nie mam ochoty gadać o tym czym według Ciebie jest enkapsulacja, albo czym według Ciebie jest programowanie obiektowe, nie mam ochoty na dywagacje o nazewnictwo. Chodzi tylko o to, czy strategia wpisuje się w paradygmat obiektowy czy nie. A jeśli tak, to czy to oznacza że funkcje globalne też wpisują się w ten paradgymat.

Riddle napisał(a):

1. Jestem zdania, że w obiektowym świecie (paradygmacie obiektowym), należy tworzyć obiekty które dostają jakiś parametr (np przez konstruktor) - nazywaj to jak chcesz, ja to nazwałem enkapsulacją, ale jeśli Ty masz inne określenie na enkapsulacje, to nie chce użyć tego słowa. Chodzi dokłądnie o to co napisałem: "ze instancje dostają coś przez parametr". To moim zdaniem jest potrzebne, żeby móc nazwać program napisany w paradygmacie obiektowym (nie ważne w jakim języku piszesz).

A mi się wydawało, że enkapsulacja to ma związek z tym co widzimy na zewnątrz obiektu a czego nie. Co ma do tego tworzenie obiektu i przekazywanie parametrów?

A odpowiadając na pytanie. Nie wynika, że strategia jest obiektowa czy nie jest. To zależy czy piszesz obiektowo czy nie :P

szydlak napisał(a):

Riddle napisał(a):

1. Jestem zdania, że w obiektowym świecie (paradygmacie obiektowym), należy tworzyć obiekty które dostają jakiś parametr (np przez konstruktor) - nazywaj to jak chcesz, ja to nazwałem enkapsulacją, ale jeśli Ty masz inne określenie na enkapsulacje, to nie chce użyć tego słowa. Chodzi dokłądnie o to co napisałem: "ze instancje dostają coś przez parametr". To moim zdaniem jest potrzebne, żeby móc nazwać program napisany w paradygmacie obiektowym (nie ważne w jakim języku piszesz).

A mi się wydawało, że enkapsulacja to ma związek z tym co widzimy na zewnątrz obiektu a czego nie. Co ma do tego tworzenie obiektu i przekazywanie parametrów?

No siłą rzeczy jak niczego nie przekazujesz przez parametr, to ten obiekt niczego nie enkapsuluje. Błagam. Nie interesuje mnie to co wy uważacie za enkapsulację. Istotne jest to czy strategia jest w paradygmacie obiektowym czy nie.

A odpowiadając na pytanie. Nie wynika, że strategia jest obiektowa czy nie jest. To zależy czy piszesz obiektowo czy nie :P

Czy według Ciebie ten kod jest obiektowy?

interface Collection {
  int size();
  bool empty();
  sort(SortStrategy strategy);
}

interface SortStrategy {
  public sort(Collection c);
}

i jej użycie

c = new ArrayCollection();
c.sort(new BubbleSort()); // sortowanie bąbelkowe
c.sort(new QuickSort()); // sortowanie quick-sort

Riddle napisał(a):

No siłą rzeczy jak niczego nie przekazujesz przez parametr, to ten obiekt niczego nie enkapsuluje. Błagam. Nie interesuje mnie to co wy uważacie za enkapsulację. Istotne jest to czy strategia jest w paradygmacie obiektowym czy nie.

Encapsulation. This principle states that all important information is contained inside an object and only select information is exposed. The implementation and state of each object are privately held inside a defined class. Other objects do not have access to this class or the authority to make changes. They are only able to call a list of public functions or methods. This characteristic of data hiding provides greater program security and avoids unintended data corruption.

Nie wiem czy jest obiektowy czy nie. Ja widzę strategie w ten sposób.

https://www.dofactory.com/net/strategy-design-pattern

Nie wiem jak wygląda kod np funkcyjny. Tzn niby wiem ale nie wiem tak na prawdę.

Ale no załóżmy, że tak jest obiektowy. I co wtedy?

Zawsze wydawało mi się, że wzorce nie są zależne od paradygmatu czy języka.

szydlak napisał(a):

Riddle napisał(a):

No siłą rzeczy jak niczego nie przekazujesz przez parametr, to ten obiekt niczego nie enkapsuluje. Błagam. Nie interesuje mnie to co wy uważacie za enkapsulację. Istotne jest to czy strategia jest w paradygmacie obiektowym czy nie.

Nie wiem czy jest obiektowy czy nie. Ja widzę strategie w ten sposób.

https://www.dofactory.com/net/strategy-design-pattern

No ja ją widzę tak samo.

Ale no załóżmy, że tak jest obiektowy. I co wtedy?

Zawsze wydawało mi się, że wzorce nie są zależne od paradygmatu czy języka.

Cały wątek dotyczy znalezienia prawdy czy strategia jest obiektowa czy nie. Jeśli nie masz argumentu za ani przeciw, to raczej nie wniesiesz nic nowego do dyskusji.

Riddle napisał(a):

Cały wątek dotyczy znalezienia prawdy czy strategia jest obiektowa czy nie. Jeśli nie masz argumentu za ani przeciw, to raczej nie wniesiesz nic nowego do dyskusji.

To ja Ci odpowiadam, że według mnie nie ma kategorii przynależności.

szydlak napisał(a):

Riddle napisał(a):

Cały wątek dotyczy znalezienia prawdy czy strategia jest obiektowa czy nie. Jeśli nie masz argumentu za ani przeciw, to raczej nie wniesiesz nic nowego do dyskusji.

To ja Ci odpowiadam, że według mnie nie ma kategorii przynależności.

Czyli nie ma czegoś takiego jak paradygmat obiektowy?

Jest ale on dotyczy języka a nie wzorca.

szydlak napisał(a):

Jest ale on dotyczy języka a nie wzorca.

Czyli różne języki mają różne paradgymaty obiektowe?

Coś co jest obiektowe w jednym, nie musi być obiektowe w innym?

Nie znam wszystkich języków. Ale OOP to OOP. Wszędzie ma te same zasady.

szydlak napisał(a):

Nie znam wszystkich języków. Ale OOP to OOP. Wszędzie ma te same zasady.

Czyli można powiedzieć że jakiś kod napisany w danym języku spłenia zasady OOP, a inny nie?

Riddle napisał(a):

Jeśli według Ciebie to błąd logiczny, to wykarz to. Zakładając że strategia może być bez stanowa i obiektowa, to czemu miałoby się nie dać zbudować aplikacji z obiektów które są tylko bezstanowe i obiektowe. Z resztą cały Twój argument jest bez sensu, bo oczywiście że dałoby się to zrobić - po prostu przekazujesz wszystkie dane przez parametry - taką aplikację dałoby się bardzo łatwo zrobić, ale po prostu nie była by napisana w paradygmacie obiektowym.

No przecież napisałem.
Przejdźmy najpierw na przypadek analogiczny.

A - zbiór liczb {1;2;3;4;5;6}
B - zbiór liczb {5;6}
C - zbiór liczb ze zbioru A taki, że suma daje 4

I teraz to, że:

1. C składa się z kilku elementów zbioru A
2. B jest podzbiorem A
   Nie oznacza, że istnieje takie C, które składać się będzie tylko z elementów występujących w B

Tak samo jest w przypadku strategii i aplikacji.

1. Jeśli A to zbiór wszystkich klas spełniających "modelowy" paradygmat obiektowy.
2. B to zbiór wszystkich klas spełniających implementujących wzorzec strategii
3. Zakładamy, że strategia wpisuje się w model obiektowy, więc B jest podzbiorem A
4. C to aplikacja złożona z elementów ze zbioru A
   To nie oznacza jeszcze, że każdą aplikację złożoną z klas spełniających paradygmat obiektowy można napisać wyłącznie za pomocą strategii.

wartek01 napisał(a):

Riddle napisał(a):

Jeśli według Ciebie to błąd logiczny, to wykarz to. Zakładając że strategia może być bez stanowa i obiektowa, to czemu miałoby się nie dać zbudować aplikacji z obiektów które są tylko bezstanowe i obiektowe. Z resztą cały Twój argument jest bez sensu, bo oczywiście że dałoby się to zrobić - po prostu przekazujesz wszystkie dane przez parametry - taką aplikację dałoby się bardzo łatwo zrobić, ale po prostu nie była by napisana w paradygmacie obiektowym.

No przecież napisałem.
Przejdźmy najpierw na przypadek analogiczny.

A - zbiór liczb {1;2;3;4;5;6}
B - zbiór liczb {5;6}
C - zbiór liczb ze zbioru A taki, że suma daje 4

I teraz to, że:

1. C składa się z kilku elementów zbioru A
2. B jest podzbiorem A
   Nie oznacza, że istnieje takie C, które składać się będzie tylko z elementów występujących w B

Tak samo jest w przypadku strategii i aplikacji.

1. Jeśli A to zbiór wszystkich klas spełniających "modelowy" paradygmat obiektowy.
2. B to zbiór wszystkich klas spełniających implementujących wzorzec strategii
3. Zakładamy, że strategia wpisuje się w model obiektowy, więc B jest podzbiorem A
4. C to aplikacja złożona z elementów ze zbioru A
   To nie oznacza jeszcze, że każdą aplikację złożoną z klas spełniających paradygmat obiektowy można napisać wyłącznie za pomocą strategii.

Wykazałeś że nie koniecznie musi się dać, ale nie wykazałeś że sie nie da.

Thanks for playing.

@Riddle: dla mnie się strategia nie kłóci z OOP. Istotą częścią tego wzorca jest zmiana (zachowania) w runtime i niby w jaki sposób miałoby to naruszać OOP? W językach nieobiektowych rónież można podmieniać zachowanie w runtime (np. wskaźnik do funkcji w C). Koncept więc jest szerszy niż OOP.

Wygląda, że zapiąłeś się na jakiś konkretny przypadek, gdzie masz implementację algorytmu, która to implementacja:

• nie jest stanowa,
• nie jest parametryzowana via konstruktor
• wypadałoby, żeby była jakoś parametryzowana (bo inaczej jaki byłby sens algorytmu, który ma zawsze ten sam input nie ma inputu?), pewnie przez argumenty podawane do metody

Czyli z poziomu wzorca, przechodzisz na poziom implementacji, która jest bezstanowa, i z faktu wybrania takiej implementacji wyciągasz wnioski, że strategia nie jest OOP?

Kolejna sprawa, tożsamość - różne instancje mają różną tożsamość, przez fakt, że tworzysz je w różnym czasie (przez to mają już różny cykl życia) i są rozróżnialne w aplikacji (przez fakt używania referencji) Możesz jednak uznać, że dla Ciebie nie są rozróżnialne, mimo, że są fizycznie różne.

p.s.

Stoi coś na przeszkodzie, żeby Builder tworzył strategię w oparciu o user input (tworzył, nie wybierał jedną z dostępnych i hardkodowanych w systemie)? Wówczas taka implementacja strategii, kłóci się z OOP czy nie?

yarel napisał(a):

@Riddle: dla mnie się strategia nie kłóci z OOP. Istotą częścią tego wzorca jest zmiana (zachowania) w runtime i niby w jaki sposób miałoby to naruszać OOP? W językach nieobiektowych rónież można podmieniać zachowanie w runtime (np. wskaźnik do funkcji w C). Koncept więc jest szerszy niż OOP.

Jezus maria, no przecież cały wątek jest o tym.

Dlatego narusza OOP, bo nie enkapsuluje żadnego stanu w sobie (nie dostaje nic przez parametry konstruktora), w efekcie nie różni się od lamdy/callbacka.

Wygląda, że zapiąłeś się na jakiś konkretny przypadek, gdzie masz implementację algorytmu, która to implementacja:

• nie jest stanowa,
• nie jest parametryzowana via konstruktor
• wypadałoby, żeby była jakoś parametryzowana (bo inaczej jaki byłby sens algorytmu, który ma zawsze ten sam input nie ma inputu?), pewnie przez argumenty podawane do metody

Czyli z poziomu wzorca, przechodzisz na poziom implementacji, która jest bezstanowa, i z faktu wybrania takiej implementacji wyciągasz wnioski, że strategia nie jest OOP?

Pretty much. Przynajmniej taka bezstanowa.

Kolejna sprawa, tożsamość - różne instancje mają różną tożsamość, przez fakt, że tworzysz je w różnym czasie (przez to mają już różny cykl życia) i są rozróżnialne w aplikacji (przez fakt używania referencji) Możesz jednak uznać, że dla Ciebie nie są rozróżnialne, mimo, że są fizycznie różne.

Może i są różne, ale idea jest taka że nie ważne czy użyję za każdy razem nowego new Strategy(), czy czy go zapiszę w globalnym miejscu i re-użyję. Nie ma znaczenia. Wszystko jedno. To dla mnie oznacza że te obiekty są tożsame, skoro mogę używać jednego lub drugiego bez róznicy (tak, wiem że w niektórych językach == da false, ale co z tego. Wszystkie funkcje jakie na niej wywołasz dadzą ten sam rezultat).

Stoi coś na przeszkodzie, żeby Builder tworzył strategię w oparciu o user input (tworzył, nie wybierał jedną z dostępnych i hardkodowanych w systemie)? Wówczas taka implementacja strategii, kłóci się z OOP czy nie?

Jeśli nie przyjmuje niczego w parametrach konstruktora, to moim zdaniem chyba tak.

Chyba że masz jakiś argument, za tym czemu miałaby się nie kłócić.

Riddle napisał(a):

Piszę program funkcyjnie, wiec dodam sobie funkcje/callbacki i rozwiązałem problem.
Teraz piszę program w paradygmacie obiektowym, i zastanawiam się jak ugryść strategię.

Wziąć i zaimplementować. Jeżeli priorytetem jest utrzymanie programu w zgodności z paradygmantem obiektowym, to nie wiem co uważasz za ten paradygmat.

1. Jestem zdania, że w obiektowym świecie (paradygmacie obiektowym), należy tworzyć obiekty które dostają jakiś parametr (np przez konstruktor) - nazywaj to jak chcesz, ja to nazwałem enkapsulacją, ale jeśli Ty masz inne określenie na enkapsulacje, to nie chce użyć tego słowa. Chodzi dokłądnie o to co napisałem: "ze instancje dostają coś przez parametr". To moim zdaniem jest potrzebne, żeby móc nazwać program napisany w paradygmacie obiektowym (nie ważne w jakim języku piszesz).

No i w końcu jasno napisałeś coś z czym mogę się jasno nie zgodzić. Dostawanie (mniejsza o sposób) jakiegoś parametru przez obiekt w czasie jego tworzenia (a również po utworzeniu), nie jest warunkiem niezbędnym, żeby coś nazwać OOP, lub nie OOP.

Nie mam ochoty gadać o tym czym według Ciebie jest enkapsulacja, albo czym według Ciebie jest programowanie obiektowe, nie mam ochoty na dywagacje o nazewnictwo. Chodzi tylko o to, czy strategia wpisuje się w paradygmat obiektowy czy nie. A jeśli tak, to czy to oznacza że funkcje globalne też wpisują się w ten paradgymat.

Ale cały ten wątek i twój problem to spór o nazewnictwo. Zastanawiasz się właśnie, czy jeżeli użyjesz funkcji globalnej, to wciąż będzie można nazwać twój program obiektowym. W poście gdzieś wyżej ubolewasz, że w części języków ~obiektowych klasy i struktury mają taką samą nazwę.

Według mojej wiedzy, nie ma aktualnie żadnego popularnego języka, który jest w 100% obiektowy. Co dla przykładu robią w Javie metody statyczne, pola statyczne, typy prymitywne itd? Czy funkcje z kotlina można wcisnąć w nazwę "object oriented programing"? Jeden rabin powie tak, drugi powie, że nie. Jeżeli sobie popatrzysz na taką funkcję okiem ortodoksa, to absolutnie nie. Ale liberał powie ci, ze taka funkcja to trochę jak implementacja interface'u funkcyjnego, tylko dzięki code sugars z kotlina nie trzeba nigdzie pisać "interface" i nazwy metody, to to się rozumie samo przez siebie. Albo czy tak modne "immutable objects" to obiekty? Bo przecież ideą u podstaw OOP było połączenie danych i logiki, która na nich operuje (w tym zmienia) w jeden byt, np.:

public class Counter{
private int clicks = 0;
public void click(){
  clicks++;
}
public int getClicks() return clicks;
}

No i jeżeli nie można, to jak to jest, że język niby czysto obiektowy, a można pisać nieobiektowo. O pakiecie Math, gdzie ani obiektów, ani metod, a właściwie same funkcje statyczne zapakowane bo trzeba w jedną klasę i typy prymitywne nawet nie warto wspominać.

A w temacie - strategia to dla mnie wzorzec w pełni obiektowy, ponieważ w moim rozumieniu wypełnia całkowicie założenia paradygmatu OOP. Pisze o klasycznych, wzorcowych metodach implementacji.

piotrpo napisał(a):

No i w końcu jasno napisałeś coś z czym mogę się jasno nie zgodzić. Dostawanie (mniejsza o sposób) jakiegoś parametru przez obiekt w czasie jego tworzenia (a również po utworzeniu), nie jest warunkiem niezbędnym, żeby coś nazwać OOP, lub nie OOP.

Okej, ale wtedy taki pojedynczy obiekt nie różni się specjalnie od funkcji prawda? Czemu miałbym nie przekazać po prostu callbacka/lamdy zamiast takiego obiektu?

Nie mam ochoty gadać o tym czym według Ciebie jest enkapsulacja, albo czym według Ciebie jest programowanie obiektowe, nie mam ochoty na dywagacje o nazewnictwo. Chodzi tylko o to, czy strategia wpisuje się w paradygmat obiektowy czy nie. A jeśli tak, to czy to oznacza że funkcje globalne też wpisują się w ten paradgymat.

Ale cały ten wątek i twój problem to spór o nazewnictwo. Zastanawiasz się właśnie, czy jeżeli użyjesz funkcji globalnej, to wciąż będzie można nazwać twój program obiektowym. W poście gdzieś wyżej ubolewasz, że w części języków ~obiektowych klasy i struktury mają taką samą nazwę.

Nie mówię o tym czy będzie można go nazwać obiektowym, tylko czy będzie obiektowy.

Według mojej wiedzy, nie ma aktualnie żadnego popularnego języka, który jest w 100% obiektowy. Co dla przykładu robią w Javie metody statyczne, pola statyczne, typy prymitywne itd? Czy funkcje z kotlina można wcisnąć w nazwę "object oriented programing"?

Moim zdaniem nie.

Jeden rabin powie tak, drugi powie, że nie.

Rabin który powie tak, moim zdaniem nie wie co to jest OOP.

Jeżeli sobie popatrzysz na taką funkcję okiem ortodoksa, to absolutnie nie. Ale liberał powie ci, ze taka funkcja to trochę jak implementacja interface'u funkcyjnego, tylko dzięki code sugars z kotlina nie trzeba nigdzie pisać "interface" i nazwy metody, to to się rozumie samo przez siebie.

Tak, ale to nie znaczy że jest obiektowe.

No i jeżeli nie można, to jak to jest, że język niby czysto obiektowy, a można pisać nieobiektowo. O pakiecie Math, gdzie ani obiektów, ani metod, a właściwie same funkcje statyczne zapakowane bo trzeba w jedną klasę i typy prymitywne nawet nie warto wspominać.

No i Math na pewno nie jest obiektowe.

A w temacie - strategia to dla mnie wzorzec w pełni obiektowy, ponieważ w moim rozumieniu wypełnia całkowicie założenia paradygmatu OOP. Pisze o klasycznych, wzorcowych metodach implementacji.

Argument jakiś za tym? Mówiłeś już 10 razy że spełnia, ale nie podajesz żadnego argumentu za tym. Daj mi powód.

piotrpo napisał(a):

Riddle napisał(a):

Piszę program funkcyjnie, wiec dodam sobie funkcje/callbacki i rozwiązałem problem.
Teraz piszę program w paradygmacie obiektowym, i zastanawiam się jak ugryść strategię.

Wziąć i zaimplementować. Jeżeli priorytetem jest utrzymanie programu w zgodności z paradygmantem obiektowym, to nie wiem co uważasz za ten paradygmat.

No dobra, wziąłem i zaimplementowałem.

Czy to jest obiektowe czy nie?

Nie jest żadnym priorytetem, po prostu zastanawiam się (Piszę to pytanie chyba 100 raz dzisiaj) czy ten napisany kod jest w paradygmacie obiektowym czy nie.

Bardzo irytujące są odpowiedzi ludzi tutaj.

Wyobraźmy sobie, że zadałem pytanie "Czy funkcja sum() jest napisana w paradygmacie funkcynmym?". (np taka function sum(a,b) { return a+b; } myślę że wszyscy ludzie zgodziliby się że tak, jednoznacznie taka funkcja jest napisana w paradygmacie funkcjnym.

Ale na pytanie zadane w sposób "Czy strategia sortowania jest napisana w paradygmacie obiektowym?" dostaję odpowiedzi które wjeżdżają na nazewnictwo, zarzucają rozmowy o to czym i czym enkapsulacja nie jest, i odciągają pytania na poboczne tory.

Czemu pytania o pasowanie do paradygmatu funkcyjnego mają taką prostą odpowiedź na tym forum, ale zwykłe pytanie "Czy strategia wpisuje się w paradygmat obiektowy" robi taki szum i zamieszanie?

Riddle napisał(a):

Czemu pytania o pasowanie do paradygmatu funkcyjnego mają taką prostą odpowiedź na tym forum, ale zwykłe pytanie "Czy strategia wpisuje się w paradygmat obiektowy" robi taki szum i zamieszanie?

Bo paradygmat obiektowy jest zdefiniowany o wiele bardziej mgliście niż paradygmat funkcyjny. Niby OOP ma o wiele lepszą definicję niż FP, ale o wiele trudniej ją zastosować

Riddle napisał(a):

piotrpo napisał(a):

No i w końcu jasno napisałeś coś z czym mogę się jasno nie zgodzić. Dostawanie (mniejsza o sposób) jakiegoś parametru przez obiekt w czasie jego tworzenia (a również po utworzeniu), nie jest warunkiem niezbędnym, żeby coś nazwać OOP, lub nie OOP.

Okej, ale wtedy taki pojedynczy obiekt nie różni się specjalnie od funkcji prawda? Czemu miałbym nie przekazać po prostu callbacka/lamdy zamiast takiego obiektu?

No nie różni się. Przecież ta lamda/callback, to wyłącznie inny sposób zapisu nowej klasy implementującej jakiś interface funkcyjny. Możesz dokładnie tą samą logikę zapisać jako lambdę, klasę anonimową, albo utworzyć sobie klasę, której instancje będą przyjmowane w miejsce tej lambdy soLid jak w mordę strzelił. Czy jak coś jest zgodne z SOLID, to jest też zgodne z OOP?

Według mojej wiedzy, nie ma aktualnie żadnego popularnego języka, który jest w 100% obiektowy. Co dla przykładu robią w Javie metody statyczne, pola statyczne, typy prymitywne itd? Czy funkcje z kotlina można wcisnąć w nazwę "object oriented programing"?

Moim zdaniem nie.

OK, twoim zdaniem, bo to kwestia opinii, a nie faktów. Ja nie wiem - nie natknąłem się jeszcze na przypadek, kiedy musiałbym wyrobić sobie zdanie

No i Math na pewno nie jest obiektowe.

O, i w końcu się w czymś zgadzamy :)

A w temacie - strategia to dla mnie wzorzec w pełni obiektowy, ponieważ w moim rozumieniu wypełnia całkowicie założenia paradygmatu OOP. Pisze o klasycznych, wzorcowych metodach implementacji.

Argument jakiś za tym? Mówiłeś już 10 razy że spełnia, ale nie podajesz żadnego argumentu za tym. Daj mi powód.

Klasa gospodarza jest (albo powinna być) zgodna z OOP, bo nic nie stoi na przeszkodzie, żeby wewnątrz łączyła dane, logikę, która te dane zmienia. Może też korzystać z innych obiektów, takich jak ta wstrzykiwana strategia. Strategia też może i powinna realizować postulaty SOLID, jest obiektem (w językach "czysto" obiektowych), enkapsuluje w sobie wiedzę jak coś zrobić.

Pytanie, które nie daje mi spokoju - rozumiem dyskusje o rzeczach pozbawionych znaczenia, ale właściwie o co chodzi? Wstąpiłeś do jakiegoś kościoła, w którym można jeść mięso w piątek, ale za pisanie nie-OOP idzie się do piekła?