Week02

프레임 워크, API, 라이브러리

프레임워크

• 어떠한 목적을 쉽게 달성할 수 있도록 해당 목적과 관련된 코드의 뼈대를 미리 만들어둔 것
• 내가 프레임워크 안에 원하는 코드를 채워넣으면 실행 흐름은 프레임워크가 주도한다
• 즉 프레임워크가 코드를 호출 → 제어 역전 (IoC)
• 예를 들어 웹을 만들기 위해 Spring boot를 사용할 경우 각 URL이 어떤 함수에 연결되는지만 정한다면 나머지의 흐름은 모두 프레임워크가 알아서 처리한다

API

• 애플리케이션 프로그래밍 인터페이스 (Application Programming Interface)
• 2개 이상의 소프트웨어 컨포넌트(독립적인 기능을 수행하는 소프트웨어 부품) 사이에서 상호작용할 수 있도록 정의된 인터페이스
• 하나의 소프트웨어 안에 존재하는 여러 컨포넌트 사이에서 상호작용이 일어날 수도 있고(함수 호출), 하나의 컴퓨터 안의 여러 소프트웨어 컨포넌트 사이에서 상호작용이 일어날 수도 있고 서로 다른 컴퓨터의 컨포넌트 사이에서 상호작용이 일어날 수도 있다
• 그러나 API라는 말은 주로 네트워크를 통해 멀리 떨어진 다른 프로그램과 소통하는 Web API 호풀을 의미한다
• 소프트웨어 어플리케이션들이 서로 데이터를 주고받으며 통신할 수 있도록 만들어진 규칙
• 스프링 부트의 경우 @PostMapping(), @RequestBody, return 등을 사용해 통신 API를 구현한다. 우리가 이런 어노테이션들로만 api를 만들 수 있는 이유는 이외 복잡한 처리들을 모두 스프링부트에서 자동으로 처리해주고 있기 때문이다
• 개발자가 @PostMapping 어노테이션을 붙였을 때 스프링 부트가 뒤에서 해주는 일들은 다음과 같다

1. 내장 웹 서버 실행: 톰캣(Tomcat) 같은 웹 서버를 자동으로 실행시켜서 인터넷 요청을 받을 준비를 한다
2. 요청 분석 (디스패처 서블릿): 들어온 HTTP 요청의 URL("/hello")과 메서드(POST)를 보고, 어떤 코드(@PostMapping이 붙은 메서드)에게 일을 시켜야 할지 정확히 찾아 연결해준다
3. 데이터 변환 (JSON → DTO): @RequestBody를 보면, 요청 메시지에 담겨 온 JSON 형식의 텍스트를 개발자가 만든 자바 객체(DTO)로 자동으로 변환한다 → 역직렬화(Deserialization)
4. 응답 데이터 변환 (객체 → JSON): 개발자가 메서드에서 객체(DTO)를 return하면 이것을 다시 JSON 형식의 텍스트로 자동으로 변환해서 응답 메시지에 담아 보낸다 → 직렬화(Serialization)

즉, 스프링부트와 같은 프레임워크를 사용함으로써 개발자는 가장 중요한 비즈니스 로직에만 집중하고 반복적인 네트워크 처리나 데이터 변환 작업을 스프링부트에게 일임한다

라이브러리

• 프로그램 개발에 필요한 함수, 클래스, 객체들을 모아둔 도구들
• 개발자는 필요할 때 직접 라이브러리의 기능을 직접 호출하여 사용할 수 있다
• 제어권이 항상 개발자에게 있다

제어 역전과 의존성 주입

IoC

• 제어 역전
• 제어 역전을 실현하는 방법 중 하나 = 의존성 주입 (DI, Dependency Injection))

DI

• 의존성 주입
• 객체가 필요로 하는 것(의존성)을 직접 만드는 대신 외부에서 주입해주는 것
• 의존성이란 한 객체가 동작하기 위해 다른 객체가 미리 만들어져 있어야 함을 의미한다
• 의존관계 주입을 위해서는 아래 세 가지의 조건이 필요하다

1. 코드에는 런타임 의존관계가 드러나지 않는다. 인터페이스에만 의존하고 있어야 한다

• 예를 들어 '커피 머신' 클래스를 위해 '원두'라는 클래스를 만들고자 할 경우
• '원두'라는 인터페이스 아래 '원두'를 상속받는 여러 원두 클래스(에티오피아 원두, 케냐 원두 등등)를 작성한다
• 커피 머신 클래스는 인터페이스 '원두'를 어트리뷰트로 사용한다

public class CoffeeMachine {

    // 인터페이스 안에 채워지는 객체는 외부에서 만들어져 주입됨(의존성 주입)
    private CoffeeBean coffeeBean;

