W metodzie authenticate możemy zostawić void'a i rzucać jakiś RuntimeException dla przykładu, wydaje mi się że też dobre rozwiązanie. Chętnie usłyszę opinie :)
Tak jest do jedna z opcji. W zasadzie znam dwa podejścia, jedno właśnie zakłada sterowanie wyjątkami - jest to łatwe w implementacji, ale bywa ciężkie w obsłudze jeśli mamy kilka warstw i wyjątek jest rzucany gdzieś głęboko wewnątrz i tak dalej. Drugie zakłada, że wyjątki rzucane są tylko faktycznie w "wyjątkowych sytuacjach" - złe hasło chyba takową nie jest - chyba że wcześniej jest jakaś walidacja na poziomie danych z HTTP - a w metodzie authenticate() upewniamy się, że do takiej sytuacji nie dojdzie - wtedy widzę zasadność. Oczywiście też używam wyjątków, ale kwestie jak walidacja czy rezultat z metody raczej staram się sterować w taki sposób jak pokazałem.
No i jeśli już to raczej nie RuntimeException, a najlepiej własny stworzony - ewentualnie InvalidArgumentException - tak by dokładniej dało się to obsługiwać w blokach try catch.
Biorąc na warsztat jakąś klasę "serwis", która np obsługuje nam klientów. Mam na myśli klasę zawierające metody do CRUD itp. Jeśli potrzebujemy coś więcej rozbudowywać jakieś procesy, przetwarzać, to dla tego przypadku też powinniśmy to tak rozkładać czy to ma zastosowanie tylko do jakiś konkretnych przypadków?
Moim zdaniem metody jak najbardziej warto rozdzielać - chyba że masz solidny powód żeby tego nie robić. Dobrym przykładem są wzorce kreacyjne jak fabryki, gdzie tworzony zostaje obiekt, czasem jeszcze modyfikowany i zwracany. Mimo, że zasada zostaje złamana to więcej zalet, niż wad.
W metodzie authenticate możemy zostawić void'a i rzucać jakiś RuntimeException dla przykładu, wydaje mi się że też dobre rozwiązanie. Chętnie usłyszę opinie :)
Tak jest do jedna z opcji. W zasadzie znam dwa podejścia, jedno właśnie zakłada sterowanie wyjątkami - jest to łatwe w implementacji, ale bywa ciężkie w obsłudze jeśli mamy kilka warstw i wyjątek jest rzucany gdzieś głęboko wewnątrz i tak dalej. Drugie zakłada, że wyjątki rzucane są tylko faktycznie w "wyjątkowych sytuacjach" - złe hasło chyba takową nie jest - chyba że wcześniej jest jakaś walidacja na poziomie danych z HTTP - a w metodzie authenticate() upewniamy się, że do takiej sytuacji nie dojdzie - wtedy widzę zasadność.
Oczywiście też używam wyjątków, ale kwestie jak walidacja czy rezultat z metody raczej staram się sterować w taki sposób jak pokazałem.
No i jeśli już to raczej nie RuntimeException, a najlepiej własny stworzony - ewentualnie InvalidArgumentException - tak by dokładniej dało się to obsługiwać w blokach try catch.
@@Koddlo to miałem na myśli, własny wyjątek rozszerzający RuntimeException, taki skrót myślowy :D
Biorąc na warsztat jakąś klasę "serwis", która np obsługuje nam klientów. Mam na myśli klasę zawierające metody do CRUD itp. Jeśli potrzebujemy coś więcej rozbudowywać jakieś procesy, przetwarzać, to dla tego przypadku też powinniśmy to tak rozkładać czy to ma zastosowanie tylko do jakiś konkretnych przypadków?
Moim zdaniem metody jak najbardziej warto rozdzielać - chyba że masz solidny powód żeby tego nie robić. Dobrym przykładem są wzorce kreacyjne jak fabryki, gdzie tworzony zostaje obiekt, czasem jeszcze modyfikowany i zwracany. Mimo, że zasada zostaje złamana to więcej zalet, niż wad.