반사 : 반사 사용이 여전히 "나쁜"또는 "느린"입니까? 2002 년 이후로 반성에 무엇이 바뀌 었습니까?

Expressions 또는 Expression Trees를 다룰 때 리플렉션을 많이 사용하여 속성 값을 설정하고 가져 오는 것을 알았습니다. 리플렉션 사용이 점점 더 일반화되고있는 것 같습니다. 유효성 검사를위한 DataAnotations, Attribute Heavy ORM 등 .

그렇다면 무엇이 바뀌 었습니까? 기계의 속도일까요? 반영 속도를 높이기 위해 프레임 워크가 변경 되었습니까?

아니면 아무것도 바뀌지 않았습니까? 여전히 반사를 사용하는 것이 "나쁜"또는 "느린"입니까?

반성이 나쁘지도 느리지도 않습니다. 단순히 도구입니다. 모든 도구와 마찬가지로 특정 시나리오에서는 매우 유용하지만 다른 시나리오에서는 그렇게 중요하지 않습니다.

성능이 실제로 문제인 경우 항상 FasterFlect 와 같은 라이브러리를 사용할 수 있습니다 .

추가 자료
반성이 비효율적이라면 언제 가장 적절합니까?

사람들이 불필요하게 반사를 사용하는 것에주의하는 이유는 성능이 아니기 때문입니다. 예, 반사를 사용하는 데 약간의 오버 헤드가 있지만 종종 비슷한 복잡성을 가진 다른 접근 방식을 사용하지 않고 문제를 해결해야하며, 그렇지 않은 경우에도 오버 헤드는 거의 중요하지 않습니다 (특히 응용 프로그램 수준 개발의 경우).

리플렉션을 사용하면 소스 코드에 대해 일반적으로 할 수있는 몇 가지 중요한 가정이 깨지고 "모든 참조 찾기"와 같은 도구가 안정적으로 작동하지 않습니다. 리플렉션 (Reflection)은 기본적으로 컴파일러가 시행하는 C #과 같은 대부분의 유형 안전과 유형 시스템이 일반적으로 컴파일러 오류로 잡아서 변환하는 프로그래밍 오류의 대부분을 제거하여 최악의 경우 런타임 오류가되거나 매우 불명확 한 버그가됩니다.

그렇다면 사람들은 왜 반사를 사용합니까? 간단히 말하면 위에서 설명한 문제에도 불구하고 매우 귀중한 도구이기 때문입니다. 리플렉션을 통해 동적 프로그래밍의 이점 중 일부는 C #과 같이 정적이고 엄격하게 유형이 지정된 언어로 제공 될 수 있으며 동적 프로그래밍 언어는 최근 특히 웹 프로그래밍 영역 (PHP, Javascript 및 상당히 두드러진 Python)에서 그 장점을 보여주었습니다. 모두 동적 타이핑을 사용하며 웹 프로그래밍에 적합한 것으로 입증되었습니다. 그러나 언어는 여전히 C #이므로 대부분의 응용 프로그램을 엄격하게 형식이 지정된 OOP 관용구로 유지하고 동적 동작이 실제로 리플렉션과 다른 부분을 작게 작성할 수 있습니다.

일반적인 예는 메서드를 웹 서비스 호출로 노출해야하는 경우입니다 (아직 .NET에 내장되지 않은 프로토콜 사용). 엄격하게 형식화 된 OOP 접근 방식은 작동하지만 지나치게 제한적이고 어색합니다. 그러나 리플렉션을 사용하여 메서드에 대한 호출과 키 / 값 쌍을 인수에 매핑하면 해당 웹 서비스에 대한 배관을 한 번 작성한 다음 원하는 클래스에서 사용할 수 있습니다.

리플렉션은 여전히 ​​직통 전화보다 훨씬 느립니다. 두 가지가 변경되었습니다.

• 런타임은 반사 메커니즘을 최적화하여 차이가 작아졌습니다.
• CPU가 더 빨라져서 작은 비 효율성이 더 쉽게 견딜 수 있습니다.

이 두 가지 요소가 함께 반영 비용이 일상적으로 (유지 보수성 POV에서 적절한 경우)이를 사용할 수있는 지점으로 낮추고 프로파일 러가 실제로 병목 현상인지 여부를 알려줄 때까지 기다립니다 ( 그렇지 않을 시간).