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

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.

Wiesz, przykłady powinny w miarę możliwości być trafne. (IMG:style_emoticons/default/wink.gif)

Klasa sama w sobie stanowi interfejs i definiuje kontrakt, więc nie ma tutaj "nie powinna" skoro fakt zupełnie zaprzecza nawet samemu "nie może". Służy do tego zazwyczaj słowo kluczowe "public". Definicja słowa interfejs nie obejmuje sobą tylko tego co w języku programowania ma słowo kluczowe "interface".

Dlatego właśnie pisałem o publicznym interfejsie, przez który rozumiałem interfejs jaki dana biblioteka udostępnia kodowi korzystającemu z niej. Tutaj w przypadku PHP będzie się to ograniczać do TypeHintingu czy informacji o zwracanych typach danych (phpDoc).

Rezultatem jest to, że zamiast właściwej kompozycji i dziedziczenia wszędzie są pociskane interfejsy i powielany kod.

Nie rozumiem w czym niby interfejs miałby przeszkadzać w dziedziczeniu czy kompozycji, pomijając fakt, że w przypadku tego ostatniego, wymusza tworzenie lepszego kodu (nieograniczony polimorfizm/nieskrępowane dziedziczenie).

Nikt nie potrzebuje klasy do zaokrąglania liczb, a jeśli już to wystarczy, że klasa "Rounder" będzie zaopatrzona w metody abstrakcyjne implementowane w klasach pochodnych (MathRounder czy InnyRounder).

Jak widać @greycoffey potrzebował i zastosowanie tutaj interfejsu w niczym nie przeszkadza, a w przypadku gdy InnyRounder będzie już dziedziczył po czymś innym nie będzie miał problemu z podpięciem swojej klasy.

A tworzenie takiej biblioteki mija się z celem bo jest ona za mała i każdy komu zaokrąglanie nie pasuje prędzej napisze własne funkcje niż znajdzie to w sieci.

Od kiedy to przydatność mierzy się liczbą linii kodu? Ja, gdybym potrzebował poprawnego zaokrąglania czy potrzebowałbym innych metod zaokrąglania wolałbym skorzystać z pow. biblioteki, niż tracić czas na pisanie jej samemu.

Nie ma też sensu pisanie testów do zadań trywialnych.

Kto powiedział, że zaokrąglanie jest trywialne. Ja tam widzę co najmniej kilka miejsc, gdzie coś może źle zadziałać.

Ten post edytował Crozin 9.01.2014, 11:11:52