Wątek przeniesiony 2022-06-21 17:19 z Kosz przez Adam Boduch.

Strategia w programowaniu obiektowym

0

No jeśli ktoś uważa że programowanie obiektowe, to jest po prostu używanie obiektów, to dziękuję Panu za taką opinię

No, bo dokładnie tak jest.

2

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.

a czemu nie? jeżeli tym algorytmem byłby jakiś złożony parser - pdf | worda(rtf) | worda(docx), to jak najbardziej pod spodem, za publicznym API może dziać się wiele - tymczasowa tablica danych wypełniana i używana w czasie jednego przejścia, indeksy, aktualny stan FSM, itd.

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.

Czyli Singleton na ratunek algorytmom?

0

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.

Nie muszą być identyczne, można wstrzykiwać do straregii do konstruktora np. model z wiersza bazy danych, i wtedy jak utworzysz dwie strategie z dwoma różnymi modelami, to będą mogły zwracać różne rzeczy i jeszcze w zależności od danej strategii.

Tak to jest programowanie obiektowe spełnione w 3 kwestiach czyli: atrybuty, metody i przechowywany stan, przechowywanym stanem w tym przypadku jest model zapisany w atrybucie przez konstruktor.

0
Riddle napisał(a):

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

Masz jakiegoś NPC w grze, wstrzykujesz mu strategię ruchu. Możesz utworzyć wiele instancji tego obiektu, ale z różnymi parametrami (stanem).:

public int steps
public String getNextStep(...){
return "w lewo"+steps+" kroków";
}

Możesz też zmieniać te parametry w trakcie życia samej strategii, albo nawet podmienić całą strategię w trakcie życia obiektu "gospodarza".

5
Riddle napisał(a):

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.

Konkretna implementacja strategii jak najbardziej enkapsuluje algorytm. Nie wynika z tego oczywiście obiektowość. Tak samo jak z braku enkapsulacji nie wynika brak obiektowości.

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.

Niektóre będą, inne nie będą.
Z tego, że w szczególnym przypadku można mieć implementację strategii, która nie posiada stanu nie sprawia, że to nie jest programowanie obiektowe.
Zwłaszcza, że klient strategii musi mieć do niej referencję, a więc ma już stan.

Próbujesz udowodnić, że jeśli np. jeden obiekt w programie nie posiada w stanu, to cały program nie jest obiektowy?

0

Kiedy mówię "enkaosulacja" mam na myśli hermetyzację parametrów, wartości danych, nie zachowania.

Jeśli stragia może nie przyjmować żadnych wartości i nadal być obiektowa, to znaczy to że wszystkie klasy mogłyby nie enkaosulować nic, i nadal być obiektowe.

A skoro tak, to można by napisać całą aplikacje nie enkapsulujac nic, i nazwać ją obiektową.

A to mi się nie wydaje prawdziwe.

0
Riddle napisał(a):

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

łoł, będzie tu ostro

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.

Hm, czy widzisz tu podobieństwo do wizytatora? A jeśli widzisz to czy wizytator tez będzie nieobiektowy?
Nie obiektowe będą też bezstanowe serwisy w Javie. i mozliwe że wszystkie obiekty bezstanowe

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.

Czy dotyczy to wszystkich obiektów które nie mają tożsamości, jak obiekty wartości (Value Object), rekordy w Javie, data class w Kotlinie, case class w Scali?

Czy wzorzec Pyłek to w takim razie wzorzec niszczenia obiektowości? Służy on przecież do cachowania obiektów wartości?

Czy wzorzec Prototyp też jest nieobiektowy? Też ważny jest tylko jego stan przed skopiowaniem a nie jego tożsamość

Pytanie nie na temat: czy metoda copy dla data class w Kotlinie i case class w Scali jest przykładem wzorca Prototyp? (Wiem że klasyczny prototyp zakłada najpierw skopiowanie, a potem modyfikacje, jednak metoda copy robi to jednocześnie)

2
Riddle napisał(a):

