Witam czytam właśnie o programowaniu obiektowym i zastanawiam się nad pewną kwestią.
Jeżeli dla danego obiektu wszystkie składowe będą dostępne za geterami i seterami, to autorzy
książki zalecają sprawdzanie poprawności danych w tych metodach i rzucanie np. wyjątków. Zastanawiam się nad praktycznym zastosowaniem, bo jeżeli wypełniony POST nie będzie miał poprawnej wartości to raczej nie będziemy chcieli
walić errorami. Spotkałem się z rozwiązaniem polegającym na tworzeniu klasy, która pobiera wartości np. z POST, a następnie zwraca tablicę z errorami, którą można wyświetlić. Taka klasa ma sens, ale co wtedy ze sprawdzaniem w geterach i seterach ? Olać czy powielać, co wpłynie negatywnie na wydajność. Mam nadzieję, że opisałem jasno.

1. Podwójne sprawdzanie nie wpłynie negatywnie na wydajność.
2. W setterach powinieneś raczej robić jedynie najbardziej podstawową walidację danych. Np. funkcja zwracająca pierwiastek kwadratowy może rzucić wyjątek gdy podamy jej liczbę ujemną, metoda która ma dodać coś do kolekcji unikalnych elementów może rzucić wyjątek w przypadku próby dodania duplikatu itp.

A po co walić errory, jak można odesłać z powrotem do formularza (nie mówiąc już o tym, że za pomocą HTML5 i JS można się w 99,9% zabezpieczyć przez nieprawidłowymi danymi). ; )



Powielanie kodu w OOP to grzech. Po co więc jakieś dziwactwa typu walidacja razy dwa? Nie lepiej przygotować klasę typu "SuperWalidator", która przejmie tą rolę i zrobi to "raz a dobrze" (tam gdzie trzeba)?

Jeżeli tworzenie i aktualizacja obiektu następuje tylko w jednym miejscu - formularz. To możesz odpuścić sobie walidacje w setterach. Jeżeli jednak obiekt jest w zależności z innymi które mogą zmieniać jego stan to powinien sam zadbać o jego spójność i walidować dane. Zamiast walić errorami możesz wyrzucać jakiś ogólnie przyjąty wyjątek np InvalidArgumentException lub ValidationException, co by go przechwycić w formularzu i nie grzeszyć podwójną walidacją