[강의] HTTP 웹 기본 지식

HTTP 메서드의 속성

• 안전(Safe): 호출해도 리소스를 변경하지 않음.
  - GET, HEAD
• 멱등(Idempotent): 여러 번 호출해도 값이 동일함.
  - GET, PUT, DELETE
• 캐시가능(Cacheable): 응답 결과 리소스를 캐시화하는게 가능함.
  - GET, HEAD, POST, PATCH

데이터를 전달하는 상황

• 정적 데이터 조회: 쿼리 파라미터없이 리소스 경로로 단순하게 조회 가능 -> /static/star.jpg
• 동적 데이터 조회: 쿼리 파라미터를 사용해서 데이터 전달 -> /search?q=hello&hl=ko
• HTML Form을 통한 데이터 전송: form의 내용을 메시지 바디를 통해서 전송, 컨텐트 타입에 따라 형식이 다름.
  - application/x-www-form-urlencoded: 전송 데이터 url encoding 함.
  - multipart/form-data: 여러 개의 컨텐츠 타입에 대한 데이터 전송 가능
  - ex) 텍스트와 byte 형식의 파일을 같이 보낼 때
• HTTP API를 통한 데이터 전송: 직접 전송하고 싶은 데이터를 작성해서 전송
  - application/json: JSON 형태로 전송

[강의] 스프링 핵심 원리 - 기본편

프로토타입 스코프를 싱글톤 빈과 함께 사용하면?

프로토타입 스코프: 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프

해당 빈을 단독으로 사용하면 프로토타입 빈의 특성을 살릴 수 있지만,
싱글톤에 프로토타입 빈을 주입한 후에 사용하게 되면 프로토타입 빈의 특성을 살릴 수 없음.

싱글톤이 생성될 때, 이미 프로토타입 빈이 생성되어 주입됨.
이때 싱글톤의 로직을 사용하게 되면 프로토타입 빈을 새로 생성하는 것이 아닌 미리 생성해둔 빈을 사용하므로 프로토타입 빈의 특성을 살릴 수 없음.

문제 해결 - Provider

• Provider: 지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공함.
• 의존관계 조회/탐색(DL; Dependency Lookup): 의존관계를 외부에서 주입(Injection)받는게 아니라 직접 필요한 의존관계를 찾는 것.

Provider은 프로토타입 뿐만 아니라 DL이 필요한 경우에 언제든지 사용 가능함.

종류

• ObjectFactory, ObjectProvider: 스프링이 제공하는 Provider 기능이므로, 스프링에 의존적임.
• JSR-330 Provider: 자바 표준에서 제공하는 Provider 기능이므로, 스프링이 아닌 다른 컨테이너에서도 사용하기 쉬움.
  - 대신 별도의 라이브러리를 통해 받아와야 함.

웹 스코프

웹 환경에서만 동작하는 스코프
스프링이 해당 스코프의 종료시점까지 관리함. - 종료 메서드가 호출됨.

@Scope(value="request")처럼 스코프 지정이 가능함.

종류

• request: HTTP 요청 하나가 들어오고 나갈 때까지 유지되는 스코프
• session: HTTP Session과 동일한 생명주기를 가지는 스코프
• application: 서블릿 컨텍스트(ServletContext)와 동일한 생명주기를 가지는 스코프
• websocket: 웹 소켓과 동일한 생명주기를 가지는 스코프

ex) request
클라이언트 A와 B가 똑같은 요청을 하면 A 전용의 빈과 B 전용의 빈을 따로 생성함.

+) controller와 service
웹과 관련된 부분은 컨트롤러까지만 사용해야 함.
예를 들어 requestURL(HttpServletRequest request.getRequestURL()로 받은 URL: ex) http://loclhost:8080/log-demo) 같은 웹과 관련된 정보는 웹과 관련없는 서비스 계층까지 넘어가지 말도록 해야 함.

[책] 객체지향의 사실과 오해

다형성

• 송신자는 수신자에 대한 정보를 모르는 상태로 수신자에게 요청함.
  • 송신자는 수신자가 해당 요청을 처리할 수 있는지에 대한 정보만 알고 보냄.
