리플렉션 사용에 문제가 있습니까?

이유를 모르지만 리플렉션을 사용할 때 항상 "속임수"인 것처럼 느껴집니다. 아마도 내가 겪고있는 성능 히트 때문일 수 있습니다.

저의 일부는 그것이 당신이 사용하는 언어의 일부이고 당신이하려는 일을 성취 할 수 있다면 왜 그것을 사용하지 않는지 말합니다. 저의 다른 부분은 반사를 사용하지 않고 이것을 할 수있는 방법이 있어야한다고 말합니다. 상황에 따라 다를 수 있습니다.

리플렉션을 사용할 때주의해야 할 잠재적 인 문제는 무엇이며 어떻게해야합니까? 보다 일반적인 솔루션을 찾는 데 얼마나 많은 노력을 기울일 가치가 있습니까?

아니요, 부정 행위가 아닙니다. 일부 프로그래밍 언어에서 문제를 해결하는 방법입니다.

이제는 종종 최상의 (가장 깨끗하고 단순하며 유지 관리가 쉬운) 솔루션이 아닙니다. 더 좋은 방법이 있다면 실제로 사용하십시오. 그러나 때로는 그렇지 않습니다. 또는 존재하는 경우 코드 복제 등을 포함하여 훨씬 더 복잡하여 실행하기가 어렵습니다 (장기적으로 유지하기 어려움).

현재 프로젝트 (Java)의 두 가지 예 :

• 테스트 도구 중 일부는 리플렉션을 사용하여 XML 파일에서 구성을로드합니다. 초기화 될 클래스에는 특정 필드가 있으며 구성 로더는 리플렉션을 사용 fieldX하여 클래스의 해당 필드에 명명 된 XML 요소를 일치 시키고 후자를 초기화합니다. 경우에 따라 식별 된 속성 중에서 간단한 GUI 대화 상자를 즉시 ​​구축 할 수 있습니다. 반영하지 않으면 여러 응용 프로그램에서 수백 줄의 코드가 필요합니다. 따라서 리플렉션을 통해 많은 도구를 사용하지 않고도 간단한 도구를 신속하게 구성 할 수 있었고 관련성이없는 중요한 부분 (웹 앱 회귀 테스트, 서버 로그 분석 등)에 집중할 수있었습니다.
• 레거시 웹 앱의 한 모듈은 DB 테이블에서 Excel 시트로 데이터를 내보내거나 가져 오는 것이 었습니다. 그것은 중복 코드가 많이 포함되어 있었지만 물론 중복은 정확히 동일하지 않았고 일부는 버그 등을 포함했습니다. 리플렉션, 내부 검사 및 주석을 사용하여 중복을 거의 없애고 코드 양을 줄였습니다. 5K에서 2.4K 미만으로 유지하면서 코드를 더욱 강력하고 유지 관리 및 확장하기가 더 쉽습니다. 이 모듈은 신중하게 반사를 사용함으로써 우리에게 문제가되지 않았습니다.

결론은 다른 강력한 도구와 마찬가지로 반사도 발로 자신을 쏠 수 있습니다. 언제 어떻게 사용하는지 배우지 않으면 어려운 문제에 대해 우아하고 깨끗한 해결책을 얻을 수 있습니다. 당신이 그것을 남용한다면, 당신은 간단한 문제를 복잡하고 추악한 혼란으로 바꿀 수 있습니다.

부정 행위가 아닙니다. 그러나 최소한 다음과 같은 이유로 프로덕션 코드에서 나쁜 생각입니다.

• 컴파일 타임 타입의 안전을 잃 습니다. 컴파일러가 컴파일 타임에 메소드가 사용 가능한지 확인하도록하는 것이 도움이됩니다. 리플렉션을 사용하는 경우 충분히 테스트하지 않으면 런타임에 오류가 발생하여 최종 사용자에게 영향을 줄 수 있습니다. 오류가 발생하더라도 디버깅하기가 더 어려워집니다.
• 리팩토링시 버그가 발생 합니다. 이름에 따라 멤버에 액세스하는 경우 (예 : 하드 코딩 된 문자열 사용) 대부분의 코드 리팩토링 도구에 의해 변경되지 않으며 즉시 버그가 있습니다. 추적하기 어렵다.
• 성능이 느립니다 -런타임시 반영이 정적으로 컴파일 된 메소드 호출 / 변수 조회보다 느립니다. 리플렉션을 가끔 수행하는 경우에는 문제가되지 않지만 초당 수천 또는 수백만 번 리플렉션을 통해 전화를 거는 경우 성능 병목 현상이 발생할 수 있습니다. 한 번 모든 반사를 제거하여 Clojure 코드에서 10 배 속도를 향상 시켰습니다. 그래서 이것은 실제 문제입니다.

