자기개발/개발이야기

Welcome To Spring :)

참고 : asfirstalways.tistory.com/334

 

드디어 나한테도 봄이 왔다.

 

한국에서 백엔드 개발자를 한다고 하면 피해갈 수 없는게 바로 이 봄인 것 같다.

 

이 봄은 내가 이때까지 쓰던 프레임워크랑 반대로 규칙을 강제하는 부분이 많기에, 프레임워크에서 하고자하는 의도와 동작한느 원리를 알지 못하는 상태에서 접근하면 피상적인 이해만 한 후 끝날 가능성이 높다 생각했다.

 

그래서 하나하나... 정리를 해보자.

 

글이 혼란스러울 수 있는데 남이 읽으라고 쓴 글이 아닌 내 머릿속에서 정리한걸 남겨둔거라 혼란스러우면 정확히 읽고 있는거 맞다.

 

## Servlet

자바 개발자라면 다 들어봤을 단어. 그러나 나는 C# 개발자였기에 들어본 적 없다.

Servlet 클래스라고 있는데, 이게 뭘까요?

docs.oracle.com/javaee/5/tutorial/doc/bnafe.html

 

What Is a Servlet? - The Java EE 5 Tutorial

What Is a Servlet? A servlet is a Java programming language class that is used to extend the capabilities of servers that host applications accessed by means of a request-response programming model. Although servlets can respond to any type of request, the

docs.oracle.com

공식 문서는 답이 있다.

정확히는 Servlet은 `자바 클래스`를 말하는 것이고, 이것은 `Request-Response programming model로 된(by means of) 접근을 받는 Host Application에게 capabilities를 extend해주는 class`이다. 

근데 일반적으로 Web에 쓰인다 한다. 그러니 대부분의 Servley은 그에 맞는 표현이라 생각하는게 맞지 않을까 싶다.
`For such applications, Java Servlet technology defines HTTP-specific servlet classes`기 때문에!

 

### Servlet Life Cycle서블릿은 서블릿을 디플로이한 `Container`가 제어하게 된다. 그러니까 실제 Request가 Servlet에 매핑되어서 오게 되는데, 그 때 Container가 다음 행동을 한다. - Servlet 클래스의 `인스턴스`가 없으면 다음 절차를 거친다   - Servlet Class를 불러온다. -> 인스턴스를 만든다. -> Init 불러서 초기화 한다.  - 이제 인스턴스가 있을테니 Service 메소드에 request와 response 오브젝트를 패싱하며 호출한다. -> request는 알겠는데 response는 왜 패싱하죠? -> 패싱시킨다음에 안에서 변경해주면 된다. 리턴하지 않음 -> ??????? 그렇구나 알겠습니다 (당연히 함수 반환값에 return할줄)

 

 - 이런 과정에서 이제 다양한 Event가 발생하는데, 이 Event를 Listen해서 이벤트를 받아서 처리할 수 있다. 리스너 클래스를 만들어야하고, 이벤트가 발생하면 이벤트정보가 함수로 넘어온다.

 

더 많긴 했는데 여기까지만 알아보고 넘어감...

 

 

## Spring스프링의 특징이라고 하면 이 3개를 꼽는거같다.`컨테이너` `IoC` `AOP` 

 

### 컨테이너

 - 포괄적인 정의다

   - 객체의 `생성`,`관리`를 담당

   - 생성은 뭔데?

      - 맞는 걸 좋게 만들어주는거. 그러니까 Factory가 맞다.

   - 관리는 뭔데?

      - 팩토리에서 만들어진걸 관리하면 그게 관리지

 

