🚀 go-pugleaf

Sektor van Skijlen wrote:

>> > Swiss army knife to by było, gdyby ten portfel mógł przechowywać
>> > pieniądze, laptopy, meble, samochody, kontenery i elektrownie.
> 
>> Nie. Swiss army knife oznacza, że modelujesz wszystkie elementy
>> rzeczywistości czy tego wymaga system czy nie.
> 
> Nie wiem, jak ty, ale ja pojęcie "swiss army knife" znam jako jeden z
> błędów OO, który polega na stworzeniu klasy o zbyt dużym zakresie
> odpowiedzialności.

Ja też. Dlaczego uważasz, że modelowanie większej części rzeczywistości
od wymaganej nie jest "zbyt dużym zakresem odpowiedzialności"?

> Dokładność modelowania to zupełnie inna sprawa.

Inny będzie poziom szczegółowości klasy Samochód w kartotece
samochodów w Urzędzie Miasta, a inny w kartotece warsztatu
samochodowego.

Mój kolega jakiś czas temu wymyślił dobry polski odpowiednik
swiss army knife: "przydaś". Bierze się to z podejścia "przyda się,
zaimplementuję".

> Zresztą, jeśli dla ciebie programowanie obiektowe jest modelowaniem
> rzeczywistości, to obawiam się, że możemy naszą dyskusję wznowić za parę
> lat, jak będziesz już mówił językiem własnego doświadczenia, a nie
> książkowym.

I znowu założenia... Załóż przez chwilę, że nie jesteś jednak
nieomylny.

> (Na marginesie: to bardzo dobrze, że literatura do OO twierdzi, że
> programowanie obiektowe jest modelowaniem rzeczywistości. Tak bowiem
> należy tą sprawę tłumaczyć początkującym. Im więcej jednak człowiek
> programuje obiektowo, tym bardziej się przekonuje, że to nie ma nic
> wspólnego z prawdą. To jest jeden ze znaków rozpoznawczych, czy ktoś
> potrafi myśleć samodzielnie rzeczywiście dysponuje doświadczeniem
> zawodowym, czy recytuje z pamięci wiedzę książkową.)

Dla mnie odnoszenie się do rzeczywistości jest wygodną praktyką
w takich bezsensownych dyskusjach jak ta. Podobnie jak to się czyni
w literaturze. Niektórzy jednak przyjmują książkowe przykłady
za pewnik: "tak należy modelować rzeczywiste systemy". I to jest
rzeczywiście smutne.

> 
> Cofając jednak tą całą dygresję, którą nie wiem po co wprowadziłeś -
> podałem ci tylko przykład, dlaczego portfel nie może być typem
> wartościowym.
> 
> Jeśli nie zrozumiałeś nadal, to wytłumaczę ci bardziej łopatologicznie:
> portfel zawierający tyle samo pieniędzy, to nie ten sam portfel (mówię
> tak, bo twierdziłeś, że ilość pieniędzy może być wartością potrfela).

Może być. Jeśli zastanawiałbym się "czy to ten sam portfel" to rozważałbym
tożsamość a nie wartość portfela. Rozumiesz?

>> > Ilość pieniędzy nie jest wartością portfela. Jest jego stanem. Portfel
>> > nie może mieć wartości - i to nie dlatego, że poza tym może mieć
>> > jeszcze wiele innych stanów i atrytbutów.

Taki podałeś wcześniej argument. Dla mnie podział na obiekty wartościowe
i niewartościowe jest sztuczny, żeby nie powiedzieć nieistniejący, więc
nie dziw się, że opornie podążam za tą teorią.

>> Wychodząc z tego założenia stanem "obiektu" "klasy" int jest np. 2. Stan
>> ten można zmienić "funkcją" zmiany stanu, np. ++.
>> Kto z nas nie rozróżnia wartości od stanu?
> 
> int x = 2;
> int y = 2;
> 
> Powiedz mi teraz, czy "x jest y".

