[biblioteka] Rounder, Czyli jak round() wywołało frustrację Opcje

[greycoffey]

Hej,

sfrustrowany dzisiaj zachowaniem funkcji round() której zaokrąglanie half up i half down nie jest tym, za co się podaje, spłodziłem klasę, która robi to poprawnie. Zawiera interfejs oraz domyślną implementację zaokrąglacza, druga implementacja (oparta na bcmath) właśnie się tworzy (co do tego, macie jakiś pomysł na implementację metod roundHalfEven() i roundHalfOdd() w Pamil\Rounder\BcmathRounder w gałęzi bcmath-support?).

Przykład użycia i kod na GitHubie.

[Crozin]

Interfejsy są po to, żeby móc skorzystać z danego typu implementacji na różne sposoby.

Interfejsy są po to by korzystać z różnych implementacji w ten sam sposób. To o czym piszesz w dalszej części postu w tym konkretnym przypadku jest błędne. Tutaj chcemy mieć obiekt, który będzie potrafił wykonywać różnego rodzaju zaokrąglenia (w sumie 11 sposobów) na różnych podmiotach (zwykła liczba czy BC Math) i interfejs służy właśnie do wyizolowania tych podmiotów, nie samych metod zaokrąglania. Interfejs kalkulatora, który podałeś również jest błędny. Każdy kalkulator powinien umieć dodać czy odejmować. Przedstawiony przez Ciebie interfejs powinien nazywać się Operation czy właściwie BinaryOperation (od dwóch argumentów, nie od danych binarnych).

Albo mogę zwracać ten sam wynik, ale np. jedno kosztem drugiego. Przykład: jest sobie klasa, która działa szybko, ale liczy liczby do jakiegoś MAX_INT oraz druga, która jest wolniejsza, ale liczy też ogromne liczby.

Tutaj już podałeś poprawny przykład.

Inna implementacja po prostu nie ma sensu, bo zwracanie randoma to zwracanie randoma. Tu się nic nie wymyśli. A że mt_rand() działa szybciej, jest w tym przypadku jedyną słuszną implementacją, w związku z tym wystarczy: [...]

Tutaj znowu błąd. mt_rand nie jest jedyną słuszną implementacją w tym wypadku. Przecież mogę potrzebować takiej implementacji, która zawsze zwróci 42 albo jakiś z góry określony cykl liczb na przykład na potrzeby testów. Albo taką, która będzie w przeciwieństwie do mt_rand generować kryptograficznie bezpieczną liczbę. Albo jeszcze inną, która zwróci inny rozkład losowych liczb dla danego przedziału.

Na tym polega cały nonsens takich przedsięwzięć, że więcej czasu zajmuje pisanie durnych testów jednostkowych i tworzenie repozytorium na GitHubie niż właściwe pisanie kodu.

Ale to, że taki kod da się później normalnie wykorzystywać w innych projektach już nie napiszesz.

Ten interfejs to też sobie można gdzieś wsadzić bo wystarczy abstrakcyjna klasa, która sama w sobie stanowi interfejs.

Klasa abstrakcyjna raczej nie powinna stanowić publicznego interfejsu w językach z pojedynczym dziedziczeniem. Na pewno nie w tym konkretnym przypadku.

[pyro]

Interfejsy są po to by korzystać z różnych implementacji w ten sam sposób. To o czym piszesz w dalszej części postu w tym konkretnym przypadku jest błędne. Tutaj chcemy mieć obiekt, który będzie potrafił wykonywać różnego rodzaju zaokrąglenia (w sumie 11 sposobów) na różnych podmiotach (zwykła liczba czy BC Math) i interfejs służy właśnie do wyizolowania tych podmiotów, nie samych metod zaokrąglania. Interfejs kalkulatora, który podałeś również jest błędny. Każdy kalkulator powinien umieć dodać czy odejmować. Przedstawiony przez Ciebie interfejs powinien nazywać się Operation czy właściwie BinaryOperation (od dwóch argumentów, nie od danych binarnych).

Kurcze, już w momencie pisania tamtego postu przeczuwałem, że ktoś przyczepi się do tych przykładów i zarzuci branie ich za autorytet lub jakiś w pełni funkcjonalny przykład. Czułem, że pownienem był napisać jakieś ostrzeżenie czy coś (IMG:style_emoticons/default/wink.gif) . Pragnę więc oświadczyć Tobie, jak i potomnym, że z praktycznego punktu widzenia żadna z powyższych klas nie ma sensu i służyła tylko przedstawieniu toku myśleniowego "dlaczego tak a nie inaczej". Zostało to zresztą "pisane na kolanie", co widać chociażby po braku wcięć (Notepad++). Coś na styl kaczek, piesków, kotków z dajGlos(); (przykład często widziany w internecie).

Tutaj znowu błąd. mt_rand nie jest jedyną słuszną implementacją w tym wypadku. Przecież mogę potrzebować takiej implementacji, która zawsze zwróci 42 albo jakiś z góry określony cykl liczb na przykład na potrzeby testów. Albo taką, która będzie w przeciwieństwie do mt_rand generować kryptograficznie bezpieczną liczbę. Albo jeszcze inną, która zwróci inny rozkład losowych liczb dla danego przedziału.

W sumie wybrałem trochę kiepski przykład na przedstawienie problemu. Nie mniej specjalnie podałem tylko dwie klasy i cały czas pisałem dlaczego w tym przypadku jedna wyklucza drugą i dlaczego tylko odnosić się tylko do tego, co zostało napisane.

Obie klasy pozwalają na generowanie randomowych liczb, ale wyliczono, że mt_rand() działa ok. 4 razy szybciej. Inna implementacja po prostu nie ma sensu, bo zwracanie randoma to zwracanie randoma. Tu się nic nie wymyśli. A że mt_rand() działa szybciej, jest w tym przypadku jedyną słuszną implementacją

bo takie rzeczy jak losowanie z przedziału liczb w ogóle nie zostały tu po prostu przedstawione. Ale tak jak wspomniałem - przykład rzeczywiście nie najlepszy. Załóżmy, że dla tego przykładu nie istnieją dodatkowe założenia jak możliwość generowanie kryptograficznie bezpiecznej liczby albo testów. Zachęcam w międzyczasie do napisania lepszego przykładu z powodów przedstawionych.