Deklaracja interfejsów zamiast klas pod testy jednostkowe Opcje

[eerie]

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". (IMG:style_emoticons/default/wink.gif)

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?

[Salvation]

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.