Sprawdzenie poprawnosci get i set

Tylko cena ksiazki moze sie zmieniac w czasie, a reszta jest tylko do odczytu. Dobrze to zrobilem ?

package ksiegarnia;

public class Ksiazki {
    private String tytul,autor;
    private int liczba_stron, rok_wydania, cena ;

    public String getTytul() {
        return tytul;
    }

    public String getAutor() {
        return autor;
    }

    public int getLiczba_stron() {
        return liczba_stron;
    }

    public int getRok_wydania() {
        return rok_wydania;
    }

    public int getCena() {
        return cena;
    }

    public void setCena(int cena) {
      this.cena = cena;
    }
    
    
    
}

nie ma to za bardzo znaczenia, że tylko cena się zmienia a reszta nie, i przydałby się jakiś konstruktor czy coś, bo jak chcesz korzystać z klasy?

	private String tytul,autor;
	private int liczba_stron;
	private LocalDate rok_wydania;
	private double cena;

rok_wydania to raczej data, bo nie wiem jak to zapisać jako liczbę całkowitą
cena też nie powinna być double, bo double i float traci swoją dokładność po kilku operacjach na nich.

A co do konstruktora to w tym przypadku powinien byc tylko z parametrem "cena", czy bezparametrowy ?
Albo inaczej po stworzeniu obiektu w jaki sposób mozna sie dostac do pól obiektu poprzez metody?

package ksiegarnia;

public class Ksiazki {
    private String tytul,autor;
    private int liczba_stron, rok_wydania, cena ;

    public Ksiazki(){
    }
    public String getTytul() {
        return tytul="Lalka";
    }

    public String getAutor() {
        return autor="Boleslaw Prus";
    }

    public int getLiczba_stron() {
        return liczba_stron=100;
    }

    public int getRok_wydania() {
        return rok_wydania=1999;
    }

    public int getCena() {
        return cena;
    }

    public void setCena(int cena) {
      this.cena = cena;
    }
    
    public void PokazDane(){
    System.out.println("Tytuł"+getTytul());
    System.out.println("Autor"+getAutor());
    System.out.println("Liczba stron"+getLiczba_stron());
    System.out.println("Rok wydania"+getRok_wydania());
    System.out.println("Cena"+getCena());
   
    }
    
}

package ksiegarnia;

public class Ksiegarnia {

   
    public static void main(String[] args) {
       Ksiazki lalka = new Ksiazki();
       lalka.PokazDane();
       lalka.setCena(19);
       lalka.PokazDane();
       //lalka.autor="aha";
    }
    
}

nie jest błędem jak klasa ma konstruktor bezparametrowy, więc ja zostawiam
drugi konstruktor, jak nie chcesz robić setterów, to zrób ze wszystkimi polami

	public Ksiazka(String tytul, String autor, int liczba_stron, LocalDate rok_wydania, double cena) {
		this.tytul = tytul;
		this.autor = autor;
		this.liczba_stron = liczba_stron;
		this.rok_wydania = rok_wydania;
		this.cena = cena;
	}

Wszystko też zależy od problemu i trzeba się zastanowić jaki konstruktor będzie ci potrzebny. Bo można mieć np książkę, która nie ma daty wydania. I taki konstruktor też się przyda.

trojanus napisał(a):

rok_wydania to raczej data, bo nie wiem jak to zapisać jako liczbę całkowitą

Możliwości jest wiele. Jako czas uniksowy, jako reprezentacja samego roku (np. 1968) itd.

cena też nie powinna być double, bo double i float traci swoją dokładność po kilku operacjach na nich.

OK, do ceny są używane specjalne typy danych, ale serio double straci dokładność do drugiego miejsca po przecinku?

@TomRiddle: musiałem post dołożyć, bo 580 znaków to za mało na mój wywód :)

Zgoda, dokładność w przykładzie 0.3d + 0.6d jest tracona na n-tym miejscu, ale ma wpływ na wynik już na 1 miejscu po przecinku.
Jak dodaję na zwykłym kalkulatorze dwie liczby rzeczywiste jak w podanym przykładzie to oczekuję wyniku 0.9, a nie 0.899999... no to jeszcze sobie zaokrąglę w górę, bo kalkulator jest niedokładny.
W sytuacji gdzie robię kilkanaście takich operacji i jeszcze trzeba coś podzielić lub odliczyć procenty to ta dokładność spada. Zrobię testy i będą się zgadzać.
Ale wezmę kartkę papieru, ołówek i kalkulator i okazuje się, że wynik policzony ręcznie różni się od tego z programu.
Chodzi mi o to, że był to spory problem w branży bankowej, gdzie takich operacji jest wykonywanych miliardy miesięcznie. I teraz jak pogodzić fakt, że aplikacja jednemu dodała milion razy po 0.0003 złotego? Kto ma to zapłacić? Bank czy może inni klienci?
Dlatego do takich obliczeń został stworzony BigDecimal, który na dokładności nie traci i jest używany w produkcji, zamiast double czy float.
Do sedna: w powyższym przykładzie klasy, pole cena powinno być BigDecimal, zamiast int (bo nikt nie podaje tak ceny, bo zwykle jest 0.99 na końcu) i niedokładnego double/float.

Żaden wbudowany typ danych liczbowych nie rozwiązuje problemu pieniędzy, bo po pierwsze nie przechowuje wartości o walucie, po drugie nie potrafi podzielić kwoty z sensownym zaokrągleniem groszy. Poczytajcie o "money pattern".