Mozliwosc sumowania pól Java - czy zrobiłem odpowiednio?

Witam
Napisałem mini programik cwiczac sobie jave:
Pierwsza klasa:

public class Próby 
{
	private int a;
	private int b;
	
	public Próby()
	{
		this(0,0);
	}
	
	public Próby(int a, int b)
	{
		this.a = a;
		this.b = b;
	}
	
	public int getA() {
		return a;
	}

	public void setA(int a) {
		this.a = a;
	}

	public int getB() {
		return b;
	}

	public void setB(int b) {
		this.b = b;
	}

	public int obliczDl()
	{
		return a+b;
	}
	
	public String toString()
	{
		return "Suma długosci to: " + obliczDl();
	}
} 

Druga klasa:

public class PróbyC extends Próby
{

	private int c;
	
	public PróbyC()
	{
		this(0, 0, 0);
	}

	public PróbyC(int a, int b, int c)
	{
		super(a,b);
		this.c = c;
	}
	
	public int obliczDl()
	{
		return ((super.getA()) + (super.getB()) + c);
	}
	
//	public String toString()
//	{
//		return "Suma długosci to: " + obliczDl();
//	}
} 

I chciałem spytać o dwie rzeczy:

1. czy zapis: " return ((super.getA()) + (super.getB()) + c); " jest poprawny? chodzi mi tutaj o pole "c", musze zrobic dla niego setter i użyć?
   No i czy wgl potrzebne są settery i gettery z klasy Próby? moze moge użyc "super.a" zamiast "super.getA()" i to samo z B?

2)Dlaczego mimo, że toString w klasie PróbyC jest zakomentowane, jak w klasie do testowania wywołam System.out.println(obiekt_klasy_ProbaC); to wyswietla sie metoda toString? jest ona dziedziczona w jakis sposob po klasie Próby?

pozdrawiam i prosze o wyrozumiałosc ;)

1. Używanie akcesorów jest o tyle lepsze że jak kiedyś zmienisz implementacje i nie będziesz miał pół "a" oraz "b" to program nadal będzie działał bo nie będzie bazował na wewnętrznej implementacji tylko na deklarowanym "zachowaniu" obiektów (czyli na liście operacji które można na nim wykonać). Implementacja może ulegać zmianie, ale zestaw operacji zmienia się rzadziej.
2. Oczywiście że jest, tak jak i każda inna metoda.

1. Używanie akcesorów jest o tyle lepsze że jak kiedyś zmienisz implementacje i nie będziesz miał pół "a" oraz "b" to program nadal będzie działał bo nie będzie bazował na wewnętrznej implementacji tylko na deklarowanym "zachowaniu" obiektów (czyli na liście operacji które można na nim wykonać). Implementacja może ulegać zmianie, ale zestaw operacji zmienia się rzadziej.

Hm.. ale jeśli zmienie implementacje pola "a" i "b" na jakieś inne nazwy np. to używając refactoringu (jesli dobrze zapamietalem) zmienic mozemy wszystkie pola w całej klasie z np nazwy "a" na nazwe "z". A czy klasy dziedziczące/potomne itp też beda miały zmienioną nazwe?

Jeśli nie to znaczy, że wewnatrz JEDNEJ klasy do ktorej należy pole moge śmiało operować nazwami pola żywcem, jeśli natomiast chce ustawić/pobrać wartosc tego pola w innej klasie to musze uzyc settera i gettera, zeby po refactoringu ładnie to współgrało (tzn zebym nie musial zmieniac w x-ilości klas nazwy "a" na "x")

Dobrze rozumiem? ;)

EDIT
a tak w ogóle, co sie dzieje jesli w klasie nie nadpisze metody toString, a wpisze ją do System.out.println(obiekt);
Wyswietla sie cos w stylu:
Próby@237aaeec

Co to oznacza?

ad edit: Nic nie oznacza. Zwykła stringowa reprezentacja obiektu i tyle.
ad.1. Nic nie rozumiesz. Nie chodzi tu o pierdółki typu nazwa zmiennej bo refaktor to załawi. Chodzi o faktyczne zmiany w kodzie. Przykład:

• mamy klasę która przechowuje informacje o kole, środek, promień i pole (bo nie chcemy go obliczać za każdym razem)
• jeśli nagle postanowimy że jednak pole możemy obliczać za każdym razem to:
  • jeśli używaliśmy dostepu przez pole musimy przerobić każdy fragment kodu który tego używał
  • jeśli używaliśmy akcesorów to zmieniamy tylko implementację metody i tyle :)

