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

Question

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?

Answer 1

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ą :)

Comments

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?

---

"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.

---

Brzmi sensownie. Czy może ktoś ma odmienne zdanie na ten temat?

Poza tym fajne określenie : polowanie na obiektowe jednorożce :D

Answer 2

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;
}

 

Comments

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.

Answer 3

Chciałbym jedynie zauważyć że według DDD obiekt sam się waliduje
Czyli SomeFacotry::create() => ContactDataDTO => Form => ContactData->validate()
Tak w uproszczeniu

Comments

Przyznam, że nie czaję :D

---

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

---

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

---

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

---

Muszę precyzyjniej wyrażać swoje myśli, sorki :D

---

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.

---

 @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.....

---

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ć :(

---

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.

---

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 :)