클래스에 가져온 클래스와 같은 이름의 메서드가있는 경우 가져 오기 static이 작동하지 않습니다.

Question

org.junit.Assert.assertEquals 메서드를 정적으로 가져 오는 Junit4 테스트 사례가 있습니다. 내가 등호를 구현하지 않는 일부 복잡한 내부 클래스를 주장하기위한 유틸리티 메소드를 만든이 클래스에서

import static org.junit.Assert.assertEquals; 

(그리고 또한 힘든 시간을 구현있다).

private void assertEquals(MyObj o1, MyObj o2) 
{ 
    assertEquals(o1.getSomething(), o2.getSomething()); 
    assertEquals(o1.getSomethingElse(), o2.getSomethingElse()); 
    ... 
} 

나는 내가 가져있어 assertEquals 방법 (들) "과부하"하고있는 것처럼 코드가 작동 할 것으로 예상하지만, 이 정적으로 수입 된 방법을 숨기고 내 개인 비 정적 방법처럼 보인다 . 나는 또한 내 방법을 public 및 static (모든 순열)이 되려고했지만 성공하지 못했습니다. 이름을 변경해야했습니다.

이 방식으로 작동하는 이유는 무엇입니까? 설명서에서이 동작에 대한 참조를 찾을 수 없습니다.

Answer 1

관찰 한 내용은 Shadowing입니다. java에서 두 개의 유형이 동일한 간단한 이름을 가질 때, 그 중 하나는 다른 하나를 어둡게합니다. 그림자가있는 유형은 단순한 이름으로 사용할 수 없습니다.

가장 일반적인 섀도 잉 유형은 필드를 숨기는 매개 변수입니다. 일반적으로 setMyInt(int myInt) {this.myInt = myInt; }

처럼 보이도록 세터 코드가 발생할 이제이 relevant documentation을 읽어 보자

는

정적 가져 오기 주문형 선언은 결코 그림자가되는 다른 선언을 발생하지 않습니다.

이는 주문형 정적 가져 오기가 항상 마지막임을 나타냅니다. 따라서 주문형 가져 오기 선언과 동일한 간단한 이름을 가진 모든 유형은 항상 정적 가져 오기를 섀도 잉 (숨김)합니다.

Answer 2

오버로드 및 덮어 쓰기는 상속 트리에서 작동합니다. 그러나 정적 가져 오기는 상속을 구축하지 않습니다.

자신의 assertEquals 메소드에서 junit의 assertEquals를 사용하려면 className으로 정규화해야합니다. 예 : Assert.assertEquals.

org.junit.Assert의 정적이 아닌 가져 오기를 사용하십시오.

Answer 3

method hiding으로 넘어갔습니다. 로컬 메서드가 있으면 다른 클래스 (대개 수퍼 클래스)에서 "숨 깁니다".

정적으로 가져 오는 방법은 구문 상 가능하지만 여하튼 "잘못"하다고 항상 느꼈습니다.

스타일로 클래스를 가져오고 내 코드에 TheirClass.method()을 사용하는 것을 선호합니다. 이렇게하면 메서드가 로컬 메서드가 아니며 좋은 코드의 특징 중 하나가 선명도임을 분명하게 알 수 있습니다.

나는 import org.junit.Assert을 추천하며 Assert.assertEquals(...)을 사용합니다.

Answer 4

이것은 의미가 있습니다. javac가 원하는 것을 수행한다고 가정하면, 오늘은 assertEquals(MyObj, MyObj) 메소드를 선택합니다. 내일 org.junit.Assert에 assertEquals(MyObj, MyObj) 메서드가 추가되면 어떻게 될까요?부름 assertEquals(mo1,mo2)의 의미는 당신이 모르게 극적으로 변했습니다.

문제의 이름은 assertEquals입니다. Javac은 이것이 방법의 이름 (org.junit.Assert)임을 결정해야합니다. 그 후에 만 ​​메소드 오버로딩을 수행 할 수 있습니다. 의 메소드를 모두 assertEquals으로 검사하고 가장 적합한 메소드를 선택하십시오.

자바는 여러 클래스의 메소드 오버로드를 처리 할 수 ​​있지만 첫 번째 단락에서 볼 수 있듯이 개발자가 호출하는 메소드의 클래스에 큰 불확실성이 있습니다. 이러한 클래스는 서로 관련이 없으므로 메서드 의미가 크게 다를 수 있습니다.

컴파일 타임에 메서드가 속한 클래스를 개발하는 데 의심의 여지가없는 경우에도 클래스가 내일 메서드를 오버로드하여 호출 된 대상 메서드를 변경하는 것이 여전히 가능할 수 있습니다. 그러나 동일한 클래스에서 수행되므로 책임을 맡을 수 있습니다. 예를 들어 org.junit.Assert이 새로운 assertEquals(MyObj, MyObj) 메서드를 추가하기로 결정한 경우 이전 호출 인 assertEquals(Object,Object)이 새 메서드로 리 라우팅되고 호출 사이트를 손상시킬 의미 변경이 없는지 확인해야합니다.