W C++? Nie. Odsyłam do Stroustrupa jakie mechanizmy tego języka tutaj
zadziałały, a przestaniesz zadawać takie pytania.

>> >> > Typem wartościowym może być kolor. Porównanie dwóch obiektów typu
>> >> > kolor można porównać ze sprawdzeniem, czy na dwóch kartkach papieru
>> >> > zapisany tam kod koloru jest ten sam. Ty chcesz, żeby przed
>> >> > odczytaniem numeru z każdej kartki najpierw sprawdzić, czy te obie
>> >> > kartki to czasem nie jest jedna i ta sama kartka. Jaki to ma sens?
>> > 
>> >> Idąc Twoją logiką: niekoniecznie. Obiekt kolor ma jeszcze atrybuty:
>> >> data naniesienia, technika wykonania i stopień nasłonecznienia, które
>> >> pozwalają obliczyć rzeczywisty kolor w czasie :> Wtedy nie da się
>> >> porównać dwóch "czerwonych". Odsyłam do ekspertów - lakierników
>> >> samochodowych.
>> > 
>> > Nie przypominam sobie, żebym mówił o lakierze samochodowym. Mówiłem o
>> > kolorze. Kolor może być również atrybutem (a nie wartością, acz
>> > przypadkiem też nie stanem) lakieru.
> 
>> Ja tylko poszedłem Twoją logiką. Zważ, że w systemie, o którym pisałem
>> przy portfelu nie wspominałem o istnieniu kart kredytowych.
> 
> Nie poszedłeś moją logiką. Mówiłem o kolorze, a ty wziąłeś sobie nie wiem
> po co lakier samochodowy.

Oj, lakier to już była taka wisienka na torcie. Każdy kolor płowieje
w rzeczywistości, a więc... (odsyłam parę akapitów wyżej).

> Podobnie typem wartościowym mogą być "pieniądze". Ale nie kieszeń,
> portfel, konto, sejf, czy gdzie to tam jeszcze chcesz przechowywać.
> 
>> > No to jak, zrozumiałeś już, co to takiego jest wartość, czy douczysz
>> > się i zgłosisz za tydzień?
> 
>> Do kogo miałbym się zgłosić?
> 
> No cóż, wydawało mi się, że każdy, kto studiował, słyszał to słynne
> określenie. W czymś się widać pomyliłem.

Nie mierz innych swoją miarą. Nie przypominam sobie, żeby któryś z
wykładowców musiał się w ten sposób nade mną litować.

> 
>> >> >> Z tym, że w obu przypadkach nie chodzi o "przykrą konieczność", a
>> >> >> o "wspaniałą możliwość" szybkiego stwierdzenia, że chodzi o "te
>> >> >> same" a więc na pewno "takie same" obiekty.
>> >> > 
>> >> > To jest przykra konieczność. Musisz to po prostu zrobić, bo inaczej
>> >> > będzie wylot.
>> > 
>> >> W operatorze porównania? Nie sądzę...
>> > 
>> > W operatorze przypisania.
> 
>> Co miałoby sprawić "wylot" w operatorze przypisania?
> 
> Sprawdzenie, czy nie przypisujemy samego siebie. Fakt, że musisz użyć
> operatora porównania dla tożsamości jest przykrą koniecznością, bo bez
> tego usunąłbyś część obiektu, z którego za chwilę masz zamiar czytać.

Zagadnienie pomocnicze

int a;

a = a;

Pytanie: co nastąpi wcześniej odczyt czy zapis wartości a?
Ponawiam pytanie podstawowe: jaki wylot masz na myśli?

> 
>> >> > Ta "wspaniała możliwość" z kolei powoduje droższe porównanie.
>> > 
>> >> W pewnych przypadkach może tak być.
>> > 
>> > Statystycznie jest to 99% przypadków.
> 
>> Statystycznie, to ja biję swoją żonę co miesiąc. Ty, jeśli jesteś żonaty
>> również. Takie szacunki trzeba robić dla konkretnych klas a nie
>> generalizować.
> 
> No widzisz. A ja mogę sobie pozwolić na generalizację.

