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)