• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Jak napisać walidację danych formularza i wysyłanie e-maila dbając o zasady S.O.L.I.D ?

Object Storage Arubacloud
0 głosów
410 wizyt
pytanie zadane 22 października 2019 w PHP przez Artek Stary wyjadacz (11,800 p.)
Mam kod php który waliduje informacje wysłane w formularzu(kontakt użytkownika, temat, treść, google recaptcha) przez użytkownika i wysyła maila. Ostatnio czytałem co nieco o zasadach S.O.L.I.D i pewne rzeczy mnie zastanawiają.

No weźmy pierwszą zasadę : single responsibility principle. Klasa powinna mieć tylko jeden powód do zmiany. W takim razie czy powinienem :

a) zrobić jedną klasę do wysyłania maila, walidacji danych i generowania raportu

b)zrobić kilka klas : 1 do walidacji danych, 1 do wysyłania maila, 1 do generowania raportu

c) zrobić jeszcze więcej klas : 1 do walidacji danych kontaktowych, 1 do walidacji google recaptcha , 1 do walidacji treści wiadomości, 1 do walidacji tematu wiadomości, 1 do wysyłania i 1 do generowania raportu?

3 odpowiedzi

+3 głosów
odpowiedź 23 października 2019 przez mokrowski Mędrzec (156,220 p.)

Nie traktuj ani S.O.L.I.D. ani GRASP jako jedynie słusznej drogi implementacji. Nawet zasada SRP ma w swojej intencji, bronić przed zbyt dużą ilością odpowiedzialności. W praktyce jeśli dochodzi Ci odpowiedzialność np. logowania zdarzeń, niby łamiesz zasadę dodając do kodu klasy tę odpowiedzialność, ale z zasady zachowujesz dalej kontrolę intelektualną nad kodem. Wymaganie związane z logowaniem zdarzeń jest wymaganiem aspektowym. A zdrowy rozsądek jest ważniejszy niż zakładanie czapki z daszkiem z napisem "I'm S.O.L.I.D.". Łatwo można przegiąć i w drugą stronę budując 9 warstwę abstrakcji na warstwach abstrakcji które kiedyś może się przydadzą.

Zapewne oczekujesz precyzyjnej odpowiedzi. Toteż najbliżej jest b). Ale bądź elastyczny i zastanawiaj się czy wracając do kodu po 1 msc., będziesz w stanie szybko zrozumieć co w nim popełniłeś. Nie zamykaj się także w twierdzy z napisem "Tylko OOP". Walidator przecież nie zawsze koniecznie będzie klasą i może być np. zwykłą funkcją :)

komentarz 23 października 2019 przez Artek Stary wyjadacz (11,800 p.)
No ciekawa wypowiedź. Przyznam mam trochę mętlik teraz. Kolega wcześniej napisał, że odpowiedź c, Ty podajesz b :D

Jak tak myślę o tym co napisałeś to rzeczywiście chyba coś jest na rzeczy. Jak tak sobie pomyślę to w opcji C) musiałbym napisać chyba z 7 klas z czego każda klasa uruchamiałaby zapewne 1 funkcję - trochę to przekombinowane czyż nie?
1
komentarz 23 października 2019 przez mokrowski Mędrzec (156,220 p.)
"Czyż tak".

Zachowaj zdrowy rozsądek. Jeśli kod będzie się komplikował i zaczyna się rozmywać jego odpowiedzialność, to to także jest powód do jego separacji i ew. zmiany a nie polowanie na obiektowe jednorożce. W każdej metodyce/dobrej zasadzie, wyłapuj jej intencje a nie fanatyczny aspekt.

Paradygmaty programowania to narzędzia. W mojej ocenie jest trochę głupio iść przez życie jako fanatyczny wyznawca młotka tylko jednego producenta.
komentarz 23 października 2019 przez Artek Stary wyjadacz (11,800 p.)
Brzmi sensownie. Czy może ktoś ma odmienne zdanie na ten temat?

Poza tym fajne określenie : polowanie na obiektowe jednorożce :D
+1 głos
odpowiedź 22 października 2019 przez Paweł Antyporowicz Stary wyjadacz (11,470 p.)

No weźmy pierwszą zasadę : single responsibility principle. Klasa powinna mieć tylko jeden powód do zmiany.

Błędnie rozumiesz tą zasadę, ta zasada mówi, że każda klasa i funkcja powinna mieć pojedynczą odpowiedzialność. Więc opcja "C" będzie najbliższa tej zasadzie.
Co do walidacji, możesz poćwiczyć i skorzystać z kolejnej zasady SOLID, chodzi mi dokładnie Open/closed principle i stworzyć interfejs, który będzie implementowany do klas służących do walidacji.

Taki mały przykład na szybko z interfesju:

interface ValidatorInteraface
{
    public function validate($value): ValidatedObjectInterface;
}

interface ValidatedObjectInterface
{
    public function isValid(): bool;
    public function message(): string;
}

 

