odpowiedz na facebooku

1) Switch jest fajny... ale nie za bardzo.
Nie krytykuję użycia tutaj ale jeżeli się już go chwyciłeś to spróbuj JDK 14 - tam zdaje się wprowadzili nową, lepszą składnię.

2) W switch-case (zakładając że bym go w ogóle w tym przypadku użył) ja bym poukładał / posortował case'y wg:

 addNewWorker();
 fillWorkerAdditionalData();
 fillWorkingDaysStatics();
 salary.printS-L()
 salary.printW-L()

Ale to jest akurat mało istotne poza czytelnością kodu.

3) Metoda  addNewWorker() ... jak sama nazwa skazuje ponoć dodaje pracownika (employee?).
No dobra, to jedziemy z kodem i spodziewamy się, że faktycznie tak ma robić konwencji nazewniczej.
I co widzimy?

Tworzenie Worker'a:
 - wypisywanie tekstu na ekran
 - ustawianie zmiennych (PESEL, city, birthDay, baseSalaryGross )
 - tworzenie obiektu Worker z w/w danymi
Dodawanie obiektu worker do (jak mniemam) pola salary w klasie // Aktualizacja: źle stwierdziłem, bo to jest (wg komentarza z opisu programu na facebooku) to jest boolean który sygnalizuje niepowodzenie.
Wywiływanie metod na obiekcie worker:
 - worker.fillWorkerAdditionalData();
 - worker.setWorkingDays(5);

3a) Zmienna lokalna PESEL jest pisana cała wielkimi znakami - raczej nie jest to zgodne z konwencją nazewniczą w Java. Ja wiem, że "PESEL" dla oka wygląda fajniej niż "pesel" ale konwencja to konwencja, a wielkie litery oznaczają że to może być stała.
3b) baseSalaryGross - to jest podstawowa pensja brutto. Skoro tak to czemeu jest w "int" a nie np. w BigDecimal?
3c) do tworzenia obiektu klasy Worker można spróbować użyć wzorca projektowego budowniczy. A przy okazji się nauczysz że ktoś kiedyś wymyślił już koło.
https://pl.wikipedia.org/wiki/Budowniczy_(wzorzec_projektowy)
3d) worker.setWorkingDays(5); // Tutaj ustawiasz na sztywno "5" dni roboczych. Skoro jest na sztywno to ja bym użył tutaj stałej w klasie:
private static int WORKING_DAYS_5 = 5;

3 podsumowanie)
Czyli metoda addNewWorker() robi tworzenie, wypisywanie, dodawanie workera do pola klasy, DOPIERO TERAZ wywołuje metody na obiekcie worker (czyli zmienia jego stan).
Czyli jest źle. Bo wg założeń metoda ma robić tylko to co jest napisane w jej nazwie i nic więcej i nic mniej.
Poczytaj też o SOLID https://pl.wikipedia.org/wiki/SOLID_(programowanie_obiektowe)

I metoda addNewWorker() wyglądała by i nazywała by się tak:
 private Employee getEmployeeDataFromUser() {
   Employee emp = displayEmployeeInformation()
   return createEmployee(emp)
 }

Wiesz, ustawiasz pole klasy (jak mniemam też musi być statyczne) na obiekt Worker. A potem w tej metodzie jeszcze modyfikujesz ten obiekt. Więc może najpierw go zmodyfikuj a potem zwróć z metody zwykłm return'em.
Wtedy ani pole nie musi być statyczne, ani metoda. Ze static'ami jest więcej kwestii niż myślisz - ale to może ktoś kto wie by się wypowiedział w której części pamięci JVM są one przetrzymywane oraz w kestii pracy garbage collector'a.
Do tego dojdzie kwestia wielowątkowości. Np. jeżeli w twojej aplikacji wprowadzisz wiele wątków które będą sobie działać na polach/metodach statycznych - to sam kiedyś zobaczysz, że dzieją się dziwne rzeczy. I żeby temu zapobiegać musisz wprowadzać bloki statyczne i specjalne modyfikatory.
A jeżeli tak zrobisz to jeden tylko wątek będzie mógł przetwarzać dany fragment kodu - a wtedy tracisz wielowątkowość de facto.
Póki co statici olej.