    // 생성자를 통해 외부에서 주입받음
    public CoffeeMachine(CoffeeBean coffeeBean) {
        this.coffeeBean = coffeeBean;
    }

    // coffeeBean을 사용하는 메소드의 경우 coffeeBean 종류에 따라 다른 결과가 나오게 됨
    // 그러나 CoffeeMachine은 인터페이스 객체 안에 어떤 객체가 올 지 알 수 없고 알 필요도 없음
    public void brew() {
        coffeeBean.brew();
    }
}

2. 의존관계는 제 3자가 결정한다

• 위의 커피 머신에서 어떤 원두를 사용할 지는 컨테이너(제 3자)가 결정한다
• 스프링 부트가 실행될 때 컨테이너는 @Component, @Service 등의 스프링 Bean 관련 어노테이션들이 붙은 클래스를 스캔한 뒤 필요한 부품들을 미리 다 만들어둔다

3. 의존관계는 외부에서 주입한다

• 위에서 컨테이너가 생성한 부품들은 CoffeeMachine 클래스의 외부(컨테이너)로 부터 주입된다
• 주입을 위한 어노테이션은 @Autowired
• 의존관계 주입 방식에는 대표적으로 3가지가 있다

1. 생성자 주입 : 객체가 생성될 때 생성자를 통해 주입. 객체의 불변성을 보장한다 (생성자가 하나인 경우 @Autowired 생략 가능/가장 권장되는 방식)
2. 수정자 주입 : 세터와 같은 메서드에 @Autowired를 붙여 주입
3. 필드 주입 : 변수 자체에 @Autowired를 바로 붙여서 주입

• 이를 통해 CoffeeMachine은 CoffeeBean라는 인터페이스에만 의존하기에 원한다면 구체적인 원두 클래스를 얼마든지 만들어낼 수 이다

즉, 원래라면 CoffeeMachine 객체가 스스로 원하는 원두 객체를 생성해 사용했다. 그러나 제어 역전으로 인해 CoffeeMachine는 아무것도 하지 않고 제어권을 가진 컨테이너가 커피 원두를 생성하고 CoffeeMachine 내로 주입해준다

이처럼 각 객체끼지의 의존성이 존재할 때 의존성을 외부에서 주입받으면 의존관계를 직접 작성할 필요가 없어 개발자의 부담이 줄어든다

서블릿

자바 서블릿

• 웹 페이지를 동적으로 생성하는 서버 측(스프링부트 어플리케이션 측) 프로그램
• 기존의 서버는 정적인 자료만을 주고받았다
• 그러나 웹에 다양한 기능이 요구되면서 사용자의 요구에 맞춘 동적인 페이지를 만들 필요가 생겼다
• 이를 위해 만들어진 것이 서블릿이며 자바에서 웹 어플리케이션을 만들 때 HTTP 요청을 처리하는 역할을 한다

서블릿의 동작 방식

전통적인 동작 방식

1. 클라이언트에게서 요청(HTTP Request)가 날아온다
2. 서블릿 매니저는 해당 요청의 web.xml 파일을 보고 담당 서블릿을 확인한 뒤 HttpServletRequest를 담당 서블릿에게 넘겨준다
3. 담당 서블릿은 서비스 메소드를 호출해 로직을 실행한다
4. 서블릿은 완성된 결과는 HttpServletResponse에 담아 서블릿 매니저에게 전달한다
5. 사용이 끝난 HttpServletRequest와 HttpServletResponse를 삭제한다

스프링 동작 방식

1. 클라이언트에게서 요청(HTTP Request)가 날아온다
2. DispatcherServlet가 요청을 받아 URL을 보고 담당 컨트롤러에게 해당 요청을 넘긴다
3. 컨트롤러, 서비스, 레파지토리를 통해 로직이 실행된다
4. 완성된 결과는 View 혹은 JSON으로 처리된다
5. DispatcherServlet은 해당 결과를 HTTP Response로 전달한다

차이점

• 스프링 동작 방식을 사용할 경우 각 URL 요청마다 담당 서블릿을 지정할 필요 없이 DispatcherServlet이라는 하나의 창구가 모든 요청을 받아 적절한 컨트롤러에게 분배한다
• 개발자는 HttpServletRequest, Response 객체를 직접 다루며 요청과 응답의 전 과정을 코드로 구현해야 할 필요가 없다
• web.xml 파일에 어떤 URL을 어떤 서블릿이 처리할지 일일이 등록할 필요 없이 @GetMapping, @PostMapping 같은 어노테이션으로 간단하게 URL을 매핑할 수 있다

서블릿 컨테이너