ad edit: Nic nie oznacza. Zwykła stringowa reprezentacja obiektu i tyle.

ale skadś sie chyba biorą te cyferki i literki?:P

Co do przykładu - szczerze powiem nie do końca rozumiem, dopiero zaczynam z obiektami i wszystkimi pojeciami z tym zwiazanymi, moze to dlatego

• mamy klasę która przechowuje informacje o kole, środek, promień i pole (bo nie chcemy go obliczać za każdym razem)
• jeśli nagle postanowimy że jednak pole możemy obliczać za każdym razem to:
  __- jeśli używaliśmy dostepu przez pole musimy przerobić każdy fragment kodu który tego używał
  • jeśli używaliśmy akcesorów to zmieniamy tylko implementację metody i tyle __

W podkreslonej częsci sie zaczynam gubić.
klasa przechowuje informacje o polu - tzn implementacje wzoru ktory oblicza pole czy może wartości pola?
A dostęp przez pole to np uzycie w innej klasie: System.out.println("Pole rowne" + obiekt.pole); ?
a jesli uzywamy akcesorów to.. nie bardzo tutaj łapie ^^ nie bijcie za mocno

ech..., co do toString: tak trudno zajrzeć do dokumentacji? http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Object.html#toString()

Prawde mówiąc szukałem ale nie mogłem znaleźć, nie wiedziałem ze jest bezposrednio w klasie Object ;)

A moze cos powiecie na temat tego co pisalem wyzej?

Wszystkie klasy dziedziczą po Object. A co do akcesorów, to są przecież zwykłe metody i nie zawsze muszą wyglądać tak:

jakis_typ getX() { 
return x;
}

lecz np.:

jakis_typ getX() { 
jakis_typ xx;
// jakieś operacje ustawiające wartość xx (*)
return xx;
}

I teraz jeżeli w kodzie nie korzystasz z akcesorów, to wszędzie, gdzie masz object.x musisz dorzucić kod (*). Jeżeli korzystasz z akcesorów, to wystarczy jedna zmiana w metodzie (lub akcesorze jak wolisz) getX.

PS. Tak w ogóle to najlepiej by było, gdybyś przerobił jakiś kurs z podstaw Javy (w necie tego pełno)

Tak właściwie to o wiele bardziej przejrzyście byłoby zmienić implementację przeciążonej metody w ten sposób:

@Override
public int obliczDl() {
    return super.obliczDl() + c;
}

lecz np.:

 jakis_typ getX() { 
jakis_typ xx;
// jakieś operacje ustawiające wartość xx (*)
return xx;
}

getX zwraca xx? chodzi tutaj o to, ze zmieniłem nazwe pola z "x" na "xx" i używając akcesorów nie bede musial zmieniac ich wszedzie tylko w samym akcesorze, a reszta bedzie pięknie działać?

PS. Tak w ogóle to najlepiej by było, gdybyś przerobił jakiś kurs z podstaw Javy (w necie tego pełno)

Mozesz mi wierzyc, mozesz nie :D ale czytam strasznie dużo tych kursów, wypożyczyłem pare ksiązek odnosnie javy, podstaw obiektowosci w javie itp. i czytam je, ale tutaj jest jakis przykład - i teoretycznie zrozumiały ALE! no własnie, jest jakieś ale: otóż jak przyjdzie mi zrobić własne zadanie, ktore sam wymysle to nie bede wiedział jak sie do niego zabrać. Drugie ale - to fakt, ze prawde mówiąc coś rozumiem ale nie bardzo mi świta w główce po co coś tam robić, po co to jest i dlaczego tak a nie inaczej.
Po prostu niepoukładana wiedza i oczywiscie jej brak :) staram sie ciagle ja pozyskiwać i uzupełniać układając stąd moje pytania

Tak właściwie to o wiele bardziej przejrzyście byłoby zmienić implementację przeciążonej metody w ten sposób:

Aff! nie wpadłbym na to, a to takie oczywiste, dzieki za te uwage!

EDIT
i własciwie po co jest to

@Override

? słyszałem, że jak sie popełni błąd (literówke) w zapisie metody to IDE wywali błąd, racja?;)