리플렉션 사용을 다음과 같은 경우로 제한하는 것이 좋습니다.

• 대한 빠른 프로토 타이핑 하거나 가장 간단한 해결책은 "일회용"코드
• 에 대한 진정한 반성 사용 사례 사용자가 필드 / 런타임에 임의의 객체의 방법을 검토 할 수 있습니다, 예를 들어, IDE 공구.

다른 모든 경우에는 반사를 피하는 접근 방식을 알아내는 것이 좋습니다. 적절한 메소드 로 인터페이스 를 정의하고 메소드를 호출하려는 클래스 세트 에서 인터페이스 를 구현하면 대부분의 간단한 경우를 해결하기에 충분합니다.

리플렉션은 요즘 대부분의 언어에서 볼 수있는 유형 기반 매개 변수와 마찬가지로 메타 프로그래밍의 또 다른 형식 일뿐입니다. 리플렉션은 강력하고 일반적이며 리플렉션 프로그램은 순전히 객체 지향적이거나 절차 적 프로그램보다 유지 관리 성이 뛰어납니다 (물론 올바르게 사용하는 경우). 예, 성능 가격을 지불하지만 많은 경우 또는 대부분의 경우 더 관리하기 쉬운 느린 프로그램을 선택하게되어 기쁩니다.

분명히 그것은 모두 달성하려는 것에 달려 있습니다.

예를 들어 종속성 검사를 사용하여 확인할 미디어 종류 (MP3 파일 또는 JPEG 파일)를 결정하는 미디어 검사기 응용 프로그램을 작성했습니다. 쉘은 각 유형에 대한 관련 정보를 포함하는 그리드를 표시하는 데 필요한,하지만에 대한 지식이 없었다 무엇을 그것을 표시 할 거라고합니다. 이것은 해당 유형의 미디어를 읽는 어셈블리에 정의되어 있습니다.

따라서 리플렉션을 사용하여 표시 할 열 수와 유형 및 이름을 가져와 그리드를 올바르게 설정할 수있었습니다. 또한 다른 코드 또는 구성 파일을 변경하지 않고 주입 된 라이브러리를 업데이트하거나 새 라이브러리를 만들 수 있음을 의미했습니다.

다른 방법은 검사 할 미디어 유형을 전환 할 때 업데이트해야하는 구성 파일을 갖는 것입니다. 이것은 애플리케이션에 또 다른 실패 지점을 도입했을 것입니다.

라이브러리 작성자 인 경우 리플렉션은 멋진 도구 이므로 들어오는 데이터에 영향을 미치지 않습니다. 리플렉션과 메타 프로그래밍의 조합으로 라이브러리가 코드 생성 등을 거치지 않고 임의의 호출자와 원활하게 작동 할 수 있습니다.

그래도 응용 프로그램 코드에 반영되지 않도록 노력합니다 . 앱 계층에서 인터페이스, 추상화, 캡슐화 등 다른 은유를 사용해야합니다.

리플렉션은 개발자를위한 도구를 만드는 데 환상적입니다.

빌드 환경에서 코드를 검사하고 코드를 조작 / 초기 검사하는 올바른 도구를 생성 할 수 있습니다.

일반적인 프로그래밍 기술로는 유용 할 수 있지만 대부분의 사람들이 생각하는 것보다 취성입니다.

리플렉션 (IMO)의 한 가지 실제 개발 용도는 일반 스트리밍 라이브러리 작성이 매우 간단하다는 것입니다 (클래스 설명이 변경되지 않는 한 (매우 취약한 솔루션이 됨)).

잘 사용하지 않으면 OO 언어에서 리플렉션을 사용하는 것이 종종 해 롭습니다.

StackExchange 사이트에서 본 몇 가지 나쁜 질문이 있는지 확인하지 못했습니다.

