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.

wygląda fajnie, klasa czytelna i zrozumiała. Chociaż zastanawiam się, na ile jest to przydatne ? Problem zaokrągleń jest na tyle banalny, że można samemu napisać szybko prosty kodzik, który będzie działał tak jak trzeba, nie zaprzęgając do tego klas. Po za tym zaokrągleń używa się zazwyczaj rzadko, tak czy siak szacun za inicjatywę : ). co do bcmath nigdy nie potrzebowałem takiej precyzji ale z implementacją powinno być podobnie jak teraz. Wymagasz podania liczby oraz wskazania precyzji. Możesz też dorobić dla bcmath operacje arytmetyczne na 2 liczbach, z pewnością wzbogaciłoby to wartość klasy

Wygląda na sensownie skonstruowany kawałek kodu. Niemniej nie rozumiem sensu użycia interfejsów i abstrakcji... można na różne sposoby np. zaokrąglać liczbę w górę itd.?

Tzn. umiałbyś np. inaczej napisać funkcję floor(), żeby dla 3.15 zwracała coś innego niż 3?

Chwała Ci za użycie przykładów w komentarzach, bo robi to stosunkowo niewiele osób, a różnica jest tak kolosalna jak różnica pomiędzy użyciem dużej szczotki, a szczoteczki do zębów w celu umycia sedesu

Możesz podać przykład niepoprawnego działania? Sprawdziłem i u mnie zachowywała się normalnie. Przejrzałem Twoje testy i wskazują one na to, że błędnie rozumujesz zaokrąglanie w górę i dół. Chodzi o to, że zaokrągla się wartość bezwzględną, tzn. tak, żeby było od zera w kierunku nieskończoności (dodatniej lub ujemnej). Co zresztą objaśnione jest w dokumentacji:

Jeśli chodzi o ten przypadek to funkcja działa zgodnie z opisem.

@gitbejbe, trafiłeś w sedno, czas napisać coś, co usprawni obsługę dużych liczb, bo to funkcyjne API bcmath jest straszne, zwłaszcza gdy przychodzi do porównywania liczb.

@pyro, co do tej abstrakcji, w planach mam dodanie obsługi zaokrąglania dla dużych liczb (i to można wykonać za pomocą bcmath, lub własnego algorytmu, w każdym razie będzie to obsługa dużych liczb w postaci łańcuchów znaków, nie liczb).

Interfejsy - dla swobodnego dodawania i wymieniania implementacji.
Klasa abstrakcyjna - by nie pisać powtarzalnej metody round($number, $precision, $roundingMode) w implementacjach

@destroyerr, nazwa tej stałej to "PHP_ROUND_HALF_UP", jest to zaokrąglanie od połowy w stronę pozytywnej nieskończoności. Funkcja działa zgodnie z opisem stałej, nie z nazwą stałej.

Źródła:
Zaokrąglanie od połowy w stronę pozytywnej nieskończoności
Zaokrąglanie od połowy w stronę nieskończoności

W pierwszym linku możemy przeczytać:

To samo tyczy się PHP.

@greycoffey przekonałeś mnie. Za bardzo skupiłem się na manualu PHP. Teraz widzę, że gdybym przeczytał opis Twojego projektu to nie musiałbym zadawać tego pytania.
Git, composer, travis, testy, własne wyjątki a i projekt przydatny - można oceniać tylko pozytywnie.
Mała uwaga prośba, jeśli chciałbym tego użyć w zastępstwie funkcji \round() to przydałby się jej odpowiednik w Twojej przestrzeni nazw. Lub klasa statyczna z odpowiednimi funkcjami. Zwłaszcza, że Twoje obiekty nie posiadają żadnego stanu.

@pyro

