@Override itp

[Riveilli]

Witam,
czy mógłby mi ktoś wytłumaczyć czym są magiczne @Override, @SuppressWarnings itp, które Eclipse co jakiś czas sam mi dodaje i do czego konkretnie one służą?

[GotoFinal]

Witam,

czy mógłby mi ktoś wytłumaczyć czym są magiczne @Override, @SuppressWarnings itp, które Eclipse co jakiś czas sam mi dodaje i do czego konkretnie one służą?

ogólnie to wszystko z @ to adnotacje:

https://docs.oracle.com/javase/tutorial/java/annotations/

 

@Override

służy do poinformowania kompilatora (i IDE zwzyczaj) że dana metoda jest nadpisana, np:

public interface Runnable
{
    void run();
}

public class Test
{
    @Override
    public void run(){}
}

bez Override oczywiście też zadziała, ale:

• Od razu widzisz że dana metoda nie jest z tej klasy - wiesz że nie możesz usunąć czy ot-tak zmienić nazwy.
• IDE/kompilator wyrzuci ci błąd, jeśli Override będzie nad metodą która nie jest nadpisaniem innej, czyli od razu zauważysz po zmianie wersji libki że coś się zmieniło.

Czyli ogólnie cel jest prosty: unikanie bugów.

 

 

@SuppressWarnings to inna sprawa, i nie powineneś go dawać tylko dlatego że eclipse proponuje, w pierwszej kolejności powinieneś postarać napisać się kod tak, by nie wyrzucał on żadnych ostrzeżeń.

Ale nie zawsze się da, np w przypadku ostrych zabaw z refleksjami czy często wczytywaniem konfiguracji, gdzie też dużo castujemy itd.

 

I ową adnotacje razem z warningiem który chcemy ignorować, dajemy tam gdzie sami zadbaliśmy o bezpieczeństwo.

np kompialtor drze się że "unchecked cast" bo castujesz nagle obiekt z listy <?> do jakiegoś swojego obiektu:

List<?> list = jakasMetdaCzyCos();
MyObject obj = (MyObject) list.get(0);

i dajemy tutaj SuppressWarnings kiedy jesteśmy pewni że tam na 100% jest ten obiekt, bo np w tej tajemniczej metodzie istnieje kod który to sprawdza.

[Riveilli]

ogólnie to wszystko z @ to adnotacje:

https://docs.oracle.com/javase/tutorial/java/annotations/

 

@Override

służy do poinformowania kompilatora (i IDE zwzyczaj) że dana metoda jest nadpisana, np:

public interface Runnable
{
    void run();
}

public class Test
{
    @Override
    public void run(){}
}

bez Override oczywiście też zadziała, ale:

• Od razu widzisz że dana metoda nie jest z tej klasy - wiesz że nie możesz usunąć czy ot-tak zmienić nazwy.
• IDE/kompilator wyrzuci ci błąd, jeśli Override będzie nad metodą która nie jest nadpisaniem innej, czyli od razu zauważysz po zmianie wersji libki że coś się zmieniło.

Czyli ogólnie cel jest prosty: unikanie bugów.

 

 

@SuppressWarnings to inna sprawa, i nie powineneś go dawać tylko dlatego że eclipse proponuje, w pierwszej kolejności powinieneś postarać napisać się kod tak, by nie wyrzucał on żadnych ostrzeżeń.

Ale nie zawsze się da, np w przypadku ostrych zabaw z refleksjami czy często wczytywaniem konfiguracji, gdzie też dużo castujemy itd.

 

I ową adnotacje razem z warningiem który chcemy ignorować, dajemy tam gdzie sami zadbaliśmy o bezpieczeństwo.

np kompialtor drze się że "unchecked cast" bo castujesz nagle obiekt z listy <?> do jakiegoś swojego obiektu:

List<?> list = jakasMetdaCzyCos();
MyObject obj = (MyObject) list.get(0);

i dajemy tutaj SuppressWarnings kiedy jesteśmy pewni że tam na 100% jest ten obiekt, bo np w tej tajemniczej metodzie istnieje kod który to sprawdza.

rozumiem, dzięki

do zamknięcia