1. 사용중인 언어는 OO입니다
2. 작성자는 어떤 유형의 객체가 전달되었는지 확인한 다음 해당 메소드 중 하나를 호출하려고합니다.
3. 저자는 리플렉션이 잘못된 기술이라는 것을 인정하지 않고 이것을 "나를 도와 줄 방법을 모른다"고 지적하는 사람을 비난합니다.

다음 은 전형적인 예입니다.

OO의 요점은

1. 사물 자체로 구조 / 개념을 조작하는 방법을 알고있는 함수를 그룹화합니다.
2. 코드의 어느 지점에서나 객체 유형에 대해 충분히 알고 있어야 관련 기능이 무엇인지 알고 해당 기능의 특정 버전을 호출하도록 요청해야합니다.
3. 모든 기능에 대해 올바른 입력 유형을 지정하고 각 기능이 관련성 이상을 더 이상 알지 못하도록하여 이전 요점의 진실성을 보장합니다.

코드의 어느 지점에서든 2 번 지점이 전달 된 객체에 유효하지 않은 경우 이들 중 하나 이상이 true입니다.

1. 입력이 잘못되었습니다
2. 코드의 구조가 잘못되었습니다
3. 당신은 대체 무슨 짓을했는지 몰라요

불쌍한 개발자는 단순히 이것을 얻지 못하고 코드의 어느 부분 으로든 전달할 수 있으며 (하드 코딩 된) 가능성 세트에서 원하는 것을 수행 할 수 있다고 생각합니다. 이 바보들은 반사 를 많이 사용 합니다.

OO 언어의 경우 리플렉션은 메타 활동 (클래스 로더, 종속성 주입 등)에만 필요합니다. 이러한 맥락에서, 합법적 인 이유에 대해 전혀 모르는 코드의 조작 / 구성을 지원하는 일반적인 서비스를 제공하기 때문에 반영이 필요합니다. 거의 모든 다른 상황에서, 당신이 반성에 도달한다면, 당신은 무언가 잘못하고 있으며, 이 코드 조각이 전달 된 객체에 대해 왜 충분히 알지 못하는지 스스로에게 물어볼 필요 가 있습니다.

리플렉션 된 클래스의 도메인이 잘 정의 된 경우 대안 은 런타임시 리플렉션을 사용하는 대신 다른 메타 데이터와 함께 리플렉션을 사용 하여 코드를 생성하는 것입니다. FreeMarker / FMPP를 사용하여이 작업을 수행합니다. 선택할 수있는 다른 도구가 많이 있습니다. 이것의 장점은 쉽게 디버깅 할 수있는 "실제"코드로 끝나는 것입니다.

상황에 따라 훨씬 더 빠른 코드를 만들거나 많은 코드를 만들 수 있습니다. 반사의 단점을 피합니다.

• 컴파일 타임 타입 안전 손실
• 리팩토링으로 인한 버그
• 성능 저하

앞서 언급했다.

반사가 부정 행위처럼 느껴지면 확실하지 않은 많은 추측에 근거하고 있기 때문에 장은 이것이 위험하다는 경고입니다. 자신의 메타 데이터를 반영하여 고유 한 메타 데이터를 향상시킬 수있는 방법을 제공해야합니다. 여기에서 발생할 수있는 실제 클래스의 모든 문제와 특수 사례를 설명 할 수 있습니다.

부정 행위는 아니지만 다른 도구와 마찬가지로 해결하려는 용도로 사용해야합니다. 리플렉션은 정의에 따라 코드를 통해 코드를 검사하고 수정할 수 있습니다. 그것이 당신이해야 할 일이라면, 반사는 작업을위한 도구입니다. 리플렉션은 메타 코드에 관한 것입니다. 코드를 대상으로하는 코드 (데이터를 대상으로하는 일반 코드와 반대).

리플렉션 사용의 좋은 예는 일반적인 웹 서비스 인터페이스 클래스입니다. 일반적인 설계는 프로토콜 구현을 페이로드 기능과 분리하는 것입니다. 따라서 T페이로드를 구현 하는 클래스 하나 (콜렛이라고 함 )와 프로토콜 ( P) 을 구현하는 클래스가 있습니다 . T매우 간단합니다. 원하는 모든 호출에 대해 수행해야 할 모든 작업을 수행하는 하나의 메소드 만 작성하십시오. P그러나 웹 서비스 호출을 메소드 호출에 맵핑해야합니다. 중복성을 피하고 P재사용 성 이 높기 때문에이 매핑을 일반화하는 것이 바람직 합니다. Reflection은 T런타임에 클래스를 검사하고 클래스 에 P대한 컴파일 타임 지식없이 웹 서비스 프로토콜 을 통해 전달 된 문자열을 기반으로 메소드를 호출 하는 수단을 제공합니다.T. '코드에 대한 코드'규칙을 사용하면 P클래스에 T데이터의 일부로 클래스에 코드가 있다고 주장 할 수 있습니다 .

