[gajowy_marucha]

#php #symfony2

Używacie get i set dla kazdego pola czy magic methods? Czytalem troche o tym na #stackoverflow i nie bylo jednoznacznego rozstrzygnięcia.

[k.....o]

@gajowy_marucha: lol metody magiczne zamiast geterów i seterów xD Ja myślałem że ty ogarniasz trochę programowanie.

Z geterów i seterów (częściowo) można zrezygnować używając ddd, ale to nie ten poziom jeszcze :D

[uirapuru]

@gajowy_marucha: im mniej magii tym lepiej. jest wygodna. ale ciężko się debuguje i wprowadza chaos przy pisaniu i czytaniu kodu. Fajny feature, coś jak goto. Nie używaj gdzie nie musisz. (mówię o getowaniu i setowaniu).

[gajowy_marucha]

@uirapuru: no wlasnie czytalem o tym troche i czesc ludzi pisala ze nie ma problemu, inni znow zeby nie uzywac ale nie podawali co konkretnie moze sie spierniczyc przez to.

[uirapuru]

@gajowy_marucha: ludzie pokroju Otwella pewnie nie mają z tym problemu ;) Potem inni mają podwójny ;D

[gajowy_marucha]

@kmicolo: dzieki napwrawde pomogles i objasniles :)

[uirapuru]

@kmicolo: znaczy "używając ddd" masz na myśli, że przenieść to do konstruktora ? ;)

[k.....o]

@uirapuru: całkiem spodobala mi się filozofia konstruktorów statycznych i tworzenia metod które zwracają dane biznesowe, nie propertiesy. zamiast getDistance() * getTime() to calculate()

[gajowy_marucha]

@uirapuru: poza czytelnoscia kodu i debugowaniem jakie jeszcze ma wady takie podejscie?

[uirapuru]

@gajowy_marucha: na szybko mi nic nie przychodzi do głowy. ale te dwa powody są wystarczająco dobre

@kmicolo nooo, ddd ostatnio to dla mnie jakby "powrót" do rzeczy, które się kiedyś musiałem oduczyć przez odmienne podejścia. ale im dalej, tym bardziej mi się to podoba.

[k.....o]

@gajowy_marucha: to magia! to nei jest podejście. To droga na skróty przez wysokie pokrzywy bez majtek na dupie. To głupota, to samobójstwo. To podejście godne laravela.
@uirapuru: daj spokój, ciężko się przestawić. Strasznie ciężko. Patrzysz na ten kod i najpierw, wow jakie czytelne, później jezu jakie #!$%@?. Dopiero później dostrzegasz zalety.

[uirapuru]

@kmicolo: bo sie robi ultra-fat-model, którego mnie do tej pory oduczano, bo jak w ORM (przykładowo) może być logika w encjach? btw: jedziecie na phpcona? pijemy? :D

[gajowy_marucha]

@kmicolo:
@uirapuru: A takie properties jak id, modifiedat, createdat, version itp deklarujecie w kazdej klasie czy uzywacie dziedziczenia? I dlaczego?

[uirapuru]

@gajowy_marucha: nie jestem tak biegły w sztuce DDD jak kmicolo, ale robiłem do tej pory podobnie jak w hexagonal symfony, czyli właściwa encja tych pól nie miała, a dopiero dziedzicząca po niej encja "z warstwy persystencji" (nie wiem czy dobrze to nazywam), którą faktycznie operował doctrine

[k.....o]

@uirapuru: no raczej że jade. Jedno piwo można wypić xD
@gajowy_marucha: jak chcesz takie rzeczy dzielić to masz traity. Eo modifies masz chyba nawet traity gotowe w gedmo behaviours

[gajowy_marucha]

@uirapuru: Nie bardzo rozumiem. Symfony obczajam dopiero od paru tygodni.
Ja mam jedna superclass po ktorej dziedzicza encje z ORM. te pola co wymienilem sa tylko w tej Base superclass.

Np mogę mieć taką strukturę: Base (superclass) {id, createdat, modifiedby itp} -> Dict (superclass) {name, code} -> Country (Orm) {continent}

Moglbys wyjasnic czemu to jest złe podejscie? Jesli jest złe. dzieki.

[gajowy_marucha]

@kmicolo: modifies to tylko dla postawowej informacji, zamierzam potem dac EntityAudit do calosci. Czemu traity a nie dziedziczenie?

[uirapuru]

@gajowy_marucha https://github.com/MarcelloDuarte/hexagonal-symfony/ - zajrzyj zwłaszcza do plików

https://github.com/MarcelloDuarte/hexagonal-symfony/blob/master/src/SensioLabs/CeremonyTrackerBundle/Entity/Project.php

oraz

https://github.com/MarcelloDuarte/hexagonal-symfony/blob/master/src/SensioLabs/Ceremonies/Project.php

a następnie jako "ślad" obadaj, czemu jedno jest w Bundle a drugie nie ;) Po prostu to rozerwanie pomiędzy rzeczy należące do domeny i nienależące (kod z bundle, id, create date itd)

co to superclass to moim zdaniem bardzo złe rozwiązanie. zmień jedno w superclass, zmienisz we wszystkich. Osobiscie unikam dziedziczenia jak ognia, a już tymbardziej nie pozwalam sobie na pisanie kodu,

[gajowy_marucha]

@uirapuru: dzieki, ja z kolei wlasnie dlatego uzywam dziedziczenia. Uzywam tego tylko to rzeczy ktore sie nei zmieniaja, takie jak te co wymienilem.

[uirapuru]

@gajowy_marucha: zauwazylem, ze programowanie ostatnio to dla mnie głównie znajomosc ludzkich zachowań. Ludzie (w tym ja) często zakładają, że coś się nie zmieni - przykładowo. nie przewidują, że nawet nazwa klasy (typu *Manager czy coś) potrafi powodować, że z czasem dzieje się w środku śmietnik. Zatem im więcej malutkich klas, każda final, zablokowane dziedziczenie, jednocelowość każdego kawałka kodu - tym lepiej. Blokuj na starcie sam swoje własne lenistwo w przyszłości. Coś

[gajowy_marucha]

@uirapuru: nie no ja rozumiem to ale nie chodzi o lenistwo wrecz przeciwnie. Pomyslalem ze po co ma deklarowac np takei version wszedzie. Jak bede chcial np nr wersji zmieniac co 100 albo pole modifiedAt z date na datetime - wystarczty zmienic w jedym miejscu a nie robic refactor wszystkcih klas. Chyba wlasnie po to miedzy innymi jest dziedziczenie? Tak jak mowil @kmicolo mogle uzyc traitow ale co za roznica tak