알고리즘 고수가 되기까지

설명 순서는 다음과 같습니다.

1. 프록시란
2. 객체에서 프록시
3. 프록시 구현
4. Spring에서 프록시 사용하기

1. 프록시란

   - 번역하면 '대리자' 라는 뜻임

   - 클라이언트-서버 개념에서 일반적으로 클라이언트가 서버를 직접 호출하고, 처리 결과를 직접 받는다

   - 그런데 클라이언트가 서버에 직접 요청하는 것이 아니라 어떤 대리자를 통해서 간접적으로 서버에 요청할 수 있음(클라이언트 -> 대리자 -> 서버)

   - 예를 들어 내가 직접 마트에서 장을 볼 수 있지만, 누군가에게 대신 장을 봐달라고 부탁할 수 있다

   - 여기서 이런 대리자를 '프록시' 라고 함

   - 프록시를 사용하면 프록시가 중간에서 여러가지 일을 할 수 있음

      ① 접근 제어 캐싱

         : 엄마에게 라면을 사달라고 부탁했는데, 엄마는 라면이 이미 집에 있다고 할 수 있음. 그러면 기대한 것 보다 빨리 먹을 수 있음

      ② 부가 기능 추가

         : 아빠에게 자동차 쥐유를 부탁했는데, 아빠는 주유뿐만 아니라 세차까지 하고 왔음. 기대한 것외에 세차라는 부가 긴으까지 얻게 되었음

      ③ 프록시 체인

         : 동생에게 라면을 사달라고 부탁했는데, 동생은 또 다른 동생에게 라면을 사달라고 부탁할 수 있음. 중요한 점은 클라이언트는 대리자를 통해 요청했기 때문에 그 이후 과정은 모름. 동생을 통해서 라면이 도착하기만 하면 됨

2. 객체에서 프록시

   - 객체에서 프록시가 되려면, 클라이언트는 서버에게 요청을 한 것인지 프록시에게 요청을 한 것인지 몰라야 함

   - 쉽게 말해서 서버와 프록시는 같은 인터페이스를 사용해야 함. 그렇게 되면 클라이언트가 사용하는 객체를 프록시 객체로 바꾸어도 클라이언트 코드를 변경하지 않아도 됨

   - 프록시의 주요 기능

      ① 접근 제어 : 권한에 따른 접근 차단, 캐싱, 지연 로딩

      ② 부가 기능 추가 : ex) 실행 시간 측정해서 로그 남김

3. 프록시 구현

   - 프록시 핵심 구조

      ① 프록시와 실제 서버는 같은 interface를 구현함 -> 클라이언트가 서버를 호출했는지 클라이언트를 호출했는지 모르게 하기 위해

      ② 프록시는 실제 서버를 필드로 갖고 있어서, 부가적인 일을 수행하는 도중에 실제 서버의 메서드를 호출함

4. Spring에서 프록시 사용하기

   - Controller, Service, Repository의 interface를 구현한 프록시 만들기

   - Bean으로 프록시 객체를 등록해서, 런타임시 클라이언트는 프록시 객체를 사용하도록 함

   - 그러면 프록시 객체를 따로 다 생성해서 Bean으로 등록해줘야 할까? 아님. 

   - Spring은 Java의 Reflection을 이용해서 부가 기능을 추가한 프록시를 동적으로 대신 생성해줌

      * Reflection : 클래스의 메타 정보를 획득해서, 코드를 동적으로 실행시킬 수 있는 기술

프록시에 대해 알아볼 수 있었습니다.

설명 순서는 다음과 같습니다.

1. AOP란
2. 문제 예시
3. 템플릿 메서드 패턴으로 해결하기

1. AOP란

   - Aspect Oriented Programming의 약자로 관점 지향 프로그래밍을 뜻함

   - 어떤 로직을 여러가지 관점으로 분리하고 각각의 관점을 모듈화하는 방법을 말함

   - 소스 코드상에서 부가적인 관점은 다른 부분에서 반복해서 사용할 때가 많은데, 이 때 이러한 관점을 한 곳으로 모아서 모듈화를 하고, 재사용하겠다는 취지임

2. 예시

   - Controller, Service, Repository의 메소드들의 실행시간을 측정하고 싶다고 가정

   - 코드 : 시작시간 재기 -> 핵심 로직 수행 -> 끝나는 시간 - 시작 시간으로 실행시간 측정

   - 위와 같은 코드를 모든 메소드에 추가해야함

   - 어떻게 줄일까? 이를 해결하는 여러 디자인 패턴부터 스프링의 AOP까지 정리해보자

3. 템플릿 메서드 패턴으로 해결하기

   - 템플릿 메서드 패턴의 핵심은 '변하는 것과 변하지 않는 것을 분리' 하는 것임

   - 여기서 변하는 것은 '핵심 로직'이고 변하지 않는 것은 '부가 로직(시간 측정)' 임

   - 그래서 변하지 않는 것을 '템플릿'으로 만들고 변하는 것은 '메서드'로 만들어서 해결하는 방법

   - 구현 : 추상 클래스로 템플릿을 만들고 이 안에 추상 메서드를 만든 후에, 이 클래스를 상속하는 자식 클래스가 자신의 핵심 로직을 추상메서드에 구현하는 방법

   - 변하지 않는 것은 추상클래스의 일반 메서드. 변하는 것은 추상클래스의 추상메서드. 실제 코드로 확인해보자

   - 이로써 중복을 줄이고, 관심사를 분리할 수 있음

   - 하지만 템플릿 메서드 패턴은 상속을 사용하고 있는데, 이 때문에 상속에서 오는 단점들을 안고감

   - 자식 클래스(핵심 기능) 입장에서는 부모의 기능을 전혀 사용하지 않는데 강하게 결합되어 있음. 그래서 부모가 변하면 자식에게도 영향을 줄 수 있음