4) Metoda fillWorkerAdditionalData()
A więc to jest ta słynna metoda z dodatkowymi danymi która po nazwie ... robi dodatkowe rzeczy - nie wiadomo do końca na czym.
A nie wiadomo, bo:
ustawia:
- name
- surname
- sex
- phoneNumber
..

I TERAZ - CUDA !!!

        Worker.fillWorkerAdditionalData();  // wywołujesz statyczną metodę z klasy Worker
        worker.fillWorkerAdditionalData();  // wywołujesz (próbujesz) wywołać statyczną metodę z obiektu klasy Worker
        worker.setWorkingDays(5); // A tutaj po raz kolejny ustawiasz mu 5 dni roboczych

No nie wiem czy taki był twój zamysł czy to tylko literówki czy what-da-fak ale to działać tak nie może.
Zresztą po co rozdzialać pobieranie danych od użytkownika na temat Employee na dwa różne zestawy pytań, skoro można je pobrać za pierwszym razem.


4a) A co się stanie jeżeli użytkownik podczas wpisywania tekstu naciśnie np. CTRL+C ? Albo wprowadzi baaaardzo dużą ilość znaków? albo nic nie wpisze i naciśnie ENTER?
Walidacje trzeba zrobić.

5) Widzę komentarz typu:
//boolean ktorej zadaniem jest sprawdzenie czy dodanie pracownika się udało

Nie, nie, nie. Nie idźcie tą drogą. Jeżeli coś się ma niepowieść - to wyrzuć sztucznie "twój" wyjątek. A potem gdzieś "wyżej" go przechwyć i zareaguj odpowiednio. Po to są wyjątki.

6) Poczytaj sobie o wzorcach projektowych. Na początek tak pobieżnie chociaż o tych podstawowych GoF (Gang of four). Może ci się przydadzą kiedyś.

7) Zacznij myśleć o kodzie w Javie jako kodzie obiektowym - bo taka właśnie Java jest i do obiektowego programowania powstała.
Do metody przekazujesz argumenty, ona je przetwarza i zwraca "wynik" jako obiekt.
A u ciebie jest np.
addNewWorker() - bez argumeentów
metoda coś tam mieli, tworzy, wykonuje cuda wianki przy czym zmienia zewnętrzny stan pól statycznych w klasie
i na końcu metoda niczego nie zwraca.

8) Jak już na siłę używasz String.out.print() to można tę klasę zaimportować statycznie. Wtedy w kodzie nie musisz pisać każdorazowo:
 String.out.print()
tylko:
 out.print()

9) Tak się zastanawiam jak w łatwy sposób rozwiązać u ciebie problem typu:
 - zestaw pytań które zadać użytkownikowi
 - i przechowywać do każdego pytania odpowiedź użytkownika

I jak to osiągnąć? co? Zamiast beszczelnie wypisywać String.out.print() tekst i potem scanner.nextLine()

Czyli jak stworzyć sobie listę złożoną z elementów:
Pytanie - Odpowiedź
String - String

A może by tak sobie stworzyć klasę... która by przechowywała w sobie Pytanie i jej Odpowiedź?
class QAClass { // he he, trzeba się zastanowić jak ją sensownie nazwać
   public String question;
   public String answer;
}

A potem stworzyć wiele takich pytań o konkretnej treści i stworzyć z nich "łańcuszek"?

qa1 = new QAClass("Podaj imię pracownika:")
qa2 = new QAClass("Podaj telefon:")

List<QAClass> listaPytań = new LinkedList<>();

listaPytań.add(qa1)
listaPytań.add(qa2)


A potem aby zadać otrzymać wszysktie odpowiedzi:

for(QAClass qa: listaPytań) {
  System.out.print( qa.getQuestion() )
  qa.setAnwer(  scanner.nextLine() )
}


A jak potem stworzyć z listy odpowiedzi obiekt Employee?
aaa w zasadzie to ta klasa nie jest nam już w ogóle potrzebna ALE jeżeli ktoś by się uparł to się da. Ale trzeba tutaj na sztywno wiedzieć któro pytanie w kolejności jaką odpowiedź przetrzymuje.
Tzn. Klasa LinkedList przechowuje pytania w odpowiedniej kolejności. Więc wyciągając element spod konkretnego indexu wiemy co on zawiera:

Employee emp = new Employee();
String odpowiedź = listaPytań.get(1) // będzie imie pracownika
emp.setName( odpowiedź )