Deklaracja interfejsów zamiast klas pod testy jednostkowe |
Deklaracja interfejsów zamiast klas pod testy jednostkowe |
6.05.2024, 15:08:35
Post
#1
|
|
Grupa: Zarejestrowani Postów: 82 Pomógł: 0 Dołączył: 3.08.2017 Ostrzeżenie: (0%) |
Witam. Mam taką wątpliwość... Kiedyś przeczytałem artykuł na temat zasad SOLID. Autor sugerował, iż powinno się deklarować jako typy wartości (np. parametry i zwracana wartość metody) interfejsy i klasy abstrakcyjne zamiast konkretnych klas, aby kod był przystosowany pod testy jednostkowe z np. PHP Unit. Innym razem poznałem opinię, iż np. taki język programowania Pyton w ogóle nie ma interfejsów i nie ma sensu "onanizować się kodem".
Ostatnio przystosowałem moją starą przykładową aplikację do nowego framework'a Symfony 7. W trakcie programowania raz definiowałem, iż jakiś wstrzykiwany do kontrolera obiekt ma interfejs (np. "EntityManagerInterface"). Innym razem podawałem, iż jest danej klasy (np. "Environment"). Jak w kodzie poniżej: https://github.com/webeeq/toposoba.eeq/blob...aController.php I tu rodzi się moje pytanie. Czy jeśli nie mam zamiaru stosować w mojej aplikacji testów jednostkowych, to jednak pomimo tego kod powinien być przystosowany do ich stosowania? I gdzie deklarować interfejsy zamiast konkretnych klas, aby dało się testować taką aplikację z użyciem np. PHP Unit? |
|
|
6.05.2024, 15:46:27
Post
#2
|
|
Grupa: Zarejestrowani Postów: 357 Pomógł: 70 Dołączył: 15.07.2014 Ostrzeżenie: (0%) |
SOLID nie zostało wymyślone pod testy, a po to, by kod był bardziej abstrakcyjny i przystosowany do konsumpcji różnych obiektów o tym samym typie.
Mamy np. Interface Animal, więc wrzucamy do metody Animal $animal i wywołujemy np. metodę canRun(), która zwraca true lub false. Nie interesuje nas czy "wrzucone" Zwierzę, to Kot, Pies, Ptak czy Ryba. I o to w całym tym zamyśle chodzi. A pisanie kodu wg zasad SOLID (czy teraz już CUPID), a najlepiej także wg metodologii TDD, znacznie uprości kod. Nie tylko w testach. |
|
|
Wersja Lo-Fi | Aktualny czas: 19.05.2024 - 16:03 |