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

Strategia w programowaniu obiektowym

0
fun firstName(fullName):<Context, Result>{
  return Pair(fullName, fullName.split(" ")[0])
}

fun lastName(fullName)<Context, Result>{
  return Pair(fullName, fullName.split(" ")[1])
}
....
fun jakaśFunkcja(fullName) {
  val a = firstName(fullName)
  val firstName = a.last
  val lastName = lastName(a.first)
....
}

@Riddle: Tak, jest brzydko. Ale się da. I nie ma sensu, bo fullName się nie zmienia, ale tak samo można przekazać cały stan dowolnego obiektu, juz po zmianie.

0

Dokładnie. pop() w stosie jest nieobiektowy. Żeby był obiektowy powinno się zrobić last = stack.last(); stack.removeLast(); (gdzie removeLast()) zwraca void. Jeśli pop() coś usuwa i zwraca, to nie jest napisany w paradygmacie obiektowym, po prostu

@Riddle: Próbowałeś kiedyś programować coś wielowątkowego? Np sytuacja jeden producent, wielu konsumentów. Wszystko synchronizowane kolejką, ale konsumenci ściągają dane z kolejki kto pierwszy ten lepszy. I teraz spróbuj zaimplemntować to w OOP z last = stack.last(); stack.removeLast(). Czy to znaczy że OOP nie nadaje się do programowania wielowątkowania, Czy nie da się stworzyć kolejki do synchronizacji watków w OOP?

0
KamilAdam napisał(a):

Dokładnie. pop() w stosie jest nieobiektowy. Żeby był obiektowy powinno się zrobić last = stack.last(); stack.removeLast(); (gdzie removeLast()) zwraca void. Jeśli pop() coś usuwa i zwraca, to nie jest napisany w paradygmacie obiektowym, po prostu

@Riddle: Próbowałeś kiedyś programować coś wielowątkowego? Np sytuacja jeden producent, wielu konsumentów. Wszystko synchronizowane kolejką, ale konsumenci ściągają dane z kolejki kto pierwszy ten lepszy. I teraz spróbuj zaimplemntować to w OOP z last = stack.last(); stack.removeLast(). Czy to znaczy że OOP nie nadaje się do programowania wielowątkowania, Czy nie da się stworzyć kolejki do synchronizacji watków w OOP?

Twoje pytanie tak na prawdę brzmi "Czy to znaczy że CQS nie nadaje się do programowania wielowątkowania, Czy nie da się stworzyć kolejki do synchronizacji watków w CQS?"

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

Dokładnie. pop() w stosie jest nieobiektowy. Żeby był obiektowy powinno się zrobić last = stack.last(); stack.removeLast(); (gdzie removeLast()) zwraca void. Jeśli pop() coś usuwa i zwraca, to nie jest napisany w paradygmacie obiektowym, po prostu

@Riddle: Próbowałeś kiedyś programować coś wielowątkowego? Np sytuacja jeden producent, wielu konsumentów. Wszystko synchronizowane kolejką, ale konsumenci ściągają dane z kolejki kto pierwszy ten lepszy. I teraz spróbuj zaimplemntować to w OOP z last = stack.last(); stack.removeLast(). Czy to znaczy że OOP nie nadaje się do programowania wielowątkowania, Czy nie da się stworzyć kolejki do synchronizacji watków w OOP?

Twoje pytanie tak na prawdę brzmi "Czy to znaczy że CQS nie nadaje się do programowania wielowątkowania, Czy nie da się stworzyć kolejki do synchronizacji watków w CQS?"

Zgadza się, ale z twojej definicji OOP zrozumiałem że CQS jest warunkiem koniecznym OOP. WIęc jeśli nie da się programować wielowątkowo używając CQS, to nie da się też programować wielowątkowo używając OOP

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

Dokładnie. pop() w stosie jest nieobiektowy. Żeby był obiektowy powinno się zrobić last = stack.last(); stack.removeLast(); (gdzie removeLast()) zwraca void. Jeśli pop() coś usuwa i zwraca, to nie jest napisany w paradygmacie obiektowym, po prostu

@Riddle: Próbowałeś kiedyś programować coś wielowątkowego? Np sytuacja jeden producent, wielu konsumentów. Wszystko synchronizowane kolejką, ale konsumenci ściągają dane z kolejki kto pierwszy ten lepszy. I teraz spróbuj zaimplemntować to w OOP z last = stack.last(); stack.removeLast(). Czy to znaczy że OOP nie nadaje się do programowania wielowątkowania, Czy nie da się stworzyć kolejki do synchronizacji watków w OOP?

Twoje pytanie tak na prawdę brzmi "Czy to znaczy że CQS nie nadaje się do programowania wielowątkowania, Czy nie da się stworzyć kolejki do synchronizacji watków w CQS?"

Zgadza się, ale z twojej definicji OOP zrozumiałem że CQS jest warunkiem koniecznym OOP. WIęc jeśli nie da się programować wielowątkowo używając CQS, to nie da się też programować wielowątkowo używając OOP

Tak, jesli nie da się w CQS, to nie da się też w OOP, a jeśli da się w CQS, to da się też w OOP.

