Problem: dwie jednostki tej samej kwoty
Dostawca zwraca tekst 12.34. Twój kod pracuje na całkowitych groszach, więc potrzebuje 1234. Jeśli konwersja zostanie rozrzucona po kontrolerach, łatwo pomnożyć kwotę dwa razy albo inaczej obsłużyć błąd w drugim endpointzie.
tłumaczy jeden na drugi. Klient korzystający z ceny powinien otrzymać uzgodnioną jednostkę, niezależnie od formatu dostawcy.
Przepływ: tekst dostawcy 12.34 → sprawdzenie formatu → zamiana jednostki → 1234 grosze → klient.
Mały przykład do uruchomienia
Zapisz jako adapter.php i uruchom php adapter.php. Przykład nie potrzebuje frameworka, bazy ani sieci.
<?php
declare(strict_types=1);
function toMinor(string $major): int {
if (!preg_match('/^[0-9]{1,4}\.[0-9]{2}$/D', $major)) {
throw new InvalidArgumentException('Unsupported price format');
}
[$whole, $fraction] = explode('.', $major);
return (int) $whole * 100 + (int) $fraction;
}
echo toMinor('12.34'), PHP_EOL;Wynik to 1234. Cztery cyfry przed kropką i dwie po niej są świadomym ograniczeniem tego małego kontraktu. Nie jest to ogólny parser pieniędzy ani reguła zaokrąglania.
Prześledź wykonanie
preg_match odrzuca nieuzgodniony format. explode dzieli tekst na 12 i 34. Tylko pełna część jest mnożona przez 100; końcówka już oznacza grosze. Obliczenie nie przechodzi przez float.
Dla 12.345 rzuci . Samo obcięcie końcówki ukryłoby brak ustalonej reguły zaokrąglania. Dla drugiego dostawcy zwracającego już 1234 grosze kolejne mnożenie przez 100 byłoby błędem.
Kiedy to ma sens?
Wydziel tłumaczenie, gdy obcy format różni się od Twojego kontraktu albo będzie się zmieniał niezależnie. Dla jednej krótkiej konwersji wystarczy funkcja. Nie potrzebujesz od razu hierarchii klas i rejestru pluginów.
Adapter nie sprawdza właściciela rezerwacji i nie zapewnia . Każda z tych reguł potrzebuje własnego miejsca i testu.
Sprawdź zrozumienie
Przewidź wynik dla 0.01, 10.00 i 12.345. Potem uruchom je w osobnej kopii. Który przypadek wykrywa mnożenie groszy drugi raz?
Źródła
SPRAWDŹ SWOJĄ INTUICJĘ