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

[pyro]

@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

@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 !

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.