[PHP]SRP, DRY itd. a wielość powiązanych klas Opcje

[porzeczki]

Przedszkole to przedszkole.

"Twórz jak najwięcej małych klas"
"Nie twórz ciasnych wiązań między klasami"
"Jeden argument ok, dwa to za dużo, trzy zmień coś"

Boję się dzielić kod na wiele klas bo potem trzeba dostarczyć nowe rozdzielone obiekty do pierwszego. Nie pozwalają tworzyć obiektów wewnątrz metod. Nie pozwalają by konstruktor miał wiele argumentów.

Więc jak mam dostarczyć wydzielone obiekty do pierwszego (pierwotnego, sorry) obiektu by książki były szczęśliwe? W konstruktorze? I to nie będzie ciasne wiązanie?

[Crozin]

Nie da się generalnie odpowiedzieć na pytanie: Jak poprawnie w klasie użyć (np) 5 różnych obiektów?

Na takie pytanie można odpowiedzieć jedynie mając kontekst konkretnego przypadku.

Bo rozumiem, że poprawnie byłoby wstrzykiwać instancje jako parametry konstruktora (Dependency Injection), ale tu też książka mówi, że nie ładnie mieć wiele argumentów.

I generalnie rzecz biorąc ta książka bardzo dobrze mówi. Co zatem w przypadku, gdy w kontruktorze potrzebowałbym 23 argumentów? Najprawdopodobniej mamy do czynienia ze źle zaprojektowanym obiektem, który próbuje zajmować się zbyt dużą liczbą rzeczy na raz.

Jeśli jest to kontroler to tutaj spinasz generalnie wszystko więc ilość zależności może być spora [...]

Kontrolery to dokładnie takie same klasy jak wszystkie inne. Nie powinny spinać wszystkiego, bo co jest do wszystkiego to jest do niczego. ;-) Z jakiegoś powodu da się w sieci znaleźć "odczucia", że kontrolery to jakieś specjalne klasy - nie, nie są w żaden sposób wyjątkowe.

W sensie klasa biznesowa raczej powinna po prostu coś zwracać bez większych kombinacji z innymi klasami, a w kontrolerze żongluję tymi klasami biznesowymi. Tak?

Wręcz dokładnie odwrotnie. :-) To własnie klasy/metody z części "logiki biznesowej" potrzebują wykonać całą ciężką pracę w programie, więc to w nich znajdziemy sporo zależności. Inną kwestią jest to, że nadal trzeba trzymać się zasady - im mniej zależności tym lepiej.

W skrócie: musiałbyś podać konkrety przypadek do omówienia (code review) nawet w jakimś pseudokodzie, bo tak to będziemy prowadzić akademicki wywdów.