Drukowana wersja tematu

Kliknij tu, aby zobaczyć temat w orginalnym formacie

Forum PHP.pl _ Przedszkole _ [PHP]SRP, DRY itd. a wielość powiązanych klas

Napisany przez: porzeczki 13.11.2017, 09:23:31

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?

Napisany przez: Crozin 13.11.2017, 10:06:43

Przede wszystkim trzeba pamiętać, że wszystkie hasła jakie podałeś, są dosyć... ogólne. We wszystkim trzeba zachować umiar i zdrowy rozsądek. Pokaż kod, który chciałbyś zweryfikować pod kątem zgodności z dobrymi praktykami, będziemy mogli ocenić czy coś wymaga poprawy czy nie.

Napisany przez: Pyton_000 13.11.2017, 10:19:38

Dodatkowo powiem że nie ma co na siłę próbwanie wciskać wszystkich Good Practices do swojego kodu jeśli nie był pisany pod tym kątem. Spowoduje to jeszcze większy bajzel.
Lepiej i łatwiej na początek małymi krokami robić refactoring wydzielając coś gdzieś.

Wchodzisz w kod coś zmienić. Jeśli widzisz możliwość małego refactoringu to go zrób.

Napisany przez: porzeczki 13.11.2017, 10:34:51

Nie jestem w trakcie pracy na kodem, czytam książkę i mnie naszła ta myśl. Nie da się generalnie odpowiedzieć na pytanie: Jak poprawnie w klasie użyć (np) 5 różnych obiektów?

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.

No dobra, na tę chwilę przyjmuję że to zależy od sytuacji i nie da się rzucić generalną poradę.

Napisany przez: trzczy 13.11.2017, 10:59:21

Wstrzykiwać można też Setter Injection

  1. $obj->setDependency($dep)

Napisany przez: Pyton_000 13.11.2017, 11:04:18

Jeśli jest to kontroler to tutaj spinasz generalnie wszystko więc ilość zależności może być spora, ale jeśli jakaś klasa biznesowa ma dużo to już nie jest dobry znak.

Zależy też kto rozmumie dużo, dla mnie znośnie to 3-4, dużo to 6

Napisany przez: porzeczki 13.11.2017, 11:31:46

Cytat(Pyton_000 @ 13.11.2017, 11:04:18 ) *
Jeśli jest to kontroler to tutaj spinasz generalnie wszystko więc ilość zależności może być spora, ale jeśli jakaś klasa biznesowa ma dużo zależności to już nie jest dobry znak.

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?

Napisany przez: Crozin 13.11.2017, 13:25:22

Cytat
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. smile.gif
Cytat
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.
Cytat
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.
Cytat
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. smile.gif

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)