Strategia w programowaniu obiektowym

Wydaje mi się że strategia nie wpisuje się w programowanie obiektowe.

Bo ostatecznie strategia to dostarczenie dwóch implementacji jakiegoś algorytmu, do użycia przez inną klasę, ale przecież sam algorytm strategi niczego nie enkapsuluje, więc nie może być obiektem.

No bo jak stworzę dwie instancje tej samej strategii, to one będą identyczne. Nie będę mógł nigdy mieć dwóch instancji z różnmi tożsamościami, a to mi nie pasuje do obiektówki.

Dobrze myślę? Czy coś mi uciekło.

Czy strategia to jest ten pattern, za pomocą którego wyznawcy OOP symulują zwykłe callbacki?

W sensie, czy funkcję sortByAbs można nazwać implementacją strategii?

const array = [10, -2, 6, -5, 8, -100];
const sortByAbs = (a, b) => Math.abs(a) - Math.abs(b); // strategia?
array.sort(sortByAbs);
console.log(array); // [ -2, -5, 6, 8, 10, -100 ]

Jeśli tak, to myślę, że można powiedzieć, że ten pattern enkapsuluje wymienialną logikę (tutaj: konkretny sposób sortowania).

LukeJL napisał(a):

Jeśli tak, to myślę, że można powiedzieć, że ten pattern enkapsuluje wymienialną logikę (tutaj: konkretny sposób sortowania).

Załóżmy na potrzeby tego wątku, że kiedy mówię "enkapsulować coś" to mam na myśli "enkapsulować dane, parametry, wartości".

sam algorytm strategi niczego nie enkapsuluje, więc nie może być obiektem.

Dlaczego nie? Przecież algorytm może mieć swoje parametry, które może enkapsulować.

LukeJL napisał(a):

Czy strategia to jest ten pattern, za pomocą którego wyznawcy OOP symulują zwykłe callbacki?

W sensie, czy funkcję sortByAbs można nazwać implementacją strategii?

const array = [10, -2, 6, -5, 8, -100];
const sortByAbs = (a, b) => Math.abs(a) - Math.abs(b); // strategia?
array.sort(sortByAbs);

Raczej nie.

Strategią byłoby gdybyś za pomocą tego callbacka mógł wybrać czy sortowanie będzie np bubble sort vs quick sort. To czy sortujesz rosnąco lub malejąco, to raczej nie jest strategia.

Spearhead napisał(a):

sam algorytm strategi niczego nie enkapsuluje, więc nie może być obiektem.

Dlaczego nie? Przecież algorytm może mieć swoje parametry, które może enkapsulować.

Tak, i jeśli dostałby jakieś parametry to byłoby obiektem, wtedy spoko.

Ale ja mówię o takich "bezparametrowych" strategiach.

Strategia w programowaniu obiektowym jak najbardziej występuje.
To jeden z najczęściej wykorzystywanych wzorców przeze mnie.
Już sam routing w dowolnym frameworku to jest strategia właśnie.
Przykładowo strategie możesz mieć dla każdego typu enum.
Masz załóżmy 3 typy userów client, admin, seller i dla każdego robisz sobie oddzielną strategię, która załóżmy przy rejestracji robi inne rzeczy, wyświetla inne widoki userom, czy sprawdza uprawnienia, do tych trzech rzeczy może być po jednej klasie strategii, dla każdego typu z trzema takimi samymi metodami, ale mającymi inną logikę.

Swoją drogą wystarczy wpisać w googlach jak działa strategia.
Wszyscy gadają o wzorcach nie wiadomo ile, a tu z takim podstawowym wzorcem problem.

omenomn2 napisał(a):

Strategia w programowaniu obiektowym jak najbardziej występuje.
To jeden z najczęściej wykorzystywanych wzorców przeze mnie.

Jesteś pewien że ten kod jest obiektowy? Masz jak pokazać?

No jeżeli używam klasy z metodami, to tak jest to kod obiektowy.

Aha, czyli jeżeli zrobię klasę ClientStrategy z metodami register(), view(), can() i utworzę drugą klasę AdminStrategy z takimi samymi metodami i teraz w zależności od typu wywołam strategię (obiekt!!!), a następnie metodę to według Ciebie to nie jest obiektowy kod?
Jeśli nie, to może najpierw zapoznaj się z definicjami programowania obiektowego, a dopiero później jakieś wzorce ogarniaj, po kolei!

omenomn2 napisał(a):

Aha, czyli jeżeli zrobię klasę ClientStrategy z metodami register, view, can i utworzę drugą klasę AdminStrategy z takimi samymi metodami i teraz w zależności od typu wywołam strategię (obiekt!!!), a następnie metodę to według Ciebie to nie jest obiektowy kod?

Nope.

To o czym mówisz to polimorfizm, po prostu.

Jeśli nie, to może najpierw zapoznaj się z definicjami programowania obiektowego, a dopiero później jakieś wzorce ogarniaj, po kolei!

No jeśli ktoś uważa że programowanie obiektowe, to jest po prostu używanie obiektów, to dziękuję Panu za taką opinię. Może jeszcze powiesz że jak używasz funkcji, to to jest programowanie funkcyjne?

Dziękuję za Twój wkład w ten wątek, ale proszę, wstrzymaj się już od odpowiedzi w nim, bardzo proszę.