기본적으로 리플렉션은 프로그램 코드를 데이터로 사용하는 것을 의미합니다.
따라서 프로그램 코드가 유용한 데이터 소스 인 경우 리플렉션을 사용하는 것이 좋습니다. (그러나 절충점이 있기 때문에 항상 좋은 생각은 아닙니다.)
예를 들어 간단한 클래스를 생각해보십시오.
public class Foo {
public int value;
public string anotherValue;
}
XML을 생성하려고합니다. XML을 생성하는 코드를 작성할 수 있습니다.
public XmlNode generateXml(Foo foo) {
XmlElement root = new XmlElement("Foo");
XmlElement valueElement = new XmlElement("value");
valueElement.add(new XmlText(Integer.toString(foo.value)));
root.add(valueElement);
XmlElement anotherValueElement = new XmlElement("anotherValue");
anotherValueElement.add(new XmlText(foo.anotherValue));
root.add(anotherValueElement);
return root;
}
그러나 이것은 많은 상용구 코드이며 클래스를 변경할 때마다 코드를 업데이트해야합니다. 실제로이 코드의 기능을 설명 할 수 있습니다
- 클래스 이름으로 XML 요소를 만듭니다.
- 클래스의 각 속성에 대해
- 속성 이름으로 XML 요소를 만듭니다.
- 속성 값을 XML 요소에 넣습니다.
- 루트에 XML 요소를 추가하십시오
이것은 알고리즘이며 알고리즘의 입력은 클래스입니다. 이름과 속성의 이름, 유형 및 값이 필요합니다. 여기에서 리플렉션이 발생합니다.이 정보에 액세스 할 수 있습니다. Java를 사용하면 Class클래스 의 메소드를 사용하여 유형을 검사 할 수 있습니다 .
더 많은 사용 사례 :
- 클래스의 메소드 이름을 기반으로 웹 서버에서 URL을 정의하고 메소드 인수를 기반으로 URL 매개 변수를 정의하십시오.
- 클래스의 구조를 GraphQL 타입 정의로 변환
- 단위 테스트 케이스로 이름이 "test"로 시작하는 클래스의 모든 메소드를 호출하십시오.
그러나 완전한 반영은 기존 코드 ( "자체 검사"라고도 함)를 볼뿐만 아니라 코드를 수정하거나 생성하는 것을 의미합니다. 이를 위해 Java에는 두 가지 주요 사용 사례가 있습니다 : 프록시와 모의.
인터페이스가 있다고 가정 해 봅시다.
public interface Froobnicator {
void froobnicateFruits(List<Fruit> fruits);
void froobnicateFuel(Fuel fuel);
// lots of other things to froobnicate
}
흥미로운 것을 구현하는 구현이 있습니다.
public class PowerFroobnicator implements Froobnicator {
// awesome implementations
}
실제로 두 번째 구현도 있습니다.
public class EnergySaverFroobnicator implements Froobnicator {
// efficient implementations
}
이제 로그 출력도 원합니다. 메소드가 호출 될 때마다 단순히 로그 메시지가 필요합니다. 모든 메소드에 로그 출력을 명시 적으로 추가 할 수는 있지만 성가 시므로 두 번 수행해야합니다. 각 구현마다 한 번씩. (더 많은 구현을 추가 할 때 더 많은)
대신 프록시를 작성할 수 있습니다.
public class LoggingFroobnicator implements Froobnicator {
private Logger logger;
private Froobnicator inner;
// constructor that sets those two
public void froobnicateFruits(List<Fruit> fruits) {
logger.logDebug("froobnicateFruits called");
inner.froobnicateFruits(fruits);
}
public void froobnicateFuel(Fuel fuel) {
logger.logDebug("froobnicateFuel( called");
inner.froobnicateFuel(fuel);
}
// lots of other things to froobnicate
}
그러나 알고리즘에 의해 설명 될 수있는 반복적 인 패턴이 있습니다.
- 로거 프록시는 인터페이스를 구현하는 클래스입니다.
- 인터페이스와 로거의 다른 구현을 취하는 생성자가 있습니다.
- 인터페이스의 모든 메소드
- 구현시 "$ methodname called"메시지가 기록됩니다.
- 그런 다음 내부 인터페이스에서 동일한 메소드를 호출하여 모든 인수를 전달합니다.
이 알고리즘의 입력은 인터페이스 정의입니다.
리플렉션을 사용하면이 알고리즘을 사용하여 새 클래스를 정의 할 수 있습니다. Java를 사용하면 java.lang.reflect.Proxy클래스 의 메소드를 사용하여이를 수행 할 수 있으며 더 많은 기능을 제공하는 라이브러리가 있습니다.
반사의 단점은 무엇입니까?
- 코드를 이해하기가 더 어려워집니다. 귀하는 코드의 구체적인 효과에서 한 단계 더 추상화 된 것입니다.
- 코드를 디버깅하기가 더 어려워집니다. 특히 코드 생성 라이브러리의 경우 실행되는 코드는 작성한 코드가 아니라 생성 한 코드 일 수 있으며 디버거가 해당 코드를 표시하지 않거나 중단 점을 배치 할 수 있습니다.
- 코드가 느려집니다. 하드 코딩 액세스 대신 런타임 핸들로 유형 정보를 동적으로 읽고 필드에 액세스하면 속도가 느려집니다. 동적 코드 생성은 디버그하기가 더 어려워이 효과를 완화 할 수 있습니다.
- 코드가 깨지기 쉬워 질 수 있습니다. 동적 리플렉션 액세스는 컴파일러에서 유형을 확인하지 않지만 런타임시 오류를 발생시킵니다.