Zgadzam się z 1 odpowiedzią. To wszystko sprowadza się do matematyki. Funkcja jest to takie dopasowanie, które dla każdego elementu ze zbioru
X (zwanego dziedziną) przypasowuje dokładnie 1 wartość ze zbioru
Y (zwanego przeciwdziedziną). W programowaniu z tą "dokładnie 1 wartością" bywa różnie, ale przyjmijmy, że mówimy o funkcjach, tzw. czystych (pure). By przedstawić funkcje wielu argumentów można pójść 2 drogami:
- zrobić tak jak jest w większości języków, czyli, że dziedzina
@gluteus_minimus: Funkcja przekształcająca wartość w macierz (np. obrót wokół osi OX) dalej zwraca 1 wartość ze zbioru przeciwdziedziny. To, że macierz zawiera wiele wartości nie ma tutaj najmniejszego znaczenia. Co do zwracania wartości pustej - jeśli klasę potraktujemy jako multizbiór to ∅ też można potraktować jako dozwoloną wartość w przeciwdziedzinie.
Przecież ja wspomniałem o tym, że się da symulować zwracanie wielu wartości, jednak mimo wszystko tak naprawdę zwracamy 1 wartość z
Myślę nawet, że różne języki w jakiejś mniejszej lub większej części są czyste matematycznie, jednak właśnie z praktycznych względów składają się także z odstępstw od takiej czystej matematycznej kodyfikacji.
Pisząc obiektowo powinno się ograniczać przepływ danych, a właściwie wyciąganie ich z obiektu bo dane są częścią implementacji. Jeżeli interfejs jest publiczny to lepiej starać się niczego nie zwracać, ew stosować jakiegoś rodzaju visitory przy których łatwiej zrealizować np synchronizację, natomiast przy interfejscie prywatnym można operować na polach. Poza tym jeżeli chcemy otrzymać dwa obiekty to nasuwa się myśl, że są one ze sobą skojarzone więc powinny być w obrębie obiektu.
Programowanie obiektowe to tylko jedna rzecz z programistycznej skrzynki z narzędziami.
@Sh1eldeR: Oczywiście, nie zaprzeczyłem tego a jako, że programowanie obiektowe jest na topie i takim a nie innym się zajmuje to się odniosłem do niego :)
niezwracanie jakiejkolwiek wartości -- bardzo promuje funkcje/metody, których jedynym wynikiem są efekty uboczne
@Sh1eldeR: To jest główny argument za tym, że programowanie obiektowe nie jest eleganckie - czyli wymieszanie danych z procedurami. Ale
Programowanie obiektowe to tylko jedna rzecz z programistycznej skrzynki z narzędziami. Zauważ, że jedna z rzeczy, o których wspomniałeś -- niezwracanie jakiejkolwiek wartości -- bardzo promuje funkcje/metody, których jedynym wynikiem są efekty uboczne. Poza tym, jest to niekompatybilne z obiektami-wartościami (value objects). Skoro mamy efekty uboczne, to obiekt musi się zmieniać (tj. jest mutable). Czy to na pewno dobry styl? Czy to zawsze najlepszy styl -- na
@mnlf: Właśnie na odwrót - zwraca zawsze jedną zmienną, a to że kilka jest zwracane w postaci tupli i to, że nie trzeba ich otaczać nawiasami to tylko ułatwienie wprowadzone przez twórców. Zresztą w innych miejscach można tworzyć tuple bez nawiasów, np:
t = 1, 2, 3 .
Podany przez Ciebie przykład
(x,y,z)=funkcja1() też można zapisać bez nawiasów:
x, y, z = funkcja1() I nie - wyniku funkcji nie można sobie
Komentarze (24)
najlepsze
X
(zwanego dziedziną) przypasowuje dokładnie 1 wartość ze zbioru
Y
(zwanego przeciwdziedziną). W programowaniu z tą "dokładnie 1 wartością" bywa różnie, ale przyjmijmy, że mówimy o funkcjach, tzw. czystych (pure). By przedstawić funkcje wielu argumentów można pójść 2 drogami:
- zrobić tak jak jest w większości języków, czyli, że dziedzina
Przecież ja wspomniałem o tym, że się da symulować zwracanie wielu wartości, jednak mimo wszystko tak naprawdę zwracamy 1 wartość z
Myślę nawet, że różne języki w jakiejś mniejszej lub większej części są czyste matematycznie, jednak właśnie z praktycznych względów składają się także z odstępstw od takiej czystej matematycznej kodyfikacji.
W czym problem?
TRUE, FALSE, NIE-WIEM, NIC-SIE-NIE-STALO.
Komentarz usunięty przez moderatora
Pamiętajmy
@Sh1eldeR: Oczywiście, nie zaprzeczyłem tego a jako, że programowanie obiektowe jest na topie i takim a nie innym się zajmuje to się odniosłem do niego :)
@Sh1eldeR: To jest główny argument za tym, że programowanie obiektowe nie jest eleganckie - czyli wymieszanie danych z procedurami. Ale
Programowanie obiektowe to tylko jedna rzecz z programistycznej skrzynki z narzędziami. Zauważ, że jedna z rzeczy, o których wspomniałeś -- niezwracanie jakiejkolwiek wartości -- bardzo promuje funkcje/metody, których jedynym wynikiem są efekty uboczne. Poza tym, jest to niekompatybilne z obiektami-wartościami (value objects). Skoro mamy efekty uboczne, to obiekt musi się zmieniać (tj. jest mutable). Czy to na pewno dobry styl? Czy to zawsze najlepszy styl -- na
Oczywiście, że jest lepsze. I to jest właśnie jedna z przyczyn dla których lubię pythona.
t = 1, 2, 3
.
Podany przez Ciebie przykład
(x,y,z)=funkcja1()
też można zapisać bez nawiasów:
x, y, z = funkcja1()
I nie - wyniku funkcji nie można sobie
Komentarz usunięty przez moderatora