Strategia w programowaniu obiektowym

Programowanie obiektowe to nie jest "po prostu używanie klas", wbij sobie to do głowy. To jest paradygmat. Możesz używać klas, obiektów i dziedziczenia na dziesiątą stronę, a i tak stworzyć kod który nie jest obiektowy.

Tylko, że Ty ten paradygmat, który tak wielbisz, po prostu źle interpretujesz.
Nie jest używaniem klas, jest używaniem obiektów.
Obiekt nie musi dostać nic w konstruktorze i nadal jest to programowanie obiektowe.

jarekr000000 napisał(a):

Riddle napisał(a):

Kod wtedy jest obiektowy, kiedy dane przekazywane pomiędzy różnymi, bliskimi poziomami abstrakcji (i nie mam tu na myśli metod abstrakcyjnych), może być przedstawiona conajmniej jednym obiektem, który przyjmuje ten dane przez konstruktor.

@Riddle: Czyli każdy kod jest obiektowy? Czy też masz kontrprzykład kiedy dane przekazywane pomiędzy różnymi, bliskimi poziomami abstrakcji (i nie mam tu na myśli metod abstrakcyjnych), NIE MOGĄ być przedstawiona conajmniej jednym obiektem, który przyjmuje ten dane przez konstruktor.

To moim zdaniem jest przykład kodu który nie pasuje do tej definicji

def getMimeType(filename: str)->str:
    extension = getExtension(filename)
    if extension in ['jpg', 'jpeg', 'png', 'gif']:
        return 'image/'
    return 'application/x-'

def getExtension(filename:str) -> str:
    return # tutaj jakiś kod który wyciąga ostatnie znaki po kropce

Bo z poziomu abstrakcji "mime-type" do "filename oraz extension" przechodzisz stringiem, bez obiektu pomiedzy nimi.

Obiektowo byłoby tak

def getMimeType(filename: Filename)->str:
    if filename.extension() in ['jpg', 'jpeg', 'png', 'gif']:
        return 'image/'
    return 'application/x-'

class Filename:
  def getExtension() -> str:
    return # tutaj jakiś kod który wyciąga ostatnie znaki po kropce

@Riddle
No chwilę

1. String teź jest obiektem.
2. Skoro zrobiłeś wersję drugą gdzie jest ta klasa zkonstruktorem to okazało się, że może być przedstawiona conajmniej jednym obiektem, który przyjmuje ten dane przez konstruktor. - czyli kod pierwszy jest obiektowy.

Riddle napisał(a):

def getMimeType(filename: str)->str:
    extension = getExtension(filename)
    if extension in ['jpg', 'jpeg', 'png', 'gif']:
        return 'image/'
    return 'application/x-'

def getExtension(filename:str) -> str:
    return # tutaj jakiś kod który wyciąga ostatnie znaki po kropce

Bo z poziomu abstrakcji "mime-type" do "filename oraz extension" przechodzisz stringiem, bez obiektu pomiedzy nimi.

Co to za język? Python? Przecież w Pythonie (z tego co mi wiadomo) string też jest obiektem. Więc dlaczego obiekt string jest gorszy niż obiekt Filename?

jarekr000000 napisał(a):

@Riddle
No chwilę

1. String teź jest obiektem.

KamilAdam napisał(a):

Co to za język? Python? Przecież w Pythonie (z tego co mi wiadomo) string też jest obiektem. Więc dlaczego obiekt string jest gorszy niż obiekt Filename?

Mówiąc "obiekt" nie mam na myśli tego czy jakiś język sobie coś nazwał obiektem czy nie.

Kiedy mówię "obiekt", mam na myśli obiekt w rozumieniu paradygmatu obiektowego.

Czy str w pythonie jest obiektem?

• ie. Czy str można potraktować jako obiekt w rozumieniu elementu języka? Tak
• ie. Czy str można potraktować jako obiekt w rozumieniu paradygmatu obiektowego? Nie

