[PHP][OOP]Walidacja, Klasa walidujaca, Opcje

[MateuszS]

Witam, zaczynam z OOP i napisałem prostą klasę walidującą dla małych formularzy, napiszcie co można poprawić, miałem ją zaopatrzyć w MVC i prezentować błędy widokiem ale to już na kiedy indziej.

[PHP] pobierz, plaintext 
//wlasciwa klasa w moim nastepnym poscie w tym temacie ;P
[PHP] pobierz, plaintext 

Ten post edytował MateuszS 21.04.2010, 17:23:14

[Crozin]

To zacznijmy od najłatwiejszego - przestrzeni nazw. Już pisałem jak się ich pozbyć - wystarczy usunąć namespace xxx { ... } no i pozmieniać nazwy klas, by sama nazwa oddawała lepiej charakter obiektu (teraz masz na przykład klasę: Error - i to jest ok, bo przestrzeń nazw (..\Validation) wskazuje, że jest to obiekt błędu walidacji. Bez przestrzeni nazw powinieneś to nazwać jakoś w stylu: ValidationError).

nie bardzo rozumiem jeszcze czemu używasz tyle walidatorów (obiektów)

Dwa powody:
1) Każdy obiekt powinien zajmować się jednym, wyspecjalizowanym zadaniem. Konkretne rodzaje walidacji to już zadanie na tyle złożone, że jeden obiekt nie powinien wykonywać wszystkich rodzajów walidacji (poza tym, że musi on posiadać jakąś metodę, sprawdzającą to może on jeszcze mieć masę wewnętrznych metod (z których korzystają te sprawdzające))
2) Elastyczność... Zawsze możesz utworzyć sobie nową klasę (wystarczy, że będzie ona implementować dany interfejs) i użyć ją jako walidatora... nie jesteś ograniczony do tych kilku walidatorów napisanych pierwotnie. Możesz również utworzyć nowy walidator, który będzie rozszerzeniem innego, już istniejącego. Zauważ, że teraz walidator Email sprawdza jedynie czy format emaila jest prawidłowy. Mógłbyś sobie napisać nowy walidator, który dziedziczy po nim, ale wykonuje jeszcze jedną operację... sprawdza czy domena, którą podano w mailu nie znajduje się przypadkiem na jakieś blacklist-cie.

Teraz mógłbyś napisać... "A to jak chcę sobie dodać jakąś dodatkową opcję do walidatora maila to czemu sobie nie mam zmodyfikować istniejącego już walidatora?"
I to jest generalnie prawda - mógłbyś, ale:
1) Jeżeli projekt jest już duży mogłoby to doprowadzić do zerwania kompatybilności
2) Z czasem możesz zrobić syf w kodzie, ciągle coś tam zmieniając

przekazujesz je jako wartość tablicy

Cóż... obiekt Walidator (ten, do którego dodajesz walidatory) musi w swoim wnętrzu wiedzieć jakie wartości jakim walidacjom poddać. Struktura: [nazwa pola] => obiekt walidatora, jest dosyć dobrą strukturą... ma swoje ograniczenia w postaci: jedno pole, jeden walidator - co na pewno musiałbyś rozbudować.

dlaczego to rozwiązanie ma przewagę nad pojedynczym obiektem

To już opisałem - przede wszystkim czytelność i elastyczność.

No i czy konieczna przy tym jest klasa abstrakcyjna/interfejs?

Zacznijmy od interfejsu...
No w teorii nie jest on do niczego potrzebny (PHP nie jest językiem silnie typowanym jak na przykład Java, w której raczej ciężko byłoby w ogóle skompilować kod bez użycia takiego interfejsu), ale zapewnia on zarówno polepszoną czytelność kodu (wszystkie IDE wyświetlając listę metod dostępnych dla obiektu od razu wskażą Ci, że ten parametr ma być obiektem implementującym coś tam, jak również i Ty sam czytając kod szybciej go załapiesz (po kilku tyg. nie patrzenia w niego) jak i zapewnia tego podstawową ochronę przed wrzuceniem czegoś niepoprawnego jako walidatora, przykładowo:

[PHP] pobierz, plaintext 
<?php
 
# Jeżeli metoda Validator::addValidator() ma tak zapisane parametery: $key, $validator, wtedy:
 
$v->addValidator('firstname', new PDO()));
 
# Zadziała... tzn. kod się uruchomi a Ty dostaniesz błąd, że nie można wykonać metody isValid na tym obiekcie.
# Jeżeli zaś metoda AddValidator() ma tak zapisane parametry: $key, Validatable $validator
 
$v->addValidator('firstname', new PDO()));
 
# To wywali Ci dużo przyjaźniejszy błąd: obiekt z drugiego parametru musi implementować interfejs Validatable - a nei robi tego
[PHP] pobierz, plaintext 

Na dobrą sprawę interfejsy w PHP nie są aż tak istotne (da się bez nich żyć) - tutaj wątek dot. sensu ich stosowania: Temat: Interfejsy - ale warto jest z nich korzystać.

Co do klasy abstrakcyjnej - jedyny powód, dla którego powstała to ten interfejs... wymusza on by obiekt go implementujący miał nie tylko metodę isValid, ale również dodatkowe: configure, getOpion, getOptions. Nie ma sensu bym w każdym walidatorze pisał te metody, skoro mają one robić dokładnie to samo - dlatego właśnie walidatory dziedziczą po Base (ValidatorBase w przypadku braku przestrzeni nazw).