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

[lukasz1985]

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

Głupszego sformułowanie nie słyszałem. 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". Klasy abstrakcyjne są podstawą programowania obiektowego, a interfejsy głównie wszystkim poprzewracały w głowach. Rezultatem jest to, że zamiast właściwej kompozycji i dziedziczenia wszędzie są pociskane interfejsy i powielany kod.

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

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. Nie ma też sensu pisanie testów do zadań trywialnych.