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".