Kiedy mówię o OOP, i używam określenia "obiekt" to mam na myśli to że biorę jakąś daną, opakowuję ją w klasię przekazując ją przez konstruktor, i wystawiam operacje na niej jako funkcje - to mam na mysli mówiąć "obiekt w OOP".

To czy w filozofii jakiegoś języka coś jest obiektem czy nie, to po prostu zbierzność nazw.

Riddle napisał(a):

• ie. Czy str można potraktować jako obiekt w rozumieniu paradygmatu obiektowego? Nie

Dlaczego?

KamilAdam napisał(a):

Riddle napisał(a):

• ie. Czy str można potraktować jako obiekt w rozumieniu paradygmatu obiektowego? Nie

Dlaczego?

Gdybym po prostu miał przekazać stringa w dół, to jeszce spoko.

Ale tutaj w jednym miejscu traktujesz go jak coś co ma rozszerze, a w drugim jak coś co ma mime-type. Zbyt duże uzależnienie danych od operacji na nich. Nie obiektowe IMO.

Nie można powiedzieć jednoznacznie czy "jakaś klasa jest obiektowa czy nie jest", sama w sobie. To w kompozycji tych klas (conajmniej dwóch) widać obiektówkę. IMO

Riddle napisał(a):

KamilAdam napisał(a):

Riddle napisał(a):

• ie. Czy str można potraktować jako obiekt w rozumieniu paradygmatu obiektowego? Nie

Dlaczego?

Bo nie opakowuje sobą żadnych danych, nie wystawia dostępu do nich na wyższym poziomie abstrakcji metodami.

Opakowuje np tablicę charów lub tablicę bajtów. (zależy od implementacji języka).

W tym drugim przypadku widać że dostarcza abstrakcję bo często (w Javie) str.length() jest różne od str.getBytes().length. Tą abstrakcją jest tutaj obsługa UTFa

Bo nie opakowuje sobą żadnych danych, nie wystawia dostępu do nich na wyższym poziomie abstrakcji metodami.

Czyli nie przyjmuje nic konstruktorze, niezła bzdura.
Czyli istnieją nieobiektowe obiekty, a niektóre samochody, są niesamochodowe, tak wynika z tego co pisze @Riddle .

Pomijając fakt, że połowa wzorców musiałaby być "nieobiektowa", bo nie tylko strategia nie wymaga wstrzyknięcia niczego w kostruktor.

Dekorator jest za to pół obiektowy, bo obiekt dekorowany nie przyjmuje nic do konstruktora, ale dekoratory już tak.

omenomn2 napisał(a):

Bo nie opakowuje sobą żadnych danych, nie wystawia dostępu do nich na wyższym poziomie abstrakcji metodami.

Czyli nie przyjmuje nic konstruktorze, niezła bzdura.
Czyli istnieją nie obiektowe obiekty, a niektóre samochody, są nie samochodowe, tak wynika z tego co pisze @Riddle .

Słuchaj! Ty myślisz o "kod obiektowy" w kontekście takim:

• "Czy jest użyte słowo class w kodzie?" - jeśli tak, to według @omenomn2 kod jest obiektowy.

Możesz sobie tak uważać, ale nie o tym w ogóle jest ta rozmowa! Mówisz nie na temat. To jest tak samo bezsensowne, jak jeśli znajdziesz funkcję w kodzie (nie ważne czy ma side-effecty czy nie, to to jest kod funkcyjny).

Rozmowa tyczy sie programowania obiektowego w kontekscie PARADYGMATU OBIEKTOWEGO.

Pomijając fakt, że połowa wzorców musiałaby być "nieobiektowa", bo nie tylko strategia nie wymaga wstrzyknięcia niczego w kostruktor.

Tak.

omenomn2 napisał(a):

Dekorator jest za to pół obiektowy, bo obiekt dekorowany nie przyjmuje nic do konstruktora, ale dekoratory już tak.

Dekorator może przyjąć obiekt, który przyjmuje np int albo string, powiedzmy.

new CacheMemory(new Memory(1024)).