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

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?

[nospor]

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

Oczywiscie, piszmy proceduralnie w ogole , po co onaniziowac sie klasami

Tak, Python nie ma jako takich interfejsow i programisci robia obejscia sztuczne, by tylko wprowadzic interfejsy. A wystarczyloby by Python przestal byc 100 lat za murzynami
Pisze w Python o paru miesiecy i tak mi brakuje porzadnej obiektowki ze glowa mala. powrot do _zmienna by informowac innych userow ze to zmienna prywatna to poprostu koszmar. Nie zmienia to faktu, ze Python jest o niebo lepszy niz php do rzeczy, ktore aktualne tam robie wiec siedze cicho

Czy jeśli nie mam zamiaru stosować w mojej aplikacji testów jednostkowych, to jednak pomimo tego kod powinien być przystosowany do ich stosowania?

Interfejsy stosuje sie nie tylko pod testy. Generalnie dzieki interfejsom, twoj kod jest porzadniejszy, latwiej rozszerzalny i wszystko to o czym gada SOLID.
Choc w praktyce, ja czesto mam lenia i lece po konkretnej klasie i nie tworze interfejsu bo i tak wiem, ze w tym kodzie bedzei tylko jedna klasa. Mowie tu o kontrolerach.
Gdy robie juz jakis Service to wtedy staram sie leciec po interfejsach, choc i to nie zawsze. Czasami wiem, ze mimo ze to Service, to on i tam przyjmowac bedzie zawsze te jedna klasie wiec sie nie bawie w interfejsy. A do testow jednostkowych robie poprostu MOCKa tej klasy i wszystko chula

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