Mogę z tym żyć.

Bo to co teraz robisz, Twój arugment to jest zrobienie czegoś takiego:

  • Wymyśl standardowy scenariusz (nie obiektowy), np taki ze stosem
  • Usłysz zasady obiektowe
  • Przerób standardowy nieobiektowy scenariusz, względem zasad obiektowych
  • Dostań coś co nie ma sensu
  • Krytykuj rezultat.

Coś co opisywałem dokładnie tutaj: Strategia w programowaniu obiektowym

Jakbym wziął nie funkcyjny kod (imperatywny and/or proceduralny kod), i wprowadził do niego zasadę "nie redefiniuj zmiennych", i ktoś po prostu ślepo wprowadziłby te zasady do kodu, to też dostałbyś głupi wynik, który mógłbyś krytykować.

Kluczem jest tutaj nie a) weź nieobiektowe rozwiązanie b) próbuj przerobić go na OP c) krytykuj wynik; tylko rozwiązaniem byłoby raczej - a) Zaprojektuj obiektowe rozwiązanie problemu o którym mówisz. I to rozwiązanie, raczej nie wyglądałoby jak stos.

Bezowocnym jest zmienić paradygmat, i spodziewać się efektu podobnego do tego przed zmianą paradygmatu

To jest cały sens. Zmienić paradygmat, to zmienić sposób implementacji róznych rozwiązań. To nie jest po prostu "ślepe podporządkowanie się pod arbitralne zasady".

4
Riddle napisał(a):
jarekr000000 napisał(a):

Po prostu zredaguj tą definicję, bo coś miałeś na myśli, ale logicznie wyszło bez sensu. (BTW. robienie takich definicji jest trudne).

No dobra. To spróbjmy kryteria

Moim zdaniem. Kod obiektowy to kod w którym spełniony jest każdy z warunków:

  • Nie występuje deklaracja żadnych funkcji statycznych (ale można ich użyć jako szczegół implementacyjny jakiegoś obiektu, w taki sposób żeby klienci obiektu o nim nie wiedzieli)
  • Dziedziczenie jest używane tylko jako szczegół implementacyjny, nie jako współdzielenie interfejsu
  • Nie występują obiekty, które można bez strat w logice sprowadzić do postaci funkcji (np obiektów które nie przyjmują nic przez parametr konstruktora).
  • Operacje na danych nie powinny być przeprowadzone na więcej niż jednym poziomie abstrakcji (np nie powinno się używać tego samego obiektu do okreslenia extensionu jak i mime'type'u).
    • Dla przykładu, jeśli dostajemy jedną daną (np Pesel) i z niego chcemy odczytać w programie datę urodzenia, wiek oraz płeć, to musimy stworzyć trzy obiekty które dostają ten pesel, jeden pozwala nam odczytać datę urodzenia, jeden wiek, a jeden płeć, i są przekazywane tam, gdzie każde z tych miejsc wymaga tych danych. Jeśli inny obiekt wymaga ich trzech, to powinny zostać skomponowane w czwarty obiekt, z którego można odczytać każdą z tych danych, ale który nie wie nic o peselu.
  • null nie jest używany jako wartość sama w sobie (tylko jest przekazywany jako parametry obiektu, który prezentuje zachowanie sugerujące "brak wartości")
  • Wartości nie są przekazywane bez obiektów (np publiczne stałe).
  • Metoda obiektu zwracająca wartość nie ma side-effectów (zmiany stanu obiektu lub stanu systemu).
  • Metoda zmieniająca stan obiektu lub systemu ma return-type void.
  • Nie zachodzi metaprograming (refleksje, kontenery zależnosci, switch na .class/::class/get_class(), Mickito)
  • Nie występuje rzutowanie typów
  • Nie występuje instanceof (chyba że jako szczegół implementacyjny pojedynczego obiektu, użyte na wartości zwróconej przez biblioteki, bez możliwości ominięcia go. Wtedy taką klasę na której się robi instanceof traktuje się jako gołą daną, i nie jest obiektem w rozumieniu OOP)
  • Klasy są albo final/sealed/nie open, albo abstract/interface.
    Możliwe że dopiszę coś więcej, jak o tym pomyślę.

No to jedziemy.
Rzucam kod hipotetycznie obiektowy

 10 REM Basic version of 99 bottles of beer
 20 REM Modified by M. Eric Carr ([email protected])
 30 REM from prior version found on this site.
 40 REM (Modified to correct "1 bottle" grammar)
 50 FOR X=99 TO 1 STEP -1
 60 PRINT X;"bottle";
 70 IF X<>1 THEN PRINT "s";
 80 PRINT " of beer on the wall,";X;"bottle";
 90 IF X<>1 THEN PRINT "s";
100 PRINT " of beer"
110 PRINT "Take one down and pass it around,"
120 PRINT X-1;"bottle";
130 IF X<>1 THEN PRINT "s";
140 PRINT " of beer on the wall"
150 NEXT

Na razie nie znajduję, które punkty łamie (ale może jestem nieuważny).

0
jarekr000000 napisał(a):

