Projektowanie obiektowe - zwracanie wyniku walidacji.

Question

Cześć.

Problem: muszę napisać klasę walidator zgodną z zasadami SOLID. Walidacja może pójść źle z kilku powodów. Chciałbym poza booleanem isValid zwrócić powód niepowodzenia.

Czego już próbowałem:

• zwracanie enuma ValidationFailureCause nie wchodzi w gre, bo enumy łamią zasade open-closed 
• zwracanie klasy ValidationResult z polami boolean na każdy test prowadzi do stworzenia anemic domain model
• uniknięcie anemicznego modelu przez wrzucenie walidacji do ValidationResult jakoś mi nie leży, bo walidacja przebiega na podstawie danych przesłanych do klasy i wtedy metoda validate klasy ValidationResult wygladalaby tak:

  public static ValidationResult validate(Input input, SomeExternalData data);
  

W tym momencie najbardziej przychylny jestem zwróceniu boolean'a oraz metodzie getLastFailureCause() zwracającej String z powodem niepowodzenia. Wtedy gdy walidacja sie nie powiedzie to zwracam się do walidatora o powod. 

Która z moich propozycji jest najbardziej czysta? A może powinien to rozwiązać w jeszcze inny sposób?

Comments

Tak się zastanawiam, nie jestem pewien a chce też się dowiedzieć, czy rzucenie odpowiednim wyjątkiem łamie w jakiś sposób założenia solid/clean code? Teoretycznie można byłoby utworzyć Klase dziedziczaca po exception i rzucić nim jeśli jakaś zależność wystąpi.

---

Problem w tym, że niepoprawny input dla walidatora to chleb powszedni i nie jest to wyjątkowa sytuacja, a zatem nie możemy kontrolować normalnego przebiegu programu za pomocą wyjątków.

Answer 1

Witaj, programuję w C# ale postaram się w pseudokodzie/opisie przedstawić ideę, jak będzie trzeba to mogę napisać kod w C#, a nawet w javie ale piszę z "marszu".

Nasuwa się pytanie pierwsze, czy chcesz wiedzieć dokładnie, która reguła zwróciła błąd czy tylko, że jest błąd i np.: w stringu opis wszystkich reguł które się nie powiodły ale to zawsze będziesz mógł sobie zmienić.

Moja propozycja jest następująca oczywiście, zawsze możesz zrobić te jako klasy generyczne, czyli w zależności od typu.

Powiedzmy, że masz konkretną klasę Validator (można oczywiście dodać interfejsy kwestia detali), która ma metody walidacyjne, detale potem wszystko też zależy jak chcesz tego używać ale postaram się przedstawić koncepcję.

Dodatkowo mamy klasę ValidationRule, która jest pojedynczą regułą i ma powiedzmy metodę bool IsValid oraz właściwość string ValidationError ale oczywiście można to delikatnie zmienić, żeby zwracała ValidationResult (która ma bool Is Valid oraz string z błędem, kwestia smaku).

Załóżmy, że chcesz zwalidować swój input używając trzech reguł więc tworzysz, trzy konkretne klasy ValidationRule i przekazujesz je jako lista do konstruktora Validator, a następnie w metodzie IsValid sprawdzasz wszystkie reguły i zwracasz odpowiedni rezultat, a dodatkowo inną metodą (np ValidationErrors) jeśli IsValid jest false zwracasz string lub listę stringów lub ValidationResult(s) jako listę (kwestia implementacji) i wiesz dokładnie który element z listy i dlaczego spowodował błąd walidacji.

Oczywiście konkretna implementacja będzie zależeć od wielu szczegółów tego co chcesz i jak zrobić ale wydaje mi się, że przedstawiłem ogólne podejście.

BTW: SOLID to tylko drogowskaz/definicja/reguły/pomoc :-) jak nie wiesz co zrobić to używasz SOLID i wtedy prawie zawsze powinno być ok, ale od każdej reguły można odejść o ile wie się dlaczego i co to powoduje (to gdzieś w necie znalazłem w podobnym brzmieniu).

Answer 2

Najpopularniejszy framework spring rozwiązuje to w taki sposób że zwracany jest obiekt result który ma metody takie jak hasError, getAllErrors, getFieldError itd.

Dam Ci jeszcze jeden sposób do przemyślenia, w programowaniu funkcyjnym jest dość popularne użycie klasy Either która może przyjąć jedną z dwóch wartości. Przyjmuje się że jedna jest poprawna a druga reprezentuję błąd. Korzysta sie z niej wtedy gdy zwykły optional nie niesie wartości o przyczynach błędu.

Answer 3

Zwróć klasę implementującą interfejs ValidationResult która w zależności od tego czy wynik jest poprawny czy nie, rzuci wyjątkiem w trakcie pobrania zawartości tegoż wyniku. Jeśli nie chcesz obsługiwać tego wyjątkiem (a przecież będzie do obsłużenia lokalnie w kodzie pobrania wartości), to dodaj do klasy predykat isValid(). Na podstawie jego wartości (true/false), wykonasz operację obsługi.

W takiej obsłudze OCP nie łamiesz bo z łatwością wprowadzisz nową klasę bez zmiany istniejącego kodu a anemii domeny także nie będziesz miał bo zwracasz określony rezultat operacji. Ew. predykat także nie generuje problemu bo jest jeden i ściśle dotyczy klasy zwracanej.