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?

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


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

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.