Dlaczego import klasy nie są potrzebne podczas wywoływania metody na przykład (Java)

Question

coś, co jest mylone mnie - przykład:

Thing.java:

import java.util.Date; 

class Thing { 
    static Date getDate() {return new Date();} 
} 

(sam pakiet) TestUsesThing.java:

// not importing Date here. 

public class TestUsesThing { 

    public static void main(String[] args) { 
     System.out.println(Thing.getDate().getTime()); // okay 
     // Date date = new Date(); // naturally this wouldn't be okay 
    } 

} 

Dlaczego importowanie Date nie jest konieczne, aby wywołać metodę getTime() na jednym z nich?

Answer 1

Importowanie w Javie jest konieczne tylko tak kompilator wie, co Date jest po wpisaniu

Date date = new Date(); 

Import nie jest jak #include w C/C++; wszystkie typy w ścieżce klas są dostępne pod , ale użytkownik ma je tylko po to, aby nie musieć pisać pełnej nazwy. I w tym przypadku jest to niepotrzebne.

Answer 2

Dobre pytanie !!

Myślę, że wynikiem jest różnica między tym, jak kompilator java obsługuje wyrażenia a instrukcje.

Date d = new Date(); // a statement 

gdzie jako

new Thing().getDate().getTime() 

jest wyrazem jak to ma miejsce w środku println połączenia metody. Kiedy wywołujemy getDate na nowej Thing(), kompilator próbuje obsłużyć wyrażenie, patrząc na informacje o typie dla klasy Thing, gdzie otrzymuje deklarację typu Date. Ale kiedy spróbujesz użyć Data oddzielnie w oświadczeniu jak

Date d = new Thing().getDate(); 

jesteś przypisując wynik typu w bieżącym zakresie (klasa TestUsesThing), kompilator stara się rozwiązać ten typ w tym zakresie. W wyniku tego pojawia się błąd kompilatora dla nieznanego typu.

Answer 3

Czy rzeczy i testy używają tego samego pakietu? Jeśli tak, to nie musisz importować Thinga. Powodem, dla którego musisz zaimportować datę, jest to, że znajduje się w innym pakiecie.

Answer 4

import Wyrażenia są używane do kilku rzeczy.

1. Sprawdzanie typu kompilatora i unikanie kolizji nazw.
2. Zapewnia kod bajtowy podnośnik

Ilekroć mówimy

System.out.println(new Thing().getDate().getTime()) 

Kompilator analizuje to stwierdzenie lewej do prawej i dostaje się do tej klasy.

Parsowanie kompilatora pierwszego poziomu.

1. iść do klasy rzeczy

2. kompilacji nie ma żadnego powiązania lub błąd ClassVersion od Thing.klasa

3. Sprawdź, czy klasa Thing.class ma metodę getDate.
4. jeśli nr 3 jest dobry, to wskaźnik kompilatora nadal znajduje się w Thing.class (który ma instrukcje importu daty) i mógłbym wywołać metodę Time.

5. Jako konsumenta TestUsesThing otrzymuje tylko długą zmienną.

   System.out.println(new Thing().getDate()) 
   

   5,1 W tym przypadku jesteśmy pośrednio uzyskującego dostęp .ToString (metoda

Answer 5

Właściwie), który był idealnym przykładem, ponieważ nie dwa zróżnicowanym standardzie Java Data klas: java.util .Data i java. sql .Data.

Skąd wiadomo, którego użyć? Prosty. Metoda getDate() jest deklarowany jako część definicji klasy rzeczy, a część tej deklaracji jest jej returntype:

public java.util.Date getDate() { 
    return this.date; 
} 

Oczywiście, jeśli masz import w definicji klasy sprawa - i to nie jest niejednoznaczne, wystarczy powiedzieć:

public Date getDate() { 

Jeśli było zdekodować binarny klasy rzecz, którą można zobaczyć podpis metody metody getDate i zawiera w pełni kwalifikowaną nazwę klasy (w tym pakiet) typu zwrotu.

An import jest po prostu sposobem poinformowania kompilatora, jakie pakiety chcesz założyć, odnosząc się do klas bez wyraźnych kwalifikacji. Lista importów zostanie zeskanowana za każdym razem, gdy zostanie wyświetlona niekwalifikowana nazwa klasy, a pakiety zostaną przeszukane. Jeśli nie ma dwuznaczności (np. Importowanie zarówno java.util.date, jak i java.sql.Date), ta klasa będzie używana. Jeśli możesz określić klasę niejawnie lub jeśli nazwa klasy jest w pełni kwalifikowana, nie musisz importować.