No to jedziemy.
Rzucam kod hipotetycznie obiektowy

 10 REM Basic version of 99 bottles of beer
 20 REM Modified by M. Eric Carr ([email protected])
 30 REM from prior version found on this site.
 40 REM (Modified to correct "1 bottle" grammar)
 50 FOR X=99 TO 1 STEP -1
 60 PRINT X;"bottle";
 70 IF X<>1 THEN PRINT "s";
 80 PRINT " of beer on the wall,";X;"bottle";
 90 IF X<>1 THEN PRINT "s";
100 PRINT " of beer"
110 PRINT "Take one down and pass it around,"
120 PRINT X-1;"bottle";
130 IF X<>1 THEN PRINT "s";
140 PRINT " of beer on the wall"
150 NEXT

Na razie nie znajduję, które punkty łamie (ale może jestem nieuważny).

To be honest, to ja powiedziałbym że on jest obiektowy. Iteracja, if i w sumie tyle. Także, w moim projekcie, powiedziałbym że to może uchodzić za obiektowy kod. Moim zdaniem ten kod jest obiektowy, mimo że nie ma obiektów w nim. Nie ma nic, co możnaby sensownie wydzielić.

Podobnego argumentu użyłbym, żeby spytać: czy ten kod jest funkcyjny:

print(2 + 3)

Moim zdaniem chyba tak, mimo że nie ma deklaracji funkcji w nim, bo nie ma co sensownie z niego wydzielić.

Idąc dalej tą karuzelą śmiechu, można założyć że pusty program (0 linijek, nic nie robi, tylko się bierze i wyłącza) pasuje do każdego paradygmatu świata

2
Riddle napisał(a):
jarekr000000 napisał(a):

No to jedziemy.
Rzucam kod hipotetycznie obiektowy

 10 REM Basic version of 99 bottles of beer
 20 REM Modified by M. Eric Carr ([email protected])
 30 REM from prior version found on this site.
 40 REM (Modified to correct "1 bottle" grammar)
 50 FOR X=99 TO 1 STEP -1
 60 PRINT X;"bottle";
 70 IF X<>1 THEN PRINT "s";
 80 PRINT " of beer on the wall,";X;"bottle";
 90 IF X<>1 THEN PRINT "s";
100 PRINT " of beer"
110 PRINT "Take one down and pass it around,"
120 PRINT X-1;"bottle";
130 IF X<>1 THEN PRINT "s";
140 PRINT " of beer on the wall"
150 NEXT

Na razie nie znajduję, które punkty łamie (ale może jestem nieuważny).

To be honest, to ja powiedziałbym że on jest obiektowy. Iteracja, if i w sumie tyle. Także, w moim projekcie, powiedziałbym że to może uchodzić za obiektowy kod. Moim zdaniem ten kod jest obiektowy, mimo że nie ma obiektów w nim. Nie ma nic, co możnaby sensownie wydzielić.

No to mamy wreszcie jakąś spójną definicję obiektowości i cieszy mnie, że mój ukochany BASIC z C64 się załapał (nie wiem czy każdy program w BASICU, ale z tego co widzę powyżej to dużo się załapie)

Podobnego argumentu użyłbym, żeby spytać: czy ten kod jest funkcyjny:

print(2 + 3)

A to akurat zależy. Zależy jak wygląda sygnatura funkcji print.
Jeśli print zwraca void czy coś w tym stylu, to można domniemywać, że nie jest to kod funkcyjny.

0
jarekr000000 napisał(a):

No to mamy wreszcie jakąś spójną definicję obiektowości i cieszy mnie, że mój ukochany BASIC z C64 się załapał (nie wiem czy każdy program w BASICU, ale z tego co widzę powyżej to dużo się załapie)

Od razu mówię, że według mnie nie ma czegośtakiego jak "język obiektowy", pisałem już o tym wyzej.

Mogę Ci powiedzieć czy kod który napisałeś jest obiektowy czy nie.

Ja o tym myślę w taki sposób. Czy istnieje coś takiego jak bezpieczny język? Taki język, w którym da się napisać tylko bezpieczny kod, a niebezpiecznych się nie da? Moim zdaniem nie ma czegoś takiego.

Podobnie, jak nie ma języków obiektowych, w których da się napisać kod tylko obiektowy, a nie obiektowych się nie da.

4
Riddle napisał(a):
jarekr000000 napisał(a):

No to mamy wreszcie jakąś spójną definicję obiektowości i cieszy mnie, że mój ukochany BASIC z C64 się załapał (nie wiem czy każdy program w BASICU, ale z tego co widzę powyżej to dużo się załapie)

Od razu mówię, że według mnie nie ma czegośtakiego jak "język obiektowy", pisałem już o tym wyzej.

Mogę Ci powiedzieć czy kod który napisałeś jest obiektowy czy nie.

Oczywiście.
Aczkolwiek, zgodnie z tą definicją to w zasadzie nie da się napisać w tym BASICu kodu, który nie byłby obiektowy. A to mi wystarcza. Oznacza, że byłem programistą obiektowym zanim to było modne.

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