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ć?
Java - this - używać czy nie?
- Rejestracja: dni
- Ostatnio: dni
- Postów: 2442
https://4programmers.net/Forum/Flame/276258-thismethod_vs_method
Ten link zapewne Ci pomoże. Ja tam używam, chyba że w projekcie jest narzucone inaczej.
- Rejestracja: dni
- Ostatnio: dni
- Lokalizacja: Space: the final frontier
- Postów: 26433
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.
- Rejestracja: dni
- Ostatnio: dni
- Lokalizacja: Stacktrace
- Postów: 6822
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.
- Rejestracja: dni
- Ostatnio: dni
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;
}
- Rejestracja: dni
- Ostatnio: dni
- Postów: 160
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.
- Rejestracja: dni
- Ostatnio: dni
- Postów: 317
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;
}
}
- Rejestracja: dni
- Ostatnio: dni
@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
- Rejestracja: dni
- Ostatnio: dni
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.
- Rejestracja: dni
- Ostatnio: dni
- Postów: 317
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
- Rejestracja: dni
- Ostatnio: dni
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
- Rejestracja: dni
- Ostatnio: dni
- Lokalizacja: Stacktrace
- Postów: 6822
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.