komentarz 22 października 2019 przez Artek Stary wyjadacz (11,800 p.)
Dziękuję za przykładowy kod. Ponadto posiadanie pojedynczej odpowiedzialności jest jednoznaczne z jednym powodem do zmiany. Przynajmniej tak jest napisane chyba w każdym tutorialu na ten temat.
0 głosów
odpowiedź 22 października 2019 przez UltraSF Stary wyjadacz (11,740 p.)
Chciałbym jedynie zauważyć że według DDD obiekt sam się waliduje
Czyli SomeFacotry::create() => ContactDataDTO => Form => ContactData->validate()
Tak w uproszczeniu
komentarz 22 października 2019 przez Artek Stary wyjadacz (11,800 p.)
Przyznam, że nie czaję :D
1
komentarz 22 października 2019 przez mokrowski Mędrzec (156,220 p.)

@UltraSF, kolega pytał o S.O.L.I.D. a nie DDD.

1
komentarz 23 października 2019 przez Comandeer Guru (603,480 p.)

@UltraSF, poza tym nie do końca rozumiem, czemu DTO i encja mają być od razu DDD?

komentarz 23 października 2019 przez UltraSF Stary wyjadacz (11,740 p.)
Comandeer nie rozumie, bo nie napisałem przecież że encje i dto to 100% DDD xd Napisałem tylko że można pójść za myślą DDD  i zrobić samo walidujące się obiekty :D to w sumie też odpowiedzi dla mokrowski
komentarz 23 października 2019 przez UltraSF Stary wyjadacz (11,740 p.)
Muszę precyzyjniej wyrażać swoje myśli, sorki :D
komentarz 23 października 2019 przez Comandeer Guru (603,480 p.)

można pójść za myślą DDD  i zrobić samo walidujące się obiekty

To chyba nie do końca tak. W DDD istnieje zasada "always valid entities", niemniej niekoniecznie encje muszą same siebie walidować → https://enterprisecraftsmanship.com/posts/validation-and-ddd/

Co więcej, na poziomie aplikacji, zanim to trafi do encji, możemy chcieć przeprowadzić inną walidację, sprawdzając dane sensowne z punktu widzenia samej warstwy aplikacji (CAPTCHA, zabezpieczenie anti-CSRF itd.), ale całkowicie nieistotne z perspektywy encji.

komentarz 23 października 2019 przez mokrowski Mędrzec (156,220 p.)

 @UltraSF, oj kolego. Po prostu odpowiadaj precyzyjnie na pytanie Bo idąc tą drogą w tygodniu w którym zainteresujesz się CQRS odpowiesz inaczej a w dniu w którym "functional aproach" będzie jedynie słuszny wyjedziesz z teorią kategorii i próbą tłumaczenia monad :-)

Ktoś pyta o samochód a odpowiedź "najzdrowiej jeździć rowerem". Niby prawda.... ale mało przydatna.....

komentarz 25 października 2019 przez UltraSF Stary wyjadacz (11,740 p.)
Euh @Comandeer no tak przecież nie napisałem że w DDD samowalidującę się obiekty domeny to jedyna walidacja, albo że to jedyna słuszna droga, także wgl nie rozumiem Twoje odpowiedzi.
 

@mokrowski tutaj to totalny świat fantazji nie jestem w stanie się ustosunkować :(
komentarz 25 października 2019 przez Comandeer Guru (603,480 p.)
Fakt, tylko rzuciłeś hasłem i trzeba było sobie dorobić resztę do tego. Niemniej zwróciłem uwagę, że niekoniecznie w DDD są samowalidujące się obiekty – bo to samo w sobie dla DDD nie jest aż tak istotne.
komentarz 25 października 2019 przez UltraSF Stary wyjadacz (11,740 p.)

Fakt, tylko rzuciłeś hasłem i trzeba było sobie dorobić resztę do tego

Polecam nie dorabiać

Niemniej zwróciłem uwagę, że niekoniecznie w DDD są samowalidujące się obiekty – bo to samo w sobie dla DDD nie jest aż tak istotne.

Oczywiście że tak :) 

Podobne pytania

0 głosów
1 odpowiedź 159 wizyt
pytanie zadane 25 sierpnia 2020 w C# przez Adrian1999 Nałogowiec (34,570 p.)
0 głosów
2 odpowiedzi 484 wizyt
0 głosów
1 odpowiedź 164 wizyt
pytanie zadane 10 czerwca 2020 w PHP przez XiverKi Bywalec (2,050 p.)

92,757 zapytań

141,679 odpowiedzi

320,429 komentarzy

62,101 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Akademia Sekuraka

Niedawno wystartował dodruk tej świetnej, rozchwytywanej książki (około 940 stron). Mamy dla Was kod: pasja (wpiszcie go w koszyku), dzięki któremu otrzymujemy 10% zniżki - dziękujemy zaprzyjaźnionej ekipie Sekuraka za taki bonus dla Pasjonatów! Książka to pierwszy tom z serii o ITsec, który łagodnie wprowadzi w świat bezpieczeństwa IT każdą osobę - warto, polecamy!

...