Możesz. Ale nie wpieraj, że jest ona poprawna.

> Chodzi o bardzo prostą rzecz: jakiej wielkości jest zwykle typ
> wartościowy? Niewielkiej. Musi być niewielki, bo im większy, tym więcej
> zasobów zajmuje jego wartość, dłużej się kopiuje, a i porównanie wartości
> - dosć częsta operacja - trwa dość długo. Dlatego właśnie typy wartościowe
> robi się z założenia JAK NAJMNIEJSZE - właśnie po to, żeby te operacje
> były jak najszybsze. Skoro istnieje taka presja na obiekty wartościowe, to
> gdzie masz w takim razie pole dla obiektów, w których porównanie można
> "przyspieszyć" poprzez najpierw sprawdzanie tożsamości?

To jest przypadek szczególny a nie ogólny. Nie twierdzę jednak, że przypadek
odwrotny, czyli taki jest ogólny, uniwersalny i najlepszy.

> 
>> >> Implementując operator warto
>> >> oszacować prawdopodobieństwo porównywania tych samych obiektów.
>> > 
>> > Zrób sobie małą statystykę użycia takiego typu i ilość porównań, dla
>> > których trafiasz na równość i dla których trafiasz na nierówność.
>> > 
>> > Prosty przykład - iteratory. Masz pętlę, w której przechodzisz przez
>> (...)
>> > 
>> > Podałem ci tylko przykład, jak należy prowadzić taką analizę - to, że
>> > ten przykład jest negatywny dla twojej tezy, nie ma znaczenia. Myślę,
>> > że dałoby się znaleźć przykład, który by twoją tezę potwierdzał, ale to
>> > nie ma większego znaczenia.
> 
>> Nie będę ani analizował Twojego przykładu, ani mu zaprzeczał. Zakładam,
>> że jest słuszny. To jednak tylko przykład, z którego do sformułowania
>> reguły jeszcze daleko.
> 
> To był przykład wykonania analizy, który pokazał, że się nie opłaca. Czy
> jesteśw stanie podać mi kontrprzykład - czyli taki, który udowodni, że się
> opłaca?

Proponuję przypomnieć sobie na czym polegał _dowód_, a nie przykład
potwierdzający słuszność danego twierdzenia.

>> > W odróżnieniu od ciebie jednak, ja rozumiem konieczność wykonania
>> > analizy, która dowiedzie, czy to się nam opłaca, czy nie. Ty
>> > przyjmujesz "w ciemno", że sprawdzanie najpierw tożsamości będzie
>> > zawsze bardziej opłacalne. W ostateczności zgadzasz się nawet, że
>> > "najczęściej".

Jeśli przyjmowanie w ciemno to f(n), to jesteś zaledwie na etapie f(n)-1.
Warto było się napracować?

>> Ty dla odmiany uważasz, że najczęściej nie. Na razie jednak nie potrafisz
>> udowodnić dlaczego Twoja teza jest lepsza od mojej.
> 
> Potrafię, tylko ty nie potrafisz jej zrozumieć, albo uparcie zaprzeczasz
> faktom.

Nie zaprzeczam, tylko wskazuję, że są to zaledwie pojedyncze fakty, a nie
ogólna zależność. Nawet nie: nie zaprzeczam zależności, ale Twojemu
sposobowi pseudodowodzenia.

> Moja teza jest lepsza, bo jest oparta na rzetelnej analizie (nb. analiza
> Qrczaka również). Twoja teza, że to jest "oczywiste, że tak się powinno
> zawsze robić" nie jest poparta niczym.

Nic takiego nie napisałem. Oczywiste jest dla mnie, że nie zawsze powinno
się robić tak jak Ty piszesz.

