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 
- Rejestracja:ponad 11 lat
- Ostatnio:ponad 4 lata
- Postów:2442
2
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:około 21 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Space: the final frontier
- Postów:26433
0
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.
1
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:ponad 8 lat
- Ostatnio:29 dni
- Postów:160
0
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:prawie 10 lat
- Ostatnio:prawie 4 lata
- Postów:317
0
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;
}
}
0
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:prawie 10 lat
- Ostatnio:prawie 4 lata
- Postów:317
0
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:około 18 lat
- Ostatnio:około 7 lat
0
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
edytowany 2x, ostatnio: flowCRANE
4
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.
theNames? Słabe.