AOP의 기초와 템플릿 메서드 패턴에 대해 알아볼 수 있었습니다.

설명 순서는 다음과 같습니다.

1. IOC란
2. IOC 컨테이너
3. DI란
4. IOC와 DI의 핵심

1. IOC란

   - Inversion Of Control의 줄임말로 직역하면 '제어의 반전' 이라는 뜻임

   - 그렇다면 제어가 어떻게 반전됐다는 걸까?

   - 일반적인 프로그램에서 제어권(객체의 생성 및 관리)는 개발자가 직접 해야함

   - 하지만, 스프링 프레임워크를 사용하면 이러한 제어권을 스프링이 갖게 됨

   - 이렇게, 프로그램의 제어권이 개발자에서 스프링이 쥔 것을 IOC라고 함

2. IOC 컨테이너

   - 이제 스프링 프레임워크가 제어권을 쥐고 객체의 생성과 관리를 담당함

   - 스프링에서 생성한 객체를 보관하고 관리하는 곳이 IOC 컨테이너임

   - 그리고 이 IOC 컨테이너에 등록되는 객체를 Bean이라고 부르고, 이 Bean들은 싱글톤으로 관리됨

   - 싱글톤 패턴이란

      * 클래스의 인스턴스가 딱 하나만 생성되는 것을 보장하는 디자인 패턴

      * 장점은 서버의 경우 요청마다 객체가 생성되고 소멸될 경우 메모리 낭비가 심한데, 이를 줄여줌

3. DI란

   - Dependency Injection의 줄임말로 직역하면 '의존성 주입'이라는 뜻임

   - IOC 컨테이너에서 한 객체를 생성해서 Bean으로 등록하는 과정에서, 그 객체에 필요한 다른 객체를 생성해서 넣어주는 과정이 DI임

   - 쉽게 말하면, 필요한 객체들을 생성한 후에 조립하는 과정이 DI임

4. IOC와 DI의 핵심

   - Spring에서 IOC와 DI를 도입한 이유는 프로그램의 제어권을 Spring이 받음으로써 개발자는 온전히 개발에만 집중할 수 있게 하기 위해서임

   - 그래서 개발자는 개발을 담당하고, Spring은 객체의 생성과 관리를 담당

   - 개발자와 프레임워크 사이에 역할을 명확히 나눈 것임

IOC와 DI에 대해 알아볼 수 있었습니다. 

Spring을 배우다보면 WAS, Dispatcher Servlet ... 등등 영어로 된 기괴한 용어들이 저희를 힘들게 합니다. 그 중 가장 처음에 등장하는 WAS와 Servlet의 개념에 대해 정리하려고 합니다.

1. WAS란?

WAS는 Web Application Server의 줄임말입니다. Application은 '응용'이란 뜻을 갖고 있습니다. 따라서, Web Application Server란 '웹(Web) 상에서 요청에 따라 동적(Application)으로 리소스를 제공(Server)하는 주체' 입니다. WAS의 종류에는 Tomcat, Jetty 등이 있고 Spring의 대표적인 WAS는 Tomcat입니다.

그렇다면 Spring의 WAS인 Tomcat을 이용해서 요청에 따라 다른 응답을 하는 '로직'을 작성할 수 있다는 건데,  Tomcat은 어떻게 우리가 이 로직을 잘 작성할 수 있도록 도와주는 걸까요?

2. Tomcat 없다면?

클라이언트와 서버는 HTTP 위에서 HTTP 메시지로 데이터를 주고 받습니다. 그리고, 이러한 HTTP 메시지는 예를 들어 아래와 같은 모양을 하고 있습니다.

우리는 서버의 입장에서 클라이언트로부터 위와 같은 HTTP 메시지를 받았다고 가정하겠습니다. Tomcat이 없는 우리가 가장 먼저 해야하는 일은 위 메시지에서 의미있는 문자를 뽑아내는 것입니다. 예를 들어 어떤 HTTP 메소드인지(get, post ..), 어떤 url인지(/save), 메시지 바디는 어떻게 되어있는지 등이 있습니다.

서버는 의미있는 비즈니스 로직을 짜는 일이 더 중요한데, 그것보다 HTTP 메시지를 파싱하는 일이 더 커져버리는 배보다 배꼽이 더 큰 상황이 벌어졌습니다.

3. Tomcat 하는 일

이러한 불편함을 해소시켜주는 것이 바로 Tomcat(WAS)입니다.

Tomcat은 클라이언트로부터 받은 HTTP 메시지를 잘 파싱해서 Request 객체로 만들어줍니다. 또한, 우리가 클라이언트에게 보내줘야할 응답인 Response 객체도 만들어주어서 응답 HTTP 메시지를 보다 쉽게 만들 수 있도록 도와줍니다. 

4. Servlet 이란?

우리는 WAS를 이용해서 HTTP 메시지를 손쉽게 다룰 수 있게 되었습니다. 그럼 이제 요청에 따라 응답을 동적으로 만들 '로직'이 필요합니다. 

이러한 '로직'이 있는 곳이 Servlet 입니다. Servlet에서 WAS로 부터 받은 Request 객체를 이용해서 동적인 Response 객체를 생성하고, 이를 다시 WAS에게 전달합니다. WAS는 받은 Response 객체를 응답 HTTP 메시지로 만들고 클라이언트에게 전달합니다.

따라서, Servlet은 'WAS로 부터 Request 객체를 전달받고 이를 통해 동적인 Response를 만드는 공간' 입니다.

이해하기 쉽게 대략적으로 작성한 내용이 많이 부실합니다. 큰 그림으로 WAS와 Servlet에 대해 이해하는데 도움이 되셨으면 좋겠습니다~