>> > No to podaj mi przykład typu wartościowego, w którym to się opłaca, i
>> > oszacuj ilość porównań trafionych i nietrafionych w typowych
>> > algorytmach, które go używają. Wtedy będziemy wiedzieli, o czym
>> > rozmawiamy.
> 
>> Nie chodzi o sam typ, tylko kontekst użycia.
> 
> Brawo! Zatem słucham.

Użycie typu jako klucza w hash mapie.

>> >> Generalnie jednak - nie zgadzam się.
>> > 
>> > Ależ masz pełne prawo się nie zgadzać. Ja w odróżnieniu od ciebie
>> > potrafię to uzasadnić.
> 
>> W odróżnieniu od Ciebie unikam jednoznacznych stwierdzeń na temat swoich
>> umiejętności.
> 
> Z tą "oczywistością", że operator porównania powinien najpierw sprawdzić
> tożsamość, niespecjalnie ci to wyszło.

W większości przypadków, jeśli analiza wykaże, że się opłaca. Nie przekręcaj
moich słów.

>> > Przykładowo, typ przechowywany w std::list musi być typem wartościowym.
>> > Niestety, tak jest skonstruowany szablon std::list. Świadczą o tym
>> > następujące wymagania względem typu:
>> >  - przypisywalny
>> >  - kopiowalny
>> >  - domyślnie-konstruowalny
> 
>> Rozumiem, że jeśli stworzę sobie jakiś widget, powiedzmy combo-box, który
>> spełnia powyższe wymagania, to nie będę mógł, go przechowywać w
>> std::list, bo pogwałcę Twoją teorię?
> 
> Nie. Bo jak wykonasz na nim algorytm std::remove, to zdrowo się zdziwisz,
> co po tym powstało.

Nie pisałem nic o chęci użycia któregokolwiek z algorytmów.

>> >> >> > Jeśli mówimy już o rzeczywistości - podaj mi przykład obiektu z
>> >> >> > rzeczywistości, który posiada jednocześnie wartość i tożsamość.
>> >> > 
>> >> >> Konto bankowe. Tożsamość: numer, wartość: saldo.
>> >> > 
>> >> > Oraz wartość: właściciel (można go potem kiedyś zmienić)
>> >> > Oraz obiekt: historia transakcji
>> >> > Oraz...
>> > 
>> >> Jak wyżej: zależy od kontekstu.
>> > 
>> > Nic nie zależy od żadnego kontekstu.
>> > 
>> > Saldo jest stanem (cząstkowym) konta. Saldo jest wartością. Konto jest
>> > obiektem.
> 
>> Niepotrzebnie wiążesz terminy z życia (stan konta) z terminami
>> informatycznymi (stan obiektu). Osobom z małym doświadczeniem to się
>> często zdarza, nie przejmuj się.
> 
> Parafrazując, "Skończył się czas argumentów. Teraz jest czas inwektyw".

Trafiłem widzę na wrażliwca.

> A może tak coś do tematu?
> 
>> >> Możemy nie wiązać obiektów transakcji do
>> >> konta, a zrobić wiązanie odwrotne: każda transakcja ma referencję do
>> >> konta.
>> > 
>> > Ale co to ma do rzeczy?
> 
>> To, że obiekt konto nie musi przechowywać historii, jeśli tylko zechcę
>> tak to zamodelować.
> 
> No może, i nadal, co z tego?

Guzik. Polecam lecytynkę, bo nie pamiętasz już co napisałeś kilka postów
temu i dlaczego staram się uwalić pomysł, że konto _musi_ przechowywać to
tamto i sramto.

> 
>> >> > Czy ty w ogóle wiesz, co to jest "wartość"?
>> > 
>> >> Element ze zbioru (tu: typ, klasa).
>> > 
>> > To znaczy?
> 
>> Odsyłam do książki "Matematyka dla klas drugich".
> 
> Cóż, osobliwy masz wybór literatury do nauki programowania, ale to już nie
> moja sprawa.

Widzę, że pozycja, o której wspomniałem jest Ci obca. W przeciwnym razie
wiedziałbyś, że nie ma tam słowa o programowaniu.

-- 
Mariusz Lotko