• 수신자는 자율적인 객체이므로 요청에 대해 응답하는 방법을 자유롭게 선택할 수 있음.
• 그럼에도 불구하고 송신자는 이 사실을 모르며, 송신자가 받게되는 응답 또한 변하지 않을 것임.

• 다형성: 객체들의 대체 가능성을 이용해 설계를 유연하고 재사용 가능하게 만듦.
• 수신자는 요청에 대한 응답을 할 수 있다면 그 어떤 객체도 수신자가 될 수 있음.
• 송신자는 수신자가 누군지 모르며, 심지어 누구든 상관 없음. 그러므로 수신자는 대체가 가능함.
  -> 다형성은 수신자의 종류를 캡슐화함.

=> 다형성을 이용하면 메시지를 이해할 수 있는 어떤 객체와도 협력할 수 있는 유연하고 확장 가능한 구조를 만들 수 있음.

다형성의 장점

1. 협력이 유연해진다.
   • 송신자는 수신자가 메시지를 이해한다면 누구라도 상관하지 않음.
2. 협력이 수행되는 방식을 확장할 수 있다.
   • 송신자에게 아무런 영향을 미치지 않고서도 협력의 세부적인 수행 방식을 쉽게 수정할 수 있음.
3. 협력이 수행되는 방식을 재사용할 수 있다.
   • 협력에 영향을 미치지 않고서도 다양한 객체들이 수신자의 자리를 대체할 수 있음.

메시지

다형성이 가능한 이유는 송신자와 수신자의 사이에 결합도 낮은 관계가 이어지고 있기 때문이며, 이 관계는 메시지로만 이루어져 있음.

?) 객체지향은 클래스 집합인가?

!) 클래스는 단지 동적인 객체들의 특성과 행위를 정적인 텍스트로 표현하기 위해 사용할 수 있는 추상화 도구임.
객체지향을 구성하는 것은 객체이며, 객체들의 윤곽을 결정하는 것이 메시지임.

데이터 주도 설계는 좋지 않아요

데이터 주도 설계: 데이터를 중심으로 객체를 설계하는 방식
이는 객체의 자율성을 저해함.
이를 통해 객체 외부에서는 몰라도 되는 객체 내부 구조의 변경이 외부의 협력자에게까지 파급될 것.
-> 객체를 독립된 단위가 아니라 협력이라는 문맥 안에서 생각해야 함.

=> 어떤 객체가 어떤 메시지를 전송할 수 있는가와 어떤 객체가 어떤 메시지를 이해할 수 있는가를 중심으로 객체 사이의 협력 관계를 구성하는 것이 휼륭한 객체지향 설계법임.

책임-주도 설계

책임을 완수하기 위해 협력하는 객체들을 이용해 시스템을 설계하는 방법

객체가 책임을 완수하기 위해 다른 객체의 도움이 필요하다고 판단되면 도움을 요청하기 위해 어떤 메시지가 필요한지 결정함.
메시지를 결정하면 메시지를 수신하기에 적합한 객체를 선택함.
선택된 객체는 수신자가 되어 송신자가 기대한 대로 메시지를 처리할 책임이 있음.
=> 메시지가 수신자의 책임을 결정함.

What/Who 사이클

'어떤 행위(what)'를 수행할 것인지를 결정한 후에 '누가(who)' 그 행위를 수행할 것인지를 결정해야 하는 것

• '어떤 행위': 메시지
• '누가': 수신자로 선택된 객체

행위를 먼저 식별한 후에 행위를 수행할 적절한 객체를 찾아야 함.
-> 메시지를 먼저 결정한 다음에 메지리를 수신하기에 적합한 객체를 선택해야 함.
=> 객체의 책임을 결정하는 것은 메시지임.

메시지에 초점을 맞추게 함으로써 객체지향의 장점을 극대화함.

묻지 말고 시켜라

메시지가 '어떻게' 해야 하는지를 지시하지 말고 '무엇'을 해야하는지를 요청하는 것

송신자는 수신자의 내부 상황을 볼 수 없으며, 수신자가 메시지를 처리할 수 있다는 믿음만을 가지고 전송하는 것임.

효과

1. 객체를 자율적으로 만듦.
2. 캡슐화를 보장함.
3. 결합도를 낮게 유지시킴.
   -> 설계를 유연하게 함.