사용자가 요청을 보내면 필터에서 요청 주소를 분석하여 사용자의 요청에 맞는 함수를 실행해야 한다.
전통적인 방법으로는 사용자가 요청하는 경로에 대해 조건문을 적용하여 분기하는것이다. 예로, /user 경로로 들어온 요청에 대해선 if문을 통해 컨트롤러 내 정의된 user 함수를 실행시키고, /login 경로로 들어온 요청에 대해선 컨트롤러 내의 login 함수를 실행시키면 된다.
하지만 만약 컨트롤러 내 함수가 점점 많아진다면 어떻게 될까?
깊어지는 경로(/user/info/profile/img/...)와 다분화되는 경로에 대해 모든 조건문을 만들고 관리한다는 것은 상당히 힘들것이다.
제일 큰 문제점은 필터와 컨트롤러간의 결합도가 높아진다는것이다. 컨트롤러의 함수명을 바꾸는 동시에, 미리 함수명을 지정해 분기하는 필터는 무용지물이 된다.
리플렉션이란 자바의 API를 말한다. 타입을 알지 못하고 메모리 위치만 알고있는 객체의 생성자, 메소드, 타입, 필드 등의 정보를 제공(get)하고 호출(invoke)까지 할 수 있게 돕는 API이다.
이 API를 통해 해당 클래스의 이름, 클래스 멤버의 이름과 값, 메소드의 이름과 값, 전달받는 파라미터 등을 스캔하여 필요한 정보들을 메모리상에 위치시킬 수 있다. 앞서말한 문제를 예로 들면,
서버는 요청을 받으면 컨트롤러에 위치한 모든 함수를 찾아 정보들을 메모리에 위치시킨다. 이 때, 함수에 딸린 어노테이션 정보도 포함된다. 이제부터 요청이 들어올 때마다 디스패쳐는 리플렉션된 정보들과 요청의 경로를 통해 실행해야할 함수를 찾아낸다. 심지어 불러들인 함수의 파라미터의 정보까지 알 수 있으니, 요청이 유효한 데이터를 지니고 있는지 확인할 수 있고, 유효하지 않다면 요청을 거부할 수도 있다.
스프링을 예로 들면, Controller 내 메소드가 invoke 된 후 반환하는 문자열 경로로 디스패쳐가 forward하는것도 리플렉션 덕이다.
이러한 리플렉션 개념은 API와 비슷하다 볼 수 있다. HTTP를 통해 특정 주소로 서버에 요청을 보내면 서버 내부의 메소드를 호출하여 결과값을 응답받을 수 있다.