하나.

리플렉션은 언어 유형 시스템의 제한을 극복 할 수있는 도구도 제공합니다. 이론적으로 모든 매개 변수를 type으로 전달하고 object리플렉션을 통해 해당 메소드를 호출 할 수 있습니다. 강력한 정적 타이핑 규칙을 적용해야하는 언어 인 Voilà은 이제 바인딩이 늦은 동적 형식 언어처럼 동작하지만 구문이 훨씬 정교합니다. 지금까지 본 이러한 패턴의 모든 단일 인스턴스는 더러운 해킹이었으며 언어 유형 시스템 내의 솔루션이 가능했으며 모든 측면에서 더 안전하고 우아하며 효율적이었습니다. .

다양한 비 관련 유형의 데이터 소스에 데이터 바인딩 될 수있는 GUI 컨트롤과 같은 몇 가지 예외가 있습니다. 데이터를 바인딩 할 수 있도록 데이터가 특정 인터페이스를 구현하도록 요구하는 것은 현실적이지 않으며 프로그래머가 각 유형의 데이터 소스에 대한 어댑터를 구현하지 않아도됩니다. 이 경우 리플렉션을 사용하여 데이터 소스 유형을 감지하고 데이터 바인딩을 조정하는 것이 더 유용한 선택입니다.

리플렉션에서 우리가 겪었던 한 가지 문제는 믹스 에 난독 화 를 추가했을 때 입니다. 모든 클래스는 새로운 이름을 얻었고 갑자기 클래스 또는 함수 이름으로로드하면 작동이 중지됩니다.

그것은 전적으로 달려 있습니다. 리플렉션없이하기 ​​어려운 작업의 예로는 ObjectListView 를 복제하는 것이 있습니다 . 또한 IL 코드를 즉시 생성합니다.

리플렉션은 컨벤션 기반 시스템을 생성하는 기본 방법입니다. 대부분의 MVC 프레임 워크에서 많이 사용되고 있다는 사실에 놀라지 않을 것입니다. ORM의 주요 구성 요소입니다. 이미 매일 구성 요소를 사용하여 구성 요소를 사용하고있을 가능성이 있습니다.

이러한 용도의 대안은 자체 단점이있는 구성입니다.

리플렉션은 실제로는 달리 할 수없는 일을 달성 할 수 있습니다.

예를 들어이 코드를 최적화하는 방법을 고려하십시오.

int PoorHash(char Operator, int seed, IEnumerable<int> values) {
    foreach (var v in values) {
        seed += 1;
        switch (char) {
            case '+': seed += v; break;
            case '^': seed ^= v; break;
            case '-': seed -= v; break;
            ...
        }
        seed *= 3;
    }
    return seed;
}

내부 루프 중간에 값 비싼 테스트가 있지만 추출하려면 각 연산자에 대해 루프를 한 번 다시 작성해야합니다. 리플렉션을 사용하면 루프를 수십 번 반복하지 않고도 해당 테스트를 추출하여 성능을 유지할 수 있습니다 (따라서 유지 관리 성을 희생). 필요한 루프를 즉시 생성하고 컴파일하십시오.

나는 한 사실이 최적화를 수행 은 조금 더 상황을 복잡하지만, 그 결과는 놀라운 있었다. 성능이 크게 향상되고 코드 줄이 줄어 듭니다.

(참고 : 처음에는 char 대신 Func에 전달하는 것과 동등한 방법을 시도했지만 약간 더 좋았지 만 거의 10 배 반사되지는 않았습니다.)

속임수가 아닙니다 ... 오히려, 애플리케이션 서버가 사용자가 선택한 이름으로 사용자가 만든 클래스를 실행할 수 있도록하여 부정 행위가 아닌 유연성을 제공합니다.

그리고 .class 파일의 코드를 보려면 (Java로) 무료로 사용할 수있는 디 컴파일러가 여러 개 있습니다!