Jak na tak krótki czas, nie jest źle ale można coś poprawić. Więc:
1, Polskie nazewnictwo - pozbądź się go. Używaj angielskiego.
2. Komentarze - komentarze, które opisują po co jest dana funkcja/zmienna itd (np. BankAccount 20 linia) pozbądź się ich. Jeżeli uważasz, że coś takiego potrzebuje komentarza to albo masz złe nazewnictwo, albo funkcja coś za dużo robi. Komentarze zostawiaj tylko po to, aby wyjaśnić coś co może nie być aż tak oczywiste (np dlaczego w sprawdzaniu czy liczba jest pierwszą sprawdzasz do pierwiastka tej liczby) albo np opisując jakiegoś regexa.
3. W mainie u Ciebie za dużo się dzieje. W zupełności powinno wystarczyć coś jak: new Bank().run();.
4. Za dużo masz zagnieżdżeń (np BankAccount 57 linia). Pozbądź się tego np. rozbijając kod na funkcje/dodatkowe klasy.
5. Niepotrzebnie dwa razy otwierasz plik z Lokatą. Możesz przekazać plik/ścieżkę jednokrotnie. Np jeżeli plik istnieje i zostanie otwarty, przekaż ten plik jako parametr.
6. Nazywaj zmienne tak, żeby jasno mówiły do czego służą (nawiązanie do punktu 2.) np:
czyWykonanoZdarzenie = Saldo.getSaldo()
//(...)
historia[Historia.getLicznikZdarzen()].zapiszZdarzenieWyplaty(czyWykonanoZdarzenie - Saldo.getSaldo());
Do czego w końcu służy zmienna czyWykonanoZdarzenie? Nazwa sugeruje, że jest to jakaś flaga (zmienna typu bool) natomiast potem, używasz jej jako jakiejś liczby, odejmując coś od niej. Tak samo saldoLokaty.
if (saldoLokaty == 0){
System.out.println("Nie masz lokaty takim numerze!"
)
Czy saldoLokaty określa wartość lokaty, czy numer lokaty?
7. 0 < nrLok && nrLok <= lokata.length && nrLok <= Lokata.getLiczbaLokat() <-- Po co tak długi, nic nie mówiący warunek? Nie prościej wyrzucić to do jakiejś funkcji i nazwać funkcje jakoś ładniej, tak żeby od razu mówiły o co chodzi? Nie jest to z twojego projektu, ale żeby pokazać o co chodzi.Lepiej zmienić taki zapis:
if(zarobki>0 && zarobki<85000)
Na np:
if(czyJestWPierwszymProguPodatkowym())
I warunek wyrzucić do funkcji czyChodziDoPrzedszkola().
8. if (myLok.getRodzajZdarzenia() != "Empty") <-- Oj nie. Operator != nie służy do porównywania obiektów, jakimi niewątpliwie są Stringi.. Metoda equals do tego służy. Jeżeli już porównujesz zmienną String z tekstem, to lepiej zastosować Yoda expressions i zmienić to na: "Empty".equals(myLok.getRodzajZdarzenia()).
9. Odnośnie 8 punktu, zwykły String jest nieelegancki. Lepszym sposobem, jest używanie Enum'ów.
10. Puste funkcje - np. zapiszStan(), nic nie wnoszą do projektu.
11. Masz zmienne prywatne i wygenerowane tylko gettery. Do zmiany stanów obiektów służą Ci bardziej biznesowe metody [niż settery]. Za to plus.
12. Używaj mniej zmiennych static. Mocno ogranicza to rozbudowę aplikacji. Lepiej żeby obiekt składał się z innego obiektu, w którym będziesz miał jako pola (nie statyczne) saldo i utworzył taki obiekt niż używał static. Zastanowiłbym się też nad tym, czy nie dodać jakiejś klasy User który by miał Listę lokat jako pole i w klasie User byłaby informacja na temat salda wszystkich lokat.
Dodatkowo zmienne static utrudniają testowanie programów i mogą powodować niechciane zachowania. Globalny dostęp do zmiennej oznacza, że w każdym miejscu w programie, możesz zmienić jej wartość, co może utrudnić lokalizację błędu.
13. Funkcje takie jak np. otworzLokate() (w Lokata) mocno utrudniają możliwość przeniesienia tego na inne platformy. Jeżeli kiedyś byś chciał wykorzystać ją w programie z GUI (nie konsola) pobieranie wartości za pomocą Skanera i konsoli może być bardzo ciężkie.
14.Funkcje wypłata() lepiej nazwać wypłać(). Funkcje wpłata() - wpłać().
15. Tak jak kolega napisał. Dławienie wyjątków to nie jest dobry pomysł. Tak samo jak nadużywanie ich oraz try-catch - https://en.wikipedia.org/wiki/Coding_by_exception .
To na tyle.