### IoC

 - Inversion of Control이라고 하는데 이게 왜 Inversion Of Control이고 왜 DI랑 같이 엮이는지 알아야한다.

 - 이렇다면 기존의 Control이 어떻게 이루어지는지 알아야한다.

 - 기존의 Control은 사용자가 작성한 코드가 Library를 호출하는 거였다.

 - 이것이 역전되었다는 것은 Library가 우리의 코드를 부른다는 것이다.

 - 사실 라이브러리르 쓰면서 우리가 당연하게 IoC를 누리고있어서 이게 왜 특이점인지 헷갈려서 많이 헷갈린다 (나는 그랬음)

 - 그냥 이러면 IoC다

   - 내가 하려는 것에 대해 하는 방법이 정해져있고, 내가 할 수 있는 것은 그것을 호출 할 뿐이다.

     - ko.wikipedia.org/wiki/%EC%A0%9C%EC%96%B4_%EB%B0%98%EC%A0%84

     - 이 예제 이해하기가 나만 힘든가? 원래 DAO의 검증을 ServerFacade 클래스에서 하고 있어서, DAO를 변경하면 ServerFacade를 변경해야되었는데, 저렇게 DAO에 역할을 넘기면 이제 ServerFacade는 DAO와 정해진 방법으로만 통신하고, 처리를 DAO 내부에서 한다.

     - 그러니까 DAO에서 데이터를 가져오는 과정에서 검증에 대한 `제어`를 원래 ServerFacade에서 하던걸 DAO에서 처리하게 해서 (원래는 ServerFacade에서 부르느까 전통적 프로그램 구조라면 DAO를 ServerFacde가 직접 컨트롤) 데이터를 가져오는 일련의 절차에서 검증에 대한 제어를 DAO로 역전시킨 느낌.

 - 그럼 DI는 뭘 하는거냐? 하면 의존성 주입이라는건데 의존성이 뭐고 주입은 뭔데? 라는 이야기를 하게 되면 일단 의존성이 뭔지 알아야한다.

 - 여기서 의존성이란 `하나 바뀌면 다른거 같이 바뀌어야 되는 성질`이라 해도 될거같다.  그러니까 A가 B에 의존성이 있다 하면, B가 바뀌면 A도 맞춰서 바뀌어야 된다는 거다.

 - 그래서 의존성 주입이랑 이게 뭔상관이냐? 외부에서 B를 넣어줘봤자 B가 바뀌면 A도 바뀌어야되는거 아니냐? 하는데... 사실 `B를 넣어주는 쪽이 바뀌면 된다`

 - 그러니 C라는 애가 B를 A에 넣어주는 방식이면, B가 바뀌면 C를 바꿔야한다. 

 - 보통 여기서 A는 엄청 많고, B는 그다음으로 적고, C는 더더욱 적다.

 - 의존성을 주입하게 되면 A와 B의 의존관계를 없앨 수 있다. 하지만 C와 B의 의존 관계는 생기겠지. 이건 어쩔수 없는거지. 인생에서 누군가 기댈 존재가 있어야한다.

 - 아니 근데 다른걸 넣어주면 결국 A도 바뀌어야되는거 아님? 하시는분들을 위해, 보통 그래서 주입하는건 인터페이스로 묶어서 넣는다. 다른걸 주입해도 잘 돌아가게. 문자열로 해도 되고? 여튼 애초에 A가 의존성 주입을 받기 위한 준비가 되어있어야한다. 결합도를 낮추기 위한 방법이지 마법의 기술이 아니다... 

 - 스프링에서는 이를 위해서 `어노테이션`을 사용한다. 어질어질하군...

 

### AOC

Aspect Oriented Programming이라는데, 이것도 왜 관점이라는 이상한 말을 쓰는지 벌써 혼란스러울것이다. 이 관점이라는 것은, 그것이 어디에 있는지가 아니라 `무엇을 하는 것인지`를 보자는 것이다.

대표적으로 드는것이 로깅 기능이다. 근데 여기서 `아 그럼 로깅이 관점이구나~`라고 이해하면 안되고, 로깅이 `횡단 관심사`라는 것을 명확히 알아야된다. 횡단이면 종단도 있겠지? 근데 종단이라는 말은 안쓰고 `핵심 관심사`라는 표현을 쓴다. 왜냐면 어떠한 기능이 있을 때 횡단 관심사에 해당된다는 것은 다른 기능과 공통으로 쓴다는 것인데, 이걸 때면 그 기능 고유의 관심사만 남는다. 그래서 그렇다.

이러한 고유 관심사만 남기고, 다른 횡단 관심사를 분리하자. 그래서 AOC에서 하는 설명은 고유 관심사가 아닌 실제로 바꿔야 할 횡단 관심사 위주로 이루어진다.

이러면 결국 공통되는게 빼진 종단관심사인 핵심 관심사만 남아서 응집도가 높아진다. 

 

### POJO를 왜 계속 강조하는가

 - 이전의 복잡한 프로그래밍에 대한 히스토리를 알 필요가 있다.

 - 예시로 나오는게 Servlet인데 이건 그냥 base class같은 거라서 이걸 상속한 다음 관련 사항을 다 구현해줄 필요가 있었다. 

 - 그런 복잡한 것에 대한 ㅈ대항심에서 나온게 POJO고, 그래서 그냥 심플 오브젝트라 생각하면 된다.

 - 그래서 엄격하게 POJO란 상속도 없고, 인터페이스도 없고, 어노테이션도 없고 그런데, 이걸 엄격하게 지키긴 힘들어서 여따가 `POJO인데 Annotation을 살짝 섞은 ㅎ;` 같은 느낌으로 멋대로 붙이긴 한다

 - 여튼 복잡하지 않은 오브젝트를 말함에는 다름이 없다

 - 이러한 방식은 최대한 간단한 구조를 유지함으로써 중요한 문제에 집중하게 해준다. 우리가 Servlet을 사용할 때 중요한건 무엇을 하려인가이지 Servlet의 사용법은 둘째 문제다. 그 둘째 문제에 `덜` 집중할 수 있게 해준다.

 - `덜`이니까 하긴 해야된다. 어떻게 쓰는진 알아야지...

 

###