Java - this - używać czy nie?

Cześć, mam pytanie dla osób, które już trochę z Javą pracują. Chodzi mi o używanie słowa kluczowego 'this'. Jak na razie programowałem w OOP tylko w językach, gdzie dostęp do składowej/metody musiiał być poprzedzony 'thisem'. W javie jest inaczej, bo można go stosować, lub nie. O ile w konstruktorze jest zrozumiałe, że 'this' rozróżnia nam to do czego chcemy się odwołać, tak w przypadku jakichś getterów można by się nad nim zastanowić. I teraz pytanie. Jak to jest z dobrymi praktykami? Nie mam zbyt dużego doświadczenia w Javie, więc powołuję się na wasze zdanie. Czy lepiej używać i mieć zawsze świadomość co jest co, czy w niektórych przypadkach pomijać?

`this.Method()` vs `Method()`

Ten link zapewne Ci pomoże. Ja tam używam, chyba że w projekcie jest narzucone inaczej.

O ile nie programujesz lodówką to moim zdaniem nie ma sensu, poza sytuacjami kiedy jest to konieczne (np. wołanie innego konstruktora tej samej klasy). Normalne IDE i tak ładnie oznaczy ci pola klasy więc nie ma potrzeby jakiegoś ręcznego ich oznaczania. Jest to równie bezużyteczne jak jakieś głupie nazwy w stylu mField, pParam itd. To byłp dobre 30 lat temu jak klepało się kod w debug.exe.

Co do zasady nie jest potrzebne i nie używam jeżeli nie muszę. Mam dwa powody:

• redukcja liczby kliknięć. Mniej pisania to mniej kodu, mniej kodu to mniej błędów.
• używając IDE mam podświetloną składnię i w momencie gdy intensywnie używam this, to tekst wynikowy świeci się jak choinka, bo kolor i waga jest inna niż w reszcie kodu, co utrudnia czytanie.

Oprócz konstruktorów używam też w setterach, dzięki temu parametr nie ma dziwnych prefiksów i nazywa się tak że od razu widać do czego ma być:

void setColor(int color) {
   this.color = color;
}

Używam głównie tak: https://en.wikipedia.org/wiki/Fluent_interface

Jak nie muszę to też używam, bo tam mam w projekcie i chcę, żeby było spójnie.

Jo zwyklę piszę tak. Czy to nie przeszłoby forumowego review?

public class Person {
    private final String name;
    private final int age;

    public Person(final String theName, final int theAge) {
        name = theName;
        age = theAge;
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }

}

@InterruptedException: zadziała i bedzie ok, dlaczego nie, tylko taki kod, dla mnie generuje IDE i to w formie z this bo po co kombinowac

InterruptedException napisał(a):

Jo zwyklę piszę tak. Czy to nie przeszłoby forumowego review?

public class Person {
    private final String name;
    private final int age;

    public Person(final String theName, final int theAge) {
        name = theName;
        age = theAge;
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }

}

Po co określać argumenty konstruktora jako finalne? Pierwszy raz coś takiego widzę, dlatego pytam, no offence.

Wiesz, są przypadki, że to jest niezbędne. Nie mniej jednak wynika to z tzw dobrych praktyk.
Osobiście tego nigdy nie robiłem, ale poczytałem trochę książek i blogów [0] ludzi obeznanych w Javie i się zainspirowałem.

[0] https://blogs.oracle.com/tor/entry/code_advice_12_use_final

uzycie final w konstruktorze zabezpieczy cie przed czyms takim:

 public Person(final String name, final int age) {
        name = name ;
        age = age;
    }

i wymusi to na tobie dopisanie this albo zmiana nazwy parametrow konsstruktora na nazwy inne niż pola, wiec korzysc jak najbardziej jest

Użycie final na parametrze ma praktyczne zastosowanie. Nie nadpiszesz takiej zmiennej. Jednak nie jest to jedyne zastosowanie. Załóżmy, że jednym z argumentów jest obiekt, który posłuży nam do stworzenia klasy anonimowej:

class MyClass{
	
	private Runnable task;
	
	public MyClass(String label) {
		
		this.task = new Runnable() {
			@Override
			public void run() {
				System.out.println(label);		
			}
		};
	}
}

Przed Javą 8 ten kod się nie skompiluje ponieważ label nie jest stały (oznaczony final). Od javy 8 mamy pojęcie zmiennych efektywnie finalnych i kompilator sprawdzi czy w tym przypadku wszystko jest OK.