Strategia w programowaniu obiektowym

Riddle napisał(a):

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?

Mam namyśli takie które nie posiadają danych jak Servisy w Javie, I czyste funkcje, które z powodów implementacyjnych są obiektami. Ale odpowiedzieć na twoje pytanie jest mi trudno no bo czy serwis

class MyService {
  String MY_CONST = "WriteOnly.pl"
  // miejsce na metody
}

przestał byc bezstanowy, bo mam zdefiniowaną jedną stałą? Raczej nie. Więc chodzi mi o wszystkie które nie są mutable

KamilAdam napisał(a):

Ale odpowiedzieć na twoje pytanie jest mi trudno no bo czy serwis

class MyService {
  String MY_CONST = "WriteOnly.pl"
  // miejsce na metody
}

przestał byc bezstanowy, bo mam zdefiniowaną jedną stałą? Raczej nie. Więc chodzi mi o wszystkie które nie są mutable

Moim zdaniem nie przestał, bo nadal new MyService() == new MyService(). Nadal posiadanie jednej instancji niczym się nie różni od posiadania wielu. Więc moim zdaniem to też jest nieobiektowe.

Riddle napisał(a):

Moim zdaniem nie przestał, bo nadal new MyService() == new MyService(). Nadal posiadanie jednej instancji niczym się nie różni od posiadania wielu. Więc moim zdaniem to też jest nieobiektowe.

Z tym new MyService() == new MyService() to uważaj bo w Javie zwróci to false :D Oczywiście wiem że szczegół implementacyjny :P
Hm, z drugiej strony jak się dla nich zaimplementuje equals to będą się zachowywać tak samo jak new MyRecordWithDifaults().equals(new MyRecordWithDifaults())

KamilAdam napisał(a):

Riddle napisał(a):

Moim zdaniem nie przestał, bo nadal new MyService() == new MyService(). Nadal posiadanie jednej instancji niczym się nie różni od posiadania wielu. Więc moim zdaniem to też jest nieobiektowe.

Z tym new MyService() == new MyService() to uważaj bo w Javie zwróci to false :D Oczywiście wiem że szczegół implementacyjny :P
Hm, z drugiej strony jak się dla nich zaimplementuje equals to będą się zachowywać tak samo jak new MyRecordWithDifaults() == new MyRecordWithDifaults()

Chodzi mi po prostu o to, że zadziałałyby tak samo. Nie ważne czy wywołam coś na instancji którą już mam, czy stworzę nową, to one są takie same.

I nie pasuje mi to do paradygmatu obiektowego.

Riddle napisał(a):

Chodzi mi po prostu o to, że zadziałałyby tak samo. Nie ważne czy wywołam coś na instancji którą już mam, czy stworzę nową, to one są takie same.

I nie pasuje mi to do paradygmatu obiektowego.

A to ci pasuje do paradygratu obiektowego:

class Pies(imie: String = "burek") {
  def szczekaj = println("wof, wof")
  def szczekajSwojeImie = println(s"wof, wof $imie")
}

new Pies().szczekaj
new Pies().szczekajSwojeImie

new Pies().szczekaj
new Pies().szczekajSwojeImie

new Pies("max").szczekaj
new Pies("max").szczekajSwojeImie

?

Różnica jest tylko w ostatnim szczekajSwojeImie. To by znaczyło że szczekaj jest nieobiektowe, a szczekajSwojeImie jest obiektowe?

KamilAdam napisał(a):

Riddle napisał(a):

Chodzi mi po prostu o to, że zadziałałyby tak samo. Nie ważne czy wywołam coś na instancji którą już mam, czy stworzę nową, to one są takie same.

I nie pasuje mi to do paradygmatu obiektowego.

A to ci pasuje do paradygratu obiektowego:

class Pies(imie: String = "burek") {
  def szczekaj = println("wof, wof")
  def szczekajSwojeImie = println(s"wof, wof $imie")
}

new Pies().szczekaj
new Pies().szczekajSwojeImie

new Pies().szczekaj
new Pies().szczekajSwojeImie

new Pies("max").szczekaj
new Pies("max").szczekajSwojeImie

?

Nie lubię implicit argumentów, ale tak.

To mi już pasuje, bo new Pies() to tak na prawdę new Pies("burek").

Riddle napisał(a):

Nie lubię implicit argumentów, ale tak.

To mi już pasuje, bo new Pies() to tak na prawdę new Pies("burek").

W Scali to jest Default Parameter Values. Implicit Parameter to by był:

class Pies(implicit val imie: String) {
  def szczekaj = println("wof, wof")
  def szczekajSwojeImie = println(s"wof, wof $imie")
}

implicit val imie = "burek"

new Pies().szczekaj
new Pies().szczekajSwojeImie

new Pies().szczekaj
new Pies().szczekajSwojeImie

new Pies("max").szczekaj
new Pies("max").szczekajSwojeImie

:P

KamilAdam napisał(a):

W Scali to jest Default Parameter Values. Implicit Parameter to by był:

Jejku.

Pisząc:

Riddle napisał(a):

Nie lubię implicit argumentów, ale tak.

Miałem na mysli "Nie lubię takich argumentów które można podać, ale jak się ich nie poda to wtedy to jest to samo co jakby się podało jakiś konkretny, ukryty argument".

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

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?

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?

Moim zdaniem uczepiłeś się trochę tej enkapsulacji i uważasz ją za warunek konieczny do uznania czegoś za OOP. Ale niech będzie.
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.
Jeżeli masz Strategię, to obiekt gospodarza dostaje obiekt z zewnątrz ze znanym interfejsem. Możesz tam mieć albo jakieś mega rozbudowane struktury, albo zwykłe return a+b. Nie ma znaczenia, tak długo jak patrząc z punktu widzenia gospodarza nie musisz wiedzieć co tam w środku się znajduje - algorytmy, dane, pola, AI, dzikie węże. Czyli z mojego punktu widzenia spełnia to warunki enkapsulacji. Jeżeli z twojego punktu widzenia, enkapsulacja jest wymagana do uznania czegoś za zgodne z paradygmatem obiektowym, to strategia jest z nim zgodna.