Aplikacja domowa – zadanie

Share on facebook
Share on twitter
Share on linkedin

Tygodniowe zadanie

Nadszedł czas na wyznaczenie Ci kolejnego zadania po tygodniu czwartym.

Będzie już to jedno z większych zadań, oprócz samego dodawania nowego kodu będziesz musiał również zająć się jego refaktoryzacją – czyli zająć się wprowadzaniem edycji już do istniejącego kodu.

Stan

Póki co nasza aplikacja jest w takim stanie  – mamy stworzone Product i User Dao odpowiedzialne za relację z plikiem oraz Product/User serwisy, które nie są jeszcze połączone z klasami DAO.

Stan twojej aplikacji powinien wykonać podobnie, jeśli tak nie jest to wróć do zadań z poprzedniego tygodnia – jeżeli zaś czegoś nie rozumiesz to na początku każdego tygodnia czeka na Ciebie krótkie podsumowanie wykonanego zadania przeze mnie. 😉

Cel

Celów na ten tydzien jest sporo, zacznijmy od najprostszych zadań. 😉

  1. Stwórz wyjątki UserLoginAlreadyExistException, UserShortLengthLoginException oraz UserShortLengthPasswordException. Wszystkie niech mają konstruktor bezparametrowy i parametrowy, przez który przyjmują wiadomość. Pamiętaj, że muszą to  być wyjątki checked! Wszystkie wyjątki przechowywuj w pakiecie exception.
  2. Stwórz klasę UserValidator  – od poczatku zadbaj, aby była Singletonem! Stwórz w niej metodę isValidate(User user) – gdzie będzie sprawdzał czy: hasło ma minimum 6  znaków, login ma minimum 4 znaki oraz czy podany Login nie istnieje. Do sprawdzenia ostatniego punktu możesz wykorzystać klasę UserDaoImpl oraz metodę getUserByLogin lub napisać dodatkową isUserByLoginExist – która sprawdza czy taki login już istnieje. Preferowane jest drugie rozwiązanie. Pamiętaj, aby sprawdzanie powyższych trzech punktów w metodzie isValidate rozbić na trzy osobne metody – niech każda będzie prywatna. Jest to taka zasada clean code.
  3. W metodzie isValidate w przypadku, gdy jakiś warunek nie zostanie spełniony rzuć odpowiednim wyjątkiem utworzonym w zadaniu 1.
  4. Z klas ProductService i UserService zrób Singletony – usuń również listy z pól i konstruktora. Niech obiekty będą tworzone przez konstruktor bezparametrowy. Uprzedzam, że w tym momencie wysypią nam się testy, ponieważ w nich korzystamy właśnie z konstruktor, które teraz nie będą dostępne.
  5. W klasach ProductService i UserService zdefiniuj odpowiednie pola ProductDao UserDao. Wszystkie metody w serwisach niech korzystają z metod klas Dao. Np. mając metodę addUser(User user)  w UserService sprawdź poprawność danych przy użyciu UserValidate  i jeśli wszystko jest ok to zapisz przy użyciu metody saveUser(User user) z klasy Dao. Wniosek z tego zadania jest prosty – wszystkie metody z serwisów mają korzystać z metod DAO. 
  6. Z klasy UserDao zrób Singleton, niech nazwa pliku, do którego będą zapisywani Userzy  będzie zapisana jako stała.

Testy

Wykonując powyższe zadania nasz kod został poważnie zrefaktorowany, w takim razie póki co można usunąć testy, które napisaliśmy. Do testów wrócimy w kolejnych tygodniach. 😉

Podsumowanie

Spróbuj skorzystać z całych swoich sił, aby wykonać to zadanie chociażby po częsci – w kolejnym tygodniu wytłumaczę Ci jak można to zrobić. Jednak nie poddawaj się – wracaj do poprzednij lekcji, szukaj materiałów w internecie, a szczególnie na stackoverflow.com. Pamiętaj, że sporo pracy developera to szukanie rozwiązań i próba ich aplikowania u siebie.

W piątym tygodniu zajmiemy się kolejnym wzorcem projektowym – czyli Fasadą. Zaimplementują ją w naszej aplikacji, dzięki czemu otrzymamy ostateczną warstwę, z której będzie korzystał już użytkownik. Dodatkowo zrefaktoryzujemy ProductDao oraz ProductService, tak aby w prostszy sposób móc dodawać produkty różnych kategorii.

Moje przykładowe rozwiązanie możesz obejrzeć tutaj – jeśli coś jest dla Ciebie niejasne lub popełniłem gdzieś błąd to daj znać najlepiej w komentarzu. Niestety do 10 września mnie nie będzie, dlatego wszystkie sprawy publikuj tutaj lub na grupie Facebookowej. 😉

I to na tyle w czwartym tygodniu – daj znać jak się podobało, o ile się coś podobało, a co byś zmienił? Pamiętaj, aby pisać do mnie lub na grupie facebook w przypadku, gdy czegoś nie rozumiesz. Nie zostawiaj w głowie zagadnień, których do końca nie rozumiesz – bądź głodny wiedzy!

 

Kamil Klimek

Kamil Klimek

Pierwszy kalkulator napisany w języku Pascal w podstawówce. Później miałem trochę przygód z frontendem oraz PHP, na studiach poznałem C++ oraz Jave. Obecnie prawie 3 letnie doświadczenie jako Java full stack develop. Blog jest miejscem, dzięki któremu mogę się dzielić wiedzą i pomagać innym w nauce programowania.
Subscribe
Powiadom o
guest
4 komentarzy
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Poul
Poul
3 lat temu

Mam pytanie, czy rzucanie wyjątków np. w metodach klasy Productservice i UserSevice jest złą praktyką, i lepiej je łapać?

Kamil Klimek
Kamil Klimek
3 lat temu
Reply to  Poul

Pytanie dość abstrakcyjne, wszystko zależy od sytuacji.

Wyjątki powinniśmy łapać je tam gdzie chce w jakiś sposób na nie zareagować. Jeśli jakiś wyjątek w serwisie nas nie interesuje to możemy go „wypchnąć do warstwy wyżej” i tam się nim dopiero zajmować. 😉

Paweł Dębiński
Paweł Dębiński
3 lat temu

Mam pytania:)
1. Czy funkcja isLoginAlreadyExist() z klasy UserValidator nie wystarczy żeby sprawdzała: return !login.equals(null);
Było by to dużo prostsze rozwiązanie, ale pewnie coś przegapiam 🙂
2. Czy walidację za pomocą wyjątków robimy po to żeby je przećwiczyć czy jest to powszechnie stosowana praktyka. Bo na pierwszy rzut oka to sporo zachodu z tym, a wydaje mi się że zamiast rzucania wyjątków metoda mogła by po prostu zwracać: false?
3. Po co nam teraz klasy service? UserService korzysta w całości z klasy Dao, jedyne co dodaje nowego to użycie validatora, nie można by bezpośrednio korzystać z klasy Dao dodając do niej validator a klasę service skasować?

Kamil Klimek
Kamil Klimek
3 lat temu

Cześć, już śpieszę z wyjaśnieniami.
1. Oczywiście jest to lepsze i czytelniejsze rozwiązanie, jednak zastosowałem tamto, aby było zrozumiałe dla każdego. 😉
2. Rzucanie wyjątkami jest powszechnie stosowane, przypuśćmy, że mamy możliwie więcej opcji nie tylko dwie – wtedy typ boolean już nam nie pomoże. Wyjątki są dobrą opcją dla walidatorów.
3. Usuwając serwisy nasz kod stanie się mniej czytelny – usuniemy z naszej aplikacji zasadę pojedyńczej odpowiedzialności. Automatycznie klasa DAO będzie miała dwie odpowiedzialności – operację na pliku oraz walidację, dlatego moim zdaniem warto wydzielić to do serwisu. 😉

4
0
Would love your thoughts, please comment.x
()
x