• 서블릿을 관리하는 컨테이너 역할
• 서블릿 컨테이너는 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명 주기를 관리한다
• 대표적인 서블릿 컨테이너는 톰캣이 있다
• 톰캣은 실제로 웹 서버와 통신하며 Java Server Page와 서블릿이 작동하는 환경을 제공해준다
• 원래 네트워크를 통한 소통을 위해서는 Socket을 만들고, listen(), accept(), connect() 등으로 구현해야 한다
• 서블릿 컨테이너는 이런 기능을 API로 제공하여 간편화하였다

Bean

Bean

• 스프링 컨테이너가 관리하는 자바의 객체
• 스프링은 빈을 통해 객제를 인스턴스화 한 후 객체 간의 의존관계를 관리한다
• 스프링에서 어플리케이션을 실행할 때 빈을 관리하고 조회하는 기능들을 관리하는 존재가 필요한데 이를 담당하는 것이 "스프링 컨테이너"이다
• 스프링은 웹에서 필요한 모든 객체를 어플리케이션이 시작할 때 만들어 자기들끼리 알아서 연결해준다
• 스프링 빈의 범위는 어플리케이션을 구성하는 거의 모든 객체이다
• 그 범위는 클래스 내부의 어트리뷰트부터 Controller 계층 전체, Service 계층 전체, Repository 계층 전체로 다양하다
• 이를 통해 객체 간의 결합도를 낮추고 코드를 유연하게 바꿀 수 있다

컴포넌트 스캔과 자동 주입

• @Component → @Autowired
• 스프링에서는 new 생성자를 통해 객체를 직접 생성하지 않고 @Autowired 어노테이션을 통해 객체를 등록한다
• @Controller, @Service, @Repository 어노테이션을 사용할 때 해당 어노테이션들 안에 명시적으로 @Component 어노테이션이 들어있다
• 즉 @Component 어노테이션을 추가하지 않더라도 스프링은 @Controller, @Service, @Repository 어노테이션이 붙은 클래스들을 스캔하며 Bean으로 등록한다

명시적 빈 정의

• @Configuration → @Bean
• @Configuration 어노테이션을 통해 개발자가 Bean의 생명주기를 직접 관리할 수 있다
• 관리를 위한 클래스에 @Configuration 어노테이션을 붙여주고 언하는 메소드에 @Bean 어노테이션을 붙여 원하는 빈의 생성, 소멸을 설정을 결정할 수 있다
• 해당 방법의 장점은 외부 라이브러리 객체를 빈으로 등록할 수 있다는 것이다 (외부 라이브러리 클래스의 코드에 @Component를 붙일 수는 없음)

즉, IoC(제어 역전) 컨테이너는 위의 모든 과정을 거쳐 POJO(Plain Old Java Object, 순수 자바 객체) 기반의 개발을 가능하게 하는 것이다!

SOLID와 AOP

SOLID

객체 지향 프로그램을 더 유연하고 유지/보수하기 편하게 만들기 위한 5가지 설계 원칙

1. S : 단일 책임 원칙. 하나의 클래스는 단 하나의 책임만을 가져야 한다. 하나의 기능을 변경할 때 하나의 클래스만을 수정할 수 있도록 하자
2. O : 개방-폐쇄 원칙. 확장에는 열려 있고 수정에는 닫혀 있어야 한다. 기존의 코드를 바꾸지 않고도 새로운 기능을 추가할 수 있어야 한다.
3. L : 리스코프 치환 원칙. 하위 타입은 언제나 상위 타입으로 대체할 수 있어야 한다. 자식 클래스는 부모 클래스의 역할을 대체했을 때, 기존 프로그램의 동작을 깨뜨리지 않아야 한다 (자식은 언제나 부모의 의도대로 동작할 것)
4. I : 인터페이스 분리 원칙. 인터페이스는 최소한의 기능을 가지며 구체화 시, 불필요한 메소드를 가져서는 안 된다.
5. D : 의존관계 역전 원칙. 언제든 객체를 쉽게 교환할 수 있도록 세부적인 구현 클래스에 의존하는 대신 추상화(인터페이스)에 의존해야 한다

의존관계 역전 원칙과 리스코프 치환 원칙의 내용은 이어지는 내용 - 의존관계 역전 원칙(DIP)이 제대로 동작하기 위한 전제 조건이 바로 리스코프 치환 원칙(LSP)이다

AOP

• AOP(관점 지향 프로그래밍)는 소프트웨어의 '핵심 비즈니스 로직'과 여러 곳에 흩어져 반복적으로 나타나는 '공통 기능'을 분리하는 개발 방식
• 스프링에서는 주로 로그 기록, 트랜잭션 처리, 보안 검사 같은 공통 기능을 AOP로 구현하여 코드 중복을 제거하고 핵심 비즈니스 로직을 깔끔하게 유지한다