Kiedy mówię "enkaosulacja" mam na myśli hermetyzację parametrów, wartości danych, nie zachowania.

Jeśli stragia może nie przyjmować żadnych wartości i nadal być obiektowa, to znaczy to że wszystkie klasy mogłyby nie enkaosulować nic, i nadal być obiektowe.

W tym przypadku popełniasz błąd logiczny.
Fakt, że istnieje grupa obiektów, która może nie przyjmować żadnych wartości i nadal być obiektowa nie oznacza, że możesz z takich obiektów zbudować aplikację.

To tak, jakbyś powiedział, że jeśli człowiek składa się w 70% z wody to nic nie stoi na przeszkodzie, żeby wyłącznie z wody zbudować człowieka.

0
KamilAdam napisał(a):
Riddle napisał(a):

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

łoł, będzie tu ostro

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.

Hm, czy widzisz tu podobieństwo do wizytatora? A jeśli widzisz to czy wizytator tez będzie nieobiektowy?
Nie obiektowe będą też bezstanowe serwisy w Javie. i mozliwe że wszystkie obiekty bezstanowe

Te serwisy w Javie tak, na pewno są nieobiektowe.

"Bezstanowe" masz na myśli takie które niczego nie enkapsulują czy takie które nie są mutable?

Co do wizytora, nie pamiętam kiedy zrobiłem wizytora który by czegoś nie enkaosulował, ale w strategi to normalne. W świecie lambd, trudno odróżnić strategie od callback'a.

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.

Czy dotyczy to wszystkich obiektów które nie mają tożsamości, jak obiekty wartości (Value Object), rekordy w Javie, data class w Kotlinie, case class w Scali?

Czemu mają nie mieć tożsamości? Dwa Value Object mogą mieć różne dane i tym samym są inne od siebie.

Czy wzorzec Pyłek to w takim razie wzorzec niszczenia obiektowości? Służy on przecież do cachowania obiektów wartości?

No ale z zewnątrz zachowuje się jak obiekt. Klient jakiegoś interfejsu nie musi wiedzieć czy on jest pyłkiem czy nie.

Czy wzorzec Prototyp też jest nieobiektowy? Też ważny jest tylko jego stan przed skopiowaniem a nie jego tożsamość

Trzeba by się zastanowić. Nie wiem.

Pytanie nie na temat: czy metoda copy dla data class w Kotlinie i case class w Scali jest przykładem wzorca Prototyp? (Wiem że klasyczny prototyp zakłada najpierw skopiowanie, a potem modyfikacje, jednak metoda copy robi to jednocześnie)

0
wartek01 napisał(a):
Riddle napisał(a):

Kiedy mówię "enkaosulacja" mam na myśli hermetyzację parametrów, wartości danych, nie zachowania.

Jeśli stragia może nie przyjmować żadnych wartości i nadal być obiektowa, to znaczy to że wszystkie klasy mogłyby nie enkaosulować nic, i nadal być obiektowe.

W tym przypadku popełniasz błąd logiczny.
Fakt, że istnieje grupa obiektów, która może nie przyjmować żadnych wartości i nadal być obiektowa nie oznacza, że możesz z takich obiektów zbudować aplikację.

To tak, jakbyś powiedział, że jeśli człowiek składa się w 70% z wody to nic nie stoi na przeszkodzie, żeby wyłącznie z wody zbudować człowieka.

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.

W moim poście chodziło to, "Czemu miałoby się nie dać zbudować aplikacji z bezstanowych obiektów (tak by nadal była w paradgymacie obiektowym), skoro strategia rzekomo jest obiektowa a jest bezstanowa".

Próbowałem wykazać niemożliwość tego że strategia jest obiektowa, albo chociaż fakt że czymś ta strategia się musi różnić od innych obiektów. Tego żę albo jest jakaś granica pomiędzy "byciem strategią" a "nie byciem strategią", albo po prostu strategia jest nieobiektowa.

1 użytkowników online, w tym zalogowanych: 0, gości: 1