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