zastosowanie interfejsów i abstrakcji też mnie zastanowiło. Faktycznie kod jest bardziej pro i wymusza on schematy działania, ale czy nie jest to przyrost treści nad formą ? Tak naprawdę do każdego rodzaju zaokrąglenia wystarczy napisać samą metodę w której jest tylko to co trzeba. Każdy jednak ma swoją wizje, do Twojej tak czy siak trudno się przyczepić. Dobra robota !

@destroyerr, masz rację, przerobiłem Roundera na modłę statyczną, teraz jest prościej z niego korzystać, a tutorial także przerobiłem na prostszy (wymagana tylko jedna klasa, jako że Rounder implementuje RounderInterface, to dziedziczy po nim stałe).

@gitbejbe, czy ja wiem czy bardziej pro, na pewno łatwiejszy do ogarnięcia i ewentualnej zmiany implementacji, czy korzystania równolegle z dwóch Rounderów - mamy pewność, że mają taki sam interfejs.

Wersja 1.0 właśnie została wydana, w wersji 1.1 zostanie wprowadzona obsługa zaokrąglania dużych liczb jako BcmathRounder.

Drobne uwagi:
- implements RounderInterface możesz spokojnie przenieść do AbstractRounder. Unikniesz dzięki temu potrzeby wstawiania kilku metod abstrakcyjnych.
- Zamiast tworzyć MethodNotImplementedException spokojnie mógłbyś skorzystać z wbudowanego BadMethodCallException ze stosowną informacją, zaś RoundingModeNotFoundException mógłby zostać zastąpiony przez InvalidArgumentException.

Poważne uwagi:
- Po co zmieniłeś poprawny, niestatyczny kod, na statyczny? Połowa zalet OOP i IDD właśnie została zaprzepaszczona.

Chyba się trochę nie zrozumieliśmy. Interfejsy są po to, żeby móc skorzystać z danego typu implementacji na różne sposoby. Przykładowo na podstawie danego interfejsu mogę zwracać różne wyniki, np:

[PHP] pobierz, plaintext 
<?php
 
class Calculator {
 
    private $a;
    private $b;
    private $strategy;
 
    public function __construct($a, $b) {
        $this->a = $a;
        $this->b = $b;
    }
 
    public function setStrategy($strategyName) {
        $className = ucfirst(strtolower($strategyName));
 
        if(class_exists($className) && is_subclass_of($className, 'CountingStrategy')) {
            $this->strategy = new $className();
            return true;
        } else {
            throw new StrategyNotFoundException('Calculation type not found');
        }
    }
 
    public function calculate() {
        $this->strategy->setVariables($a, $b);
        return $this->strategy->getResult();
    }
 
}
 
abstract class CountingStrategy {
    private $a;
    private $b;
 
    abstract public function getResult();
    public function setVariables($a, $b) {
        $this->a = $a;
        $this->b = $b;
    }
}
 
class Sum extends CountingStrategy {
    public function getResult() {
        return $this->a + $this->b;
    }
}
 
class Subtract extends CountingStrategy {
    public function getResult() {
        return $this->a - $this->b;
    }
}
 
?>
[PHP] pobierz, plaintext 

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 widzę trzeci przypadek, że jest sobie coś w stylu:

[PHP] pobierz, plaintext 
interface RandomizerInterface {
public function generate();
}
 
class NormalRand implements RandomizerInterface {
 
public function generate() {
return rand();
}
 
}
 
class MtlRand implements RandomizerInterface {
 
public function generate() {
return mt_rand();
}
 
}
[PHP] pobierz, plaintext 

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ą, w związku z tym wystarczy:

[PHP] pobierz, plaintext 
class MtlRand {
 
public function generate() {
return mt_rand();
}
 
}
[PHP] pobierz, plaintext 

bez zbędnych interfejsów. I widzę swojego rodzaju odbicie przypadku w przytoczonym kodzie. O to mi chodziło.

No, a teraz zmykam na sylwestra.

Do siego.

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. Ten interfejs to też sobie można gdzieś wsadzić bo wystarczy abstrakcyjna klasa, która sama w sobie stanowi interfejs. Na ten temat akurat wypowiedziałem się tutaj: Abuse of interfaces, in Java.

Czekam na bibliotekę, która będzie potrafiła poprawnie wykonywać operacje algebraiczne - będzie zwracać liczby zmiennoprzecinkowe przy dzieleniu dwóch liczb całkowitych, bo w końcu kto by pamiętał o rzutowaniu typu.

Dla niekumatych to była ironia.

@up to możesz dać choć jeden sensowny powód poco to napisałeś?

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).
Tutaj już podałeś poprawny przykład.
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.

Ale to, że taki kod da się później normalnie wykorzystywać w innych projektach już nie napiszesz.Klasa abstrakcyjna raczej nie powinna stanowić publicznego interfejsu w językach z pojedynczym dziedziczeniem. Na pewno nie w tym konkretnym przypadku.

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



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.


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.

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

Przeczytaj pare klasycznych książek i naucz się programować zanim zaczniesz pociskać takie farmazony i pozowac.

Klasa jest zupełnie nieprzydatna nikomu poza autorem i wszystko tak jak pisze lukasz1985

Wiesz, przykłady powinny w miarę możliwości być trafne.
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).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).
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.
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.
Kto powiedział, że zaokrąglanie jest trywialne. Ja tam widzę co najmniej kilka miejsc, gdzie coś może źle zadziałać.

Naprawdę wątpię, żeby komuś chciało się do zaokrąglania liczb szukać biblioteki. Z całym szacunkiem do włożonego trudu (w pisanie klasy i implementacji / testów jednostkowych nie zdzierżę bo nie cierpię nadgorliwości).

@crozin Przeczytaj sobie mój artykuł, o którym pisałem w jednym z moich poprzednich postów i przemyśl sobie to szybko dojdziesz do wniosku, że interfejsy mogą stać się problemem jeśli się ich używa "zamiast" po prostu dziedziczenia.

Skąd wiesz czy komuś będzie się chciało wpisać w Googlea php number rounding library?
Obecność testów jest dla wielu osób/projektów wręcz wymogiem przy decydowaniu się na skorzystanie z kodu osób trzecich.

Pamiętaj, że nie każdy ma takie potrzeby jak Ty.Chodzi Ci o artykuł Abuse of interfaces in Java? Przeczytałem go od razu i nie zgadzam się z częścią tez w nim zawartych. Nie wiem też w czym interfejsy same w sobie miałby utrudniać dziedziczenie (pomijaj też fakt, że ich wykorzystanie umożliwia w ogóle skorzystanie z dziedziczenia w wielu przypadkach w przeciwieństwie do klas abstrakcyjnych). Mam wrażenie jakbyś podchodził do tematu na zasadzie interfejsy kontra dziedziczenie/klasy abstrakcyjnie, zamiast normalnie, tj. interfejsy plus dziedziczenie/klasy abstrakcyjne.

Hej, ogarnąłem się po sylwestrze także mogę odpowiedzieć

Co do Roundera, to uważam jednak, że ustatycznienie go było złą decyzją. Trochę się wzorowałem na istniejącej funkcji round, ale niestety biblioteka standardowa w PHP nie jest dobrym wzorcem Myślę, że @Crozin ma rację co do tej kwestii. Anyway, podobne opinie co do kobyłowatości i przekombinowania słyszałem wobec Symfony2, które właściwie zapoczątkowało prawdziwy przełom w świecie PHP.

Wersja "odstatyczniona" 2.0 (zgodnie z semantic versioning) prawdopodobnie na dniach wyląduje na Githubie.


Życzę miłego debugowania, podczas którego zrozumiesz, że nie jest to żadna nadgorliwość, a właściwie niezbędny element każdego kodu. Używając mojej klasy czy pisząc nowe implementacje można się w chwilę upewnić, czy wszystko działa tak jak powinno.