Witam Was,
może pomoglibyście mi zrozumieć programowanie obiektowe na przykładzie, który chodzi mi po głowie.
Projekt aplikacji: aplikacja przykładowa dla mnie aby napisać i zrozumieć strukturę obiektowości.
Aplikacja bankowa, która po wpisaniu Twojego ostatniego miesięcznego dochodu wylicza jakie pożyczki masz do wyboru.
Np. jest okienko do wpisania liczby z textem: tutaj wpisz kwotę wypłaty z ostatniego miesiąca(brutto) następnie kliknij OK. Po wpisaniu np. 3000 i kliknięciu OK mamy nowe okno z listą pożyczek które nam przysługują. Teraz powiedzmy, że będziemy mieć 4 opcje pożyczek: żadna jeśli nie zarabiasz minimum 2000, mała jeśli zarabiasz 2000, średnia jeśli zarabiasz 5000, duża jeśli zarabiasz 10000.
Żeby lepiej zrozumieć obiektowość od 30minut wypisuję sobie na kartce jak to wygląda:
klasa1: pożyczka
zmienna: kwota_pożyczki
obiektyP w pożyczce: żadna/mała/średnia/duża
informacja o zmiennej kwota_pożyczki przypisana do danego obiektu(obiekt duża= 10000,średnia= 5000, mała= 2000).
klasa2: wpisanie przez użytkownika:
zmienna: moje_zarobki
obiektZ: przechowywanie zmiennej moje_zarobki
metoda do wywolania: porównanie zarobków w stylu: jeśli obiektZ jest większy albo równy do któregoś z obiektówP to napisz to w konsoli. jeśli obiektZ jest mniejszy niż 2tys zł napisz w konsoli NIE DA RADY.
To tak w większym skrócie: są 2 klasy w każdej klasie są obiekty, zmienne oraz metoda do wywolania. klasa2 dziedziczy po klasie1?
dobrze to rozumiem?
Prosiłbym o pomoc i sory za chaotyczne rozpisanie tego ale chyba za długo już nad tym myślę i wszystko mi się kiełbasi
W tak trywialnym przykładzie w sumie nie ma co się dużo zastanawiać. Masz jakiś niemutowalny Value Object reprezentujący pożyczkę, klasę odpowiadającą za interakcję z użytkownikiem (wejście i wyjście) oraz klasę zajmującą się wyszukaniem odpowiedniej pożyczki, nazwijmy ją LoanFinder.
class LoanFinder {
Optional<Loan> find(int income) {
if (income < 2000)
return Optional.empty();
if (income < 5000)
return Optional.of(new Loan(2000));
}
I tak dalej. Oczywiście zamiast inta lepiej użyć BigDecimal jeżeli dopuszczasz kwoty po przecinku. Ewentualnie pożyczkę możesz przedstawić jako Enuma z wartościami SMALL, BIG itd, ale w tym przykładzie to chyba zbyteczne. Dziedziczenie wybij sobie z głowy dopóki nie będziesz na tyle doświadczony żeby wiedzieć gdzie faktycznie warto je stosować. Wbrew pozorom wcale nie jest tak przydatne.
dziękuję za pomoc, nie do końca rozumiem (jeszcze)
niemutowalny value object - nie ulegający zmianie ok rozumiem.
klasa interakcja z uzytkownikiem- ok
klasa zajmujaca sie wyszukaniem pozyczki- ok.
W takim razie value object tworzę w klasie do wyszukania pożyczki tak?
sory, że pytam ponieważ próbuję zrozumieć to na przykładzie: jakie klasy tworze, gdzie i jakie objekty umieszczam gdzie jest dziedziczenie.
dzięki za szybką odp.
ok dziedziczenie odpuszczam.
Klasa1 interakcji uzytkownika
klasa2 wyszukiwania pozyczki
gdzie tworzę wyżej wspomniane obiekty dotyczące pożyczki?
i czy klasa1: interakcja użytkownika, nie dziedziczy "metod" wyszukiwania pożyczki z klasy2?
Można to zrobić na wiele sposobów, w prawdziwym systemie bankowym mamy cały silnik decyzyjny biorący pod uwagę setki czynników przy wyliczaniu dostępnej pożyczki, no ale do celów naukowych nie musi być to przecież robione tak samo. Jeżeli zauważysz że masz coraz więcej rodzajów pożyczki i w klasie LoanFinder robi ci się bałagan, to wtedy warto pomyśleć o wydzieleniu jej fragmentu do innej klasy, ale póki co szukaj raczej prostych rozwiązań niż przekomplikowanych. Jeżeli chcesz zobaczyć jak wygląda bardziej rozbudowany projekt obiektowy na przykładzie bankomatu to zajrzyj tutaj: http://www.math-cs.gordon.edu/courses/cs211/ATMExample/
Rolę interakcji z użytkownikiem w sumie może pełnić klasa Main, albo możesz ją wydzielić i wołać z maina. Ta klasa powinna skorzystać z klasy LoanFinder do wyliczenia pożyczki na podstawie danych wczytanych od użytkownika, ale nie ma tu żadnego dziedziczenia.
Z przykładami typu konto bankowe jest taki problem, że autorzy podręczników chętnie się odwołują do tego tematu (gdyż są to realne problemy biznesowe, jeśli ktoś rozwija w firmie podobne aplikacje), jednak jeśli zaczynasz się czegoś uczysz, to i tak przecież nie napiszesz własnej aplikacji bankowej - tak więc z musu gdybanie o kontach bankowych bez realnego doświadczenia z branżą finansową jest dość średnie (więcej sensu miałaby nauka OOP na przykładzie własnego CMSa/silnika forum i kont użytkowników na nim. Albo zrobienie własnej gry i tworzenie klas, które będą reprezentowały poszczególnych graczy -- jeśli koniecznie chcesz zrobić sobie na potrzeby nauki klasę "konta" - bo przecież jest wiele sytuacji, kiedy żadne "konta" nie będą nawet potrzebne)
Generalnie trzeba się ubrudzić w kodzie i w realnych problemach, żeby nauczyć się dobrze projektować.
Silniki systemów bankowych są napisane na Oraclu w pl/sql'u