🚀 go-pugleaf

Dnia Tue, 13 Mar 2007 19:24:26 +0100, Mariusz Lotko skrobie:
> Sektor van Skijlen wrote:

> >> > Portfel nie jest typem wartościowym.
> >> > 
> >> > Ilość pieniędzy w portfelu jest jedynie jednym ze stanów tego obiektu,
> >> > podobnie jak ilość kart kredytowych w środku, kolor portfela i
> >> > materiał, z którego go wykonano.
> > 
> >> I w _każdym_ systemie tak to modelujesz? Z pełną otoczką? Piękny przykład
> >> wzorca "swiss army knife".
> > 
> > Nie używaj pojęć, których znaczenia nie rozumiesz.

> Nie czyń założeń, na które nie masz dowodów.

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

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

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.

(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ą.)

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

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

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

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

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.

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

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

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?

> >> 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?

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

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

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.

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

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

> Pozwalam to ocenić innym. Również Tobie, choć przyznam, że 
> nie odbieram tych ocen zbyt serio.

> Daj szansę innym pochwalić Twoje umiejętności. Może kiedyś to nastąpi.

Już nastąpiło, o to się nie martw.

> >> >> "Prawdopodobnie" to dla mnie trochę za mało. Szczególnie w przypadku
> >> >> szablonów, które według mojej praktyki z reguły są po prostu
> >> >> przeznaczone dla obiektów oferujących określony interfejs. I innych
> >> >> ograniczeń w ich użyciu właściwie nie ma.
> >> > 
> >> > Tak, dokładnie. Ale typy wartościowe zwykle mają inny interfejs, niż
> >> > typy obiektowe.
> > 
> >> Znowu ogólnik: "zwykle"... "Sprzedajesz" nam teorię, która ma działać w
> >> praktyce, ułatwiać ją. Chciałbyś, żeby Twój samochód "zwykle" działał?
> > 
> > Oczywiście teoretycznie może istnieć taki wzorzec, który typom nie stawia
> > żadnych wymagań, ale w praktyce nie spotkałem się z takim.
> > 
> > Wymagania co do typów zawsze określają poszczególne operacje, które na
> > typie można wykonać. I te operacje świadczą też o tym, czy typ jest
> > wartościowy, czy nie.
> > 
> > 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.

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

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?

> > 
> > Transakcja też jest obiektem, tzw. "wartość transakcji" jest atrybutem
> > obiektu transakcji, a ilość pieniędzy, na którą opiewa transakcja, jest
> > wartością.

> Otóż to!

No właśnie. Więc co tu może, a co nie może być wartością?

> >> I podobnie z właścicielem. Krótko mówiąc "konto jest anonimowe" i
> >> przechowuje jedynie swoje saldo (wartość) oraz numer (tożsamość).
> > 
> > Numer jest atrybutem obiektu (unikalnym, więc jest ściśle związany z
> > tożsamością), właściciel też jest obiektem (w bazie banku jest osobnym
> > obiektem, który może być podmapowany do kilku kont). Saldo jest stanem
> > konta, a wartość salda to ilość pieniędzy znajdujących się na koncie.

> Dlaczego "ilość" nie jest według Ciebie "wartością"?

Widzę, że całkiem się już pogubiłeś ;)

Oczywiście, że jest.

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


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"