Wpis z mikrobloga

@sarveniusz: Jak na bloga to trochę zbyt formalne zdania - jeśli ktoś jest w stanie rozumieć o czym mowa to już raczej dawno wie to czego miałby się z nich dowiedzieć (trochę jak z "A monad is just a monoid in the category of endofunctors").

Poza tym przypadek używania dziedziczenia jako mechanizmu kopiowania funkcjonalności do stworzenia nowego typu można odrzucić na samym początku, bo ten jest już wystarczająco upośledzony -
@alex-fortune:

Dlaczego dziedziczenie nie powinno być używane*

poprawiłem ( ͡° ͜ʖ ͡°)


Aż tak radykalnie nie podchodziłbym do tego. Dziedziczenie po abstrakcji nie powinny przysporzyć jakichś kłopotów, zakładając, że nie jest ona bardzo rozbudowana. Tak z ciekawości, przykład z wpisu rozwiązywałbyś bez dziedziczenia?
@alex-fortune: Ależ oczywiście że możesz, ale czy warto? Załóżmy że chcesz stworzyć kilka różnych modeli ORMowych i zapisywać je do bazy. Najprościej by było zrobić funkcję za to odpowiadającą w klasie bazowej i po niej dziedziczyć. Traita możesz użyć chociaż nie będzie to najładniejsze. Ale Dependency Injection? No niby możesz ale będziesz sporo copy/paste.
Ależ oczywiście że możesz, ale czy warto?


@plushy: No warto

Załóżmy że chcesz stworzyć kilka różnych modeli ORMowych


Nie używasz "modeli" ORMowych w inny sposób niż worek na dane do zapisu, a najlepiej nie używasz ORMa bo to antypattern mocno

Ale zakładawszy, że używasz syfu w stylu doctrine czy innego hibernate'a to tak, faktycznie, łatwiej tak zrobić bo ze względu na to, że inaczej ciężko to pożenić ( chyba, że jest
@alex-fortune: ORM są przydatne, chyba by mnie pieprzło gdybym wszędzie miał pisać kilka tysięcy zapytań dla wyciągania podstawowych danych i zadbać o to by to działało na kilku różnych bazach danych. Ale okej, więc załóżmy że modele wysyłam do funkcji która je zapisuje i mamy inną która magicznie wyciąga rzeczy z bazy. Może tak być.

A co z kontrolerami? Część ma mieć autoryzację, część ma nie mieć, część ma mieć inną.
ORM są przydatne, chyba by mnie pieprzło gdybym wszędzie miał pisać kilka tysięcy zapytań dla wyciągania podstawowych danych i zadbać o to by to działało na kilku różnych bazach danych


@plushy: Spoko, jeśli chcesz ich uzywac tylko do fetchowania danych ( i to dość nieefektywnego - hydracja przez refleksje, brr ) to spoko

Ale okej, więc załóżmy że modele

Przestań nazywać to modelem, bo to nie jest model xD

A co
@alex-fortune: Ale co z tego że nieefektywne? Szybko się pisze i łatwo utrzymuje. A DI Container jest fajnym pomysłem ale obawiam się że nadal przy większym projekcie gdzie jest kilka setek kontrolerów stworzyłby się lekki burdel.
Ale co z tego że nieefektywne? Szybko się pisze i łatwo utrzymuje


@plushy: Kiedy piszesz at scale ( mam na mysli setki milionow ++ uzytkownikow ) to ze sie szybko pisze nie ma zbytnio znaczenia. Łatwo utrzymuje pozostawię bez komentarza, bo "modele" ORM ( aka worki na dane ) są #1 powodem dla których ludzie zamiast enkapsulować logikę biznesową zaczęli ją wrzucać w kontrolery/managery/serwisy. Ile problematycznego kodu takiego zaorałem już nie
@alex-fortune: No, może jak piszesz na setki milionów to masz taki komfort. Ale jak masz zwykły projekt na kilka milionów userów i kilku programistów do utrzymania tego to nie możesz odrzucać wszystkich rozwiązań tylko dlatego że ci się nie podobają i chciałbyś fajniej.