ZeroOne

스프링 MVC - 구조 이해

zerone — Tue, 26 Jul 2022 05:52:59 +0900

스프링 MVC 전체 구조

직접 만든 프레임워크 스프링 MVC 비교

FrontController -> DispatcherServlet

handlerMappingMap -> HandlerMapping
MyHandlerAdapter -> HandlerAdapter
ModelView -> ModelAndView
viewResolver -> ViewResolver

MyView -> View

동작 순서

핸들러 조회: 핸들러 매핑을 통해 요청 URL에 매핑된 핸들러(컨트롤러)를 조회한다.
핸들러 어댑터 조회: 핸들러를 실행할 수 있는 핸들러 어댑터를 조회한다.
핸들러 어댑터 실행: 핸들러 어댑터를 실행한다.
핸들러 실행: 핸들러 어댑터가 실제 핸들러를 실행한다.
ModelAndView 반환: 핸들러 어댑터는 핸들러가 반환하는 정보를 ModelAndView로 변환해서 반환한다.
viewResolver 호출: 뷰 리졸버를 찾고 실행한다.
JSP의 경우: InternalResourceViewResolver 가 자동 등록되고, 사용된다.
View 반환: 뷰 리졸버는뷰의 논리 이름을 물리 이름으로 바꾸고, 렌더링 역할을 담당하는 뷰 객체를 반환한다.
JSP의 경우 InternalResourceView(JstlView) 를 반환하는데, 내부에 forward() 로직이 있다.
뷰 렌더링: 뷰를 통해서 뷰를 렌더링한다.

HandlerMapping(핸들러 매핑)
핸들러 매핑에서 이 컨트롤러를 찾을 수 있어야 한다.
예) 스프링 빈의 이름으로 핸들러를 찾을 수 있는 핸들러 매핑이 필요하다.

HandlerAdapter(핸들러 어댑터)
핸들러 매핑을 통해서 찾은 핸들러를 실행할 수 있는 핸들러 어댑터가 필요하다.
예) Controller 인터페이스를 실행할 수 있는 핸들러 어댑터를 찾고 실행해야 한다.

스프링은 이미 필요한 핸들러 매핑과 핸들러 어댑터를 대부분 구현해두었다. 개발자가 직접 핸들러 매핑과 핸들러 어댑터를 만드는 일은 거의 없다.

스프링 부트가 자동 등록하는 핸들러 매핑과 핸들러 어댑터

(실제로는 더 많지만, 중요한 부분 위주로 설명하기 위해 일부 생략)

HandlerMapping

0 = RequestMappingHandlerMapping : 애노테이션 기반의 컨트롤러인 @RequestMapping에서 사용
1 = BeanNameUrlHandlerMapping : 스프링 빈의 이름으로 핸들러를 찾는다.

HandlerAdapter

0 = RequestMappingHandlerAdapter : 애노테이션 기반의 컨트롤러인 @RequestMapping에서 사용

뷰 리졸버 - InternalResourceViewResolver
스프링 부트는 InternalResourceViewResolver 라는 뷰 리졸버를 자동으로 등록하는데, 이때 application.properties 에 등록한 spring.mvc.view.prefix , spring.mvc.view.suffix 설정 정보를 사용해서 등록한다.

스프링 부트가 자동 등록하는 뷰 리졸버
(실제로는 더 많지만, 중요한 부분 위주로 설명하기 위해 일부 생략)

1 = BeanNameViewResolver : 빈 이름으로 뷰를 찾아서 반환한다. (예: 엑셀 파일 생성 기능에 사용)
2 = InternalResourceViewResolver : JSP를 처리할 수 있는 뷰를 반환한다.

뷰 리졸버 동작 방식

1. 핸들러 어댑터 호출
핸들러 어댑터를 통해 new-form 이라는 논리 뷰 이름을 획득한다.

2. ViewResolver 호출
2-1. new-form 이라는 뷰 이름으로 viewResolver를 순서대로 호출한다.
2-2. BeanNameViewResolver 는 new-form 이라는 이름의 스프링 빈으로 등록된 뷰를 찾아야 하는데 없다.
2-3. InternalResourceViewResolver 가 호출된다.

3. InternalResourceViewResolver
이 뷰 리졸버는 InternalResourceView 를 반환한다.

4. 뷰 - InternalResourceView
InternalResourceView 는 JSP처럼 포워드 forward() 를 호출해서 처리할 수 있는 경우에 사용한다.

5. view.render()

view.render() 가 호출되고 InternalResourceView 는 forward() 를 사용해서 JSP를 실행한다.

참고
> InternalResourceViewResolver 는 만약 JSTL 라이브러리가 있으면 InternalResourceView 를

상속받은 JstlView 를 반환한다. JstlView 는 JSTL 태그 사용시 약간의 부가 기능이 추가된다.

참고
> 다른 뷰는 실제 뷰를 렌더링하지만, JSP의 경우 forward() 통해서 해당 JSP로 이동(실행)해야 렌더링이

된다. JSP를 제외한 나머지 뷰 템플릿들은 forward() 과정 없이 바로 렌더링 된다.

참고
> Thymeleaf 뷰 템플릿을 사용하면 ThymeleafViewResolver 를 등록해야 한다. 최근에는 라이브러리만

추가하면 스프링 부트가 이런 작업도 모두 자동화해준다.

MVC 프레임워크 만들기

zerone — Sat, 16 Jul 2022 16:39:19 +0900

프론트 컨트롤러 패턴 소개

FrontController 패턴 특징

프론트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받음
프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출
입구를 하나로!
공통 처리 가능
프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨

스프링 웹 MVC와 프론트 컨트롤러
스프링 웹 MVC의 핵심도 바로 FrontController
스프링 웹 MVC의 DispatcherServlet이 FrontController 패턴으로 구현되어 있음

1. 프론트 컨트롤러 도입 - v1

프론트 컨트롤러를 단계적으로 도입해보자.
이번 목표는 기존 코드를 최대한 유지하면서, 프론트 컨트롤러를 도입하는 것이다.
먼저 구조를 맞추어두고 점진적으로 리펙터링 해보자.

2. View 분리 - v2

모든 컨트롤러에서 뷰로 이동하는 부분에 중복이 있고, 깔끔하지 않다.

String viewPath = "/WEB-INF/views/new-form.jsp";
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);

이 부분을 깔끔하게 분리하기 위해 별도로 뷰를 처리하는 객체(MyView)를 만들자.

3. Model 추가 - v3

서블릿 종속성 제거

컨트롤러 입장에서 HttpServletRequest, HttpServletResponse이 꼭 필요할까?
요청 파라미터 정보는 자바의 Map으로 대신 넘기도록 하면 지금 구조에서는 컨트롤러가 서블릿 기술을 몰라도 동작할 수 있다.
그리고 request 객체를 Model로 사용하는 대신에 별도의 Model 객체를 만들어서 반환하면 된다. 우리가 구현하는 컨트롤러가 서블릿 기술을 전혀 사용하지 않도록 변경해보자.
이렇게 하면 구현 코드도 매우 단순해지고, 테스트 코드 작성이 쉽다.

뷰 이름 중복 제거

컨트롤러에서 지정하는 뷰 이름에 중복이 있는 것을 확인할 수 있다.
컨트롤러는 뷰의 논리 이름을 반환하고, 실제 물리 위치의 이름은 프론트 컨트롤러에서 처리하도록 단순화 하자.
이렇게 해두면 향후 뷰의 폴더 위치가 함께 이동해도 프론트 컨트롤러만 고치면 된다.

/WEB-INF/views/new-form.jsp -> new-form
/WEB-INF/views/save-result.jsp -> save-result
/WEB-INF/views/members.jsp -> members

ModelView

지금까지 컨트롤러에서 서블릿에 종속적인 HttpServletRequest를 사용했다. 그리고 Model도 request.setAttribute() 를 통해 데이터를 저장하고 뷰에 전달했다.
서블릿의 종속성을 제거하기 위해 Model을 직접 만들고, 추가로 View 이름까지 전달하는 객체를 만들어보자.

(이번 버전에서는 컨트롤러에서 HttpServletRequest를 사용할 수 없다. 따라서 직접 request.setAttribute() 를 호출할 수 도 없다. 따라서 Model이 별도로 필요하다.)

뷰 리졸버

MyView view = viewResolver(viewName)

컨트롤러가 반환한 논리 뷰 이름을 실제 물리 뷰 경로로 변경한다. 그리고 실제 물리 경로가 있는 MyView 객체를 반환한다.
논리 뷰 이름: members
물리 뷰 경로: /WEB-INF/views/members.jsp

view.render(mv.getModel(), request, response)

뷰 객체를 통해서 HTML 화면을 렌더링 한다.
뷰 객체의 render() 는 모델 정보도 함께 받는다.
JSP는 request.getAttribute() 로 데이터를 조회하기 때문에, 모델의 데이터를 꺼내서 request.setAttribute() 로 담아둔다.
JSP로 포워드 해서 JSP를 렌더링 한다.

4. 단순하고 실용적인 컨트롤러 - v4

앞서 만든 v3 컨트롤러는 서블릿 종속성을 제거하고 뷰 경로의 중복을 제거하는 등, 잘 설계된 컨트롤러이다. 그런데 실제 컨트톨러 인터페이스를 구현하는 개발자 입장에서 보면, 항상 ModelView 객체를 생성하고 반환해야 하는 부분이 조금은 번거롭다.
좋은 프레임워크는 아키텍처도 중요하지만, 그와 더불어 실제 개발하는 개발자가 단순하고 편리하게 사용할 수 있어야 한다. 소위 실용성이 있어야 한다.

이번에는 v3를 조금 변경해서 실제 구현하는 개발자들이 매우 편리하게 개발할 수 있는 v4 버전을 개발해보자.

FrontControllerServletV4 는 사실 이전 버전과 거의 동일하다.

모델 객체 전달

Map<String, Object> model = new HashMap<>(); //추가
모델 객체를 프론트 컨트롤러에서 생성해서 넘겨준다. 컨트롤러에서 모델 객체에 값을 담으면 여기에 그대로 담겨있게 된다.

뷰의 논리 이름을 직접 반환 (ModelView -> String)

  String viewName = controller.process(paramMap, model);
  MyView view = viewResolver(viewName);

컨트롤로가 직접 뷰의 논리 이름을 반환하므로 이 값을 사용해서 실제 물리 뷰를 찾을 수 있다.

5. 유연한 컨트롤러 - v5

만약 어떤 개발자는 ControllerV3 방식으로 개발하고 싶고, 어떤 개발자는 ControllerV4 방식으로

개발하고 싶다면 어떻게 해야할까?

public interface ControllerV3 {
    ModelView process(Map<String, String> paramMap);
}

public interface ControllerV4 {
        String process(Map<String, String> paramMap, Map<String, Object> model);
}

어댑터 패턴

지금까지 우리가 개발한 프론트 컨트롤러는 한가지 방식의 컨트롤러 인터페이스만 사용할 수 있다. ControllerV3 , ControllerV4 는 완전히 다른 인터페이스이다. 따라서 호환이 불가능하다. 마치 v3는 110v이고, v4는 220v 전기 콘센트 같은 것이다. 이럴 때 사용하는 것이 바로 어댑터이다.
어댑터 패턴을 사용해서 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리할 수 있도록 변경해보자.

핸들러 어댑터: 중간에 어댑터 역할을 하는 어댑터가 추가되었는데 이름이 핸들러 어댑터이다. 여기서 어댑터 역할을 해주는 덕분에 다양한 종류의 컨트롤러를 호출할 수 있다.
핸들러: 컨트롤러의 이름을 더 넓은 범위인 핸들러로 변경했다. 그 이유는 이제 어댑터가 있기 때문에 꼭 컨트롤러의 개념 뿐만 아니라 어떠한 것이든 해당하는 종류의 어댑터만 있으면 다 처리할 수 있기 때문이다.

컨트롤러(Controller) -> 핸들러(Handler)
이전에는 컨트롤러를 직접 매핑해서 사용했다. 그런데 이제는 어댑터를 사용하기 때문에, 컨트롤러 뿐만 아니라 어댑터가 지원하기만 하면, 어떤 것이라도 URL에 매핑해서 사용할 수 있다. 그래서 이름을 컨트롤러에서 더 넒은 범위의 핸들러로 변경했다.

서블릿, JSP, MVC 패턴

zerone — Sat, 16 Jul 2022 15:44:14 +0900

1. 서블릿으로 회원 관리 웹 애플리케이션 만들기

MemberFormServlet 은 단순하게 회원 정보를 입력할 수 있는 HTML Form을 만들어서 응답한다. 자바 코드로 HTML을 제공해야 하므로 쉽지 않은 작업이다

템플릿 엔진으로

지금까지 서블릿과 자바 코드만으로 HTML을 만들어보았다. 서블릿 덕분에 동적으로 원하는 HTML을 마음껏 만들 수 있다. 정적인 HTML 문서라면 화면이 계속 달라지는 회원의 저장 결과라던가, 회원 목록 같은 동적인 HTML을 만드는 일은 불가능 할 것이다.
그런데, 코드에서 보듯이 이것은 매우 복잡하고 비효율 적이다. 자바 코드로 HTML을 만들어 내는 것 보다 차라리 HTML 문서에 동적으로 변경해야 하는 부분만 자바 코드를 넣을 수 있다면 더 편리할 것이다. 이것이 바로 템플릿 엔진이 나온 이유이다. 템플릿 엔진을 사용하면 HTML 문서에서 필요한 곳만 코드를 적용해서 동적으로 변경할 수 있다.

템플릿 엔진에는 JSP, Thymeleaf, Freemarker, Velocity등이 있다. 다음 시간에는 JSP로 동일한 작업을 진행해보자.

2. JSP로 회원 관리 웹 애플리케이션 만들기

서블릿과 JSP의 한계

서블릿으로 개발할 때는 뷰(View)화면을 위한 HTML을 만드는 작업이 자바 코드에 섞여서 지저분하고 복잡했다.
JSP를 사용한 덕분에 뷰를 생성하는 HTML 작업을 깔끔하게 가져가고, 중간중간 동적으로 변경이 필요한 부분에만 자바 코드를 적용했다. 그런데 이렇게 해도 해결되지 않는 몇가지 고민이 남는다.

회원 저장 JSP를 보자. 코드의 상위 절반은 회원을 저장하기 위한 비즈니스 로직이고, 나머지 하위 절반만 결과를 HTML로 보여주기 위한 뷰 영역이다. 회원 목록의 경우에도 마찬가지다. 코드를 잘 보면, JAVA 코드, 데이터를 조회하는 리포지토리 등등 다양한 코드가 모두 JSP에 노출되어 있다. JSP가 너무 많은 역할을 한다. 이렇게 작은 프로젝트도 벌써 머리가 아파오는데, 수백 수천줄이 넘어가는 JSP를 떠올려보면 정말 지옥과 같을 것이다. (유지보수 지옥 썰)

3. MVC 패턴의 등장

비즈니스 로직은 서블릿 처럼 다른곳에서 처리하고, JSP는 목적에 맞게 HTML로 화면(View)을 그리는 일에 집중하도록 하자. 과거 개발자들도 모두 비슷한 고민이 있었고, 그래서 MVC 패턴이 등장했다. 우리도 직접 MVC 패턴을 적용해서 프로젝트를 리팩터링 해보자.

MVC 패턴 - 개요

너무 많은 역할
하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리하게 되면, 너무 많은 역할을 하게되고, 결과적으로 유지보수가 어려워진다. 비즈니스 로직을 호출하는 부분에 변경이 발생해도 해당 코드를 손대야 하고, UI를 변경할 일이 있어도 비즈니스 로직이 함께 있는 해당 파일을 수정해야 한다. HTML 코드 하나 수정해야 하는데, 수백줄의 자바 코드가 함께 있다고 상상해보라! 또는 비즈니스 로직을 하나 수정해야 하는데 수백 수천줄의 HTML 코드가 함께 있다고 상상해보라.

변경의 라이프 사이클

사실 이게 정말 중요한데, 진짜 문제는 둘 사이에 변경의 라이프 사이클이 다르다는 점이다. 예를 들어서 UI 를 일부 수정하는 일과 비즈니스 로직을 수정하는 일은 각각 다르게 발생할 가능성이 매우 높고 대부분 서로에게 영향을 주지 않는다. 이렇게 변경의 라이프 사이클이 다른 부분을 하나의 코드로 관리하는 것은 유지보수하기 좋지 않다. (물론 UI가 많이 변하면 함께 변경될 가능성도 있다.)

기능 특화

특히 JSP 같은 뷰 템플릿은 화면을 렌더링 하는데 최적화 되어 있기 때문에 이 부분의 업무만 담당하는 것이 가장 효과적이다.

Model View Controller

MVC 패턴은 지금까지 학습한 것 처럼 하나의 서블릿이나, JSP로 처리하던 것을 컨트롤러(Controller)와 뷰(View)라는 영역으로 서로 역할을 나눈 것을 말한다. 웹 애플리케이션은 보통 이 MVC 패턴을 사용한다.

컨트롤러: HTTP 요청을 받아서 파라미터를 검증하고, 비즈니스 로직을 실행한다. 그리고 뷰에 전달할 결과 데이터를 조회해서 모델에 담는다.
모델: 뷰에 출력할 데이터를 담아둔다. 뷰가 필요한 데이터를 모두 모델에 담아서 전달해주는 덕분에 뷰는 비즈니스 로직이나 데이터 접근을 몰라도 되고, 화면을 렌더링 하는 일에 집중할 수 있다.
뷰: 모델에 담겨있는 데이터를 사용해서 화면을 그리는 일에 집중한다. 여기서는 HTML을 생성하는 부분을 말한다.

< 참고>

컨트롤러에 비즈니스 로직을 둘 수도 있지만, 이렇게 되면 컨트롤러가 너무 많은 역할을 담당한다. 그래서 일반적으로 비즈니스 로직은 서비스(Service)라는 계층을 별도로 만들어서 처리한다. 그리고 컨트롤러는 비즈니스 로직이 있는 서비스를 호출하는 역할을 담당한다. 참고로 비즈니스 로직을 변경하면 비즈니스 로직을 호출하는 컨트롤러의 코드도 변경될 수 있다. 앞에서는 이해를 돕기 위해 비즈니스 로직을 호출한다는 표현 보다는, 비즈니스 로직이라 설명했다.

MVC 패턴 - 한계
MVC 패턴을 적용한 덕분에 컨트롤러의 역할과 뷰를 렌더링 하는 역할을 명확하게 구분할 수 있다.
특히 뷰는 화면을 그리는 역할에 충실한 덕분에, 코드가 깔끔하고 직관적이다. 단순하게 모델에서 필요한 데이터를 꺼내고, 화면을 만들면 된다.
그런데 컨트롤러는 딱 봐도 중복이 많고, 필요하지 않는 코드들도 많이 보인다.

MVC 컨트롤러의 단점

1. 포워드 중복

View로 이동하는 코드가 항상 중복 호출되어야 한다. 물론 이 부분을 메서드로 공통화해도 되지만, 해당 메서드도 항상 직접 호출해야 한다.

  RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
  dispatcher.forward(request, response);

2. ViewPath에 중복

String viewPath = "/WEB-INF/views/new-form.jsp";

prefix: /WEB-INF/views/
suffix: .jsp

그리고 만약 jsp가 아닌 thymeleaf 같은 다른 뷰로 변경한다면 전체 코드를 다 변경해야 한다.

3. 사용하지 않는 코드

다음 코드를 사용할 때도 있고, 사용하지 않을 때도 있다. 특히 response는 현재 코드에서 사용되지 않는다.

  HttpServletRequest request, HttpServletResponse response

그리고 이런 HttpServletRequest , HttpServletResponse 를 사용하는 코드는 테스트 케이스를 작성하기도 어렵다.

4. 공통 처리가 어렵다.
기능이 복잡해질 수 록 컨트롤러에서 공통으로 처리해야 하는 부분이 점점 더 많이 증가할 것이다. 단순히 공통 기능을 메서드로 뽑으면 될 것 같지만, 결과적으로 해당 메서드를 항상 호출해야 하고, 실수로 호출하지 않으면 문제가 될 것이다. 그리고 호출하는 것 자체도 중복이다.

5. 정리하면 공통 처리가 어렵다는 문제가 있다.
이 문제를 해결하려면 컨트롤러 호출 전에 먼저 공통 기능을 처리해야 한다. 소위 수문장 역할을 하는 기능이 필요하다. 프론트 컨트롤러(Front Controller) 패턴을 도입하면 이런 문제를 깔끔하게 해결할 수 있다. (입구를 하나로!)
스프링 MVC의 핵심도 바로 이 프론트 컨트롤러에 있다.

서블릿

zerone — Sat, 16 Jul 2022 15:31:16 +0900

스프링부트 서블릿 등록, 사용

@ServletComponentScan

스프링 부트는 서블릿을 직접 등록해서 사용할 수 있도록 @ServletComponentScan 을 지원한다.
다음과 같이 추가하자.

@WebServlet

서블릿 애노테이션 name: 서블릿 이름 urlPatterns: URL 매핑

hello.servlet.ServletApplication

package hello.servlet;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.web.servlet.ServletComponentScan;

@ServletComponentScan //서블릿 자동 등록 
@SpringBootApplication
public class ServletApplication {
     public static void main(String[] args) {
        SpringApplication.run(ServletApplication.class, args);
	} 
}

hello.servlet.basic.HelloServlet

package hello.servlet.basic;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {
	@Override
	protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		System.out.println("HelloServlet.service");
        System.out.println("request = " + request);
        System.out.println("response = " + response);
        String username = request.getParameter("username");
        System.out.println("username = " + username);
        response.setContentType("text/plain");
        response.setCharacterEncoding("utf-8");
		response.getWriter().write("hello " + username);
	}
}

서블릿 컨테이너 동작방식

HttpServletRequest

HttpServletRequest 역할

HTTP 요청 메시지를 개발자가 직접 파싱해서 사용해도 되지만, 매우 불편할 것이다.
서블릿은 개발자가 HTTP 요청 메시지를 편리하게 사용할 수 있도록 개발자 대신에 HTTP 요청 메시지를 파싱한다.
그리고 그 결과를 HttpServletRequest 객체에 담아서 제공한다.

HttpServletRequest를 사용하면 다음과 같은 HTTP 요청 메시지를 편리하게 조회할 수 있다.

HTTP 요청 메시지

POST /save HTTP/1.1
Host: localhost:8080
Content-Type: application/x-www-form-urlencoded

username=kim&age=20

HttpServletRequest 개요

START LINE

HTTP 메소드
URL
쿼리 스트링
스키마, 프로토콜 헤더

헤더

헤더 조회

바디

form 파라미터 형식 조회
message body 데이터 직접 조회

HttpServletRequest 객체는 추가로 여러가지 부가기능도 함께 제공한다.

임시 저장소 기능

해당 HTTP 요청이 시작부터 끝날 때 까지 유지되는 임시 저장소 기능
- 저장: request.setAttribute(name, value)
- 조회: request.getAttribute(name)

세션 관리 기능

request.getSession(create: true)

HttpServletResponse

HttpServletResponse 역할

HTTP 응답 메시지 생성
HTTP 응답코드 지정 헤더 생성
바디 생성

편의 기능 제공

Content-Type, 쿠키, Redirect

HTML, HTTP API, CSR, SSR

zerone — Sun, 3 Jul 2022 00:10:15 +0900

정적 리소스

고정된 HTML 파일, CSS, JS, 이미지, 영상 등을 제공
주로 웹 브라우저

동적 리소스

1. HTML 페이지

동적으로 필요한 HTML 파일을 생성해서 전달
웹 브라우저: HTML 해석

2. HTTP API

HTML이 아니라 데이터를 전달
주로 JSON 형식 사용
다양한 시스템에서 호출
데이터만 주고 받음, UI 화면이 필요하면, 클라이언트가 별도 처리
주로 JSON 형태로 데이터 통신
UI 클라이언트 접점
앱 클라이언트(아이폰, 안드로이드, PC 앱)
웹 브라우저에서 자바스크립트를 통한 HTTP API 호출
React, Vue.js 같은 웹 클라이언트

3. 서버 to 서버

주문 서버 -> 결제 서버
기업간 데이터 통신

서버사이드 렌더링, 클라이언트 사이드 렌더링

SSR - 서버 사이드 렌더링

HTML 최종 결과를 서버에서 만들어서 웹 브라우저에 전달 주로 정적인 화면에 사용
관련기술: JSP, 타임리프 -> 백엔드 개발자

CSR - 클라이언트 사이드 렌더링

HTML 결과를 자바스크립트를 사용해 웹 브라우저에서 동적으로 생성해서 적용
주로 동적인 화면에 사용, 웹 환경을 마치 앱 처럼 필요한 부분부분 변경할 수 있음
예) 구글 지도, Gmail, 구글 캘린더
관련기술: React, Vue.js -> 웹 프론트엔드 개발자

참고

React, Vue.js를 CSR + SSR 동시에 지원하는 웹 프레임워크도 있음
SSR을 사용하더라도, 자바스크립트를 사용해서 화면 일부를 동적으로 변경 가능

동시요청 - 멀티 스레드

zerone — Sat, 2 Jul 2022 22:55:37 +0900

쓰레드

애플리케이션 코드를 하나하나 순차적으로 실행하는 것은 쓰레드
자바 메인 메서드를 처음 실행하면 main이라는 이름의 쓰레드가 실행
쓰레드가 없다면 자바 애플리케이션 실행이 불가능
쓰레드는 한번에 하나의 코드 라인만 수행
동시 처리가 필요하면 쓰레드를 추가로 생성

단일 요청 - 쓰레드 하나 사용

다중 요청 - 쓰레드 하나 사용

나중에 들어온 요청이 대기하게 된다. 동시 요청 처리 불가

요청 마다 쓰레드 사용

동시 요청을 처리할 수 있다.
장점
리소스(CPU, 메모리)가 허용할 때 까지 처리가능
하나의 쓰레드가 지연 되어도, 나머지 쓰레드는 정상 동작한다.
단점
쓰레드는 생성 비용은 매우 비싸다.
고객의 요청이 올 때 마다 쓰레드를 생성하면, 응답 속도가 늦어진다.
쓰레드는 컨텍스트 스위칭 비용이 발생한다.
쓰레드 생성에 제한이 없다.
고객 요청이 너무 많이 오면, CPU, 메모리 임계점을 넘어서 서버가 죽을 수 있다.

쓰레드 풀

필요한 쓰레드를 쓰레드 풀에 보관하고 관리한다.
특징
쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리한다.
톰캣은 최대 200개 기본 설정 (변경 가능)
사용
쓰레드가 필요하면, 이미 생성되어 있는 쓰레드를 쓰레드 풀에서 꺼내서 사용한다.
사용을 종료하면 쓰레드 풀에 해당 쓰레드를 반납한다.
최대 쓰레드가 모두 사용중이어서 쓰레드 풀에 쓰레드가 없으면? 기다리는 요청은 거절하거나 특정 숫자만큼만 대기하도록 설정할 수 있다.
장점
쓰레드가 미리 생성되어 있으므로, 쓰레드를 생성하고 종료하는 비용(CPU)이 절약되고, 응답 시간이 빠르다.
생성 가능한 쓰레드의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리할 수 있다.

실무 팁
WAS의 주요 튜닝 포인트는 최대 쓰레드(max thread) 수이다.
이 값을 너무 낮게 설정하면?
동시 요청이 많으면, 서버 리소스는 여유롭지만, 클라이언트는 금방 응답 지연
이 값을 너무 높게 설정하면?
동시 요청이 많으면, CPU, 메모리 리소스 임계점 초과로 서버 다운
장애 발생시?
클라우드면 일단 서버부터 늘리고, 이후에 튜닝 클라우드가 아니면 열심히 튜닝
성능 테스트
최대한 실제 서비스와 유사하게 성능, 테스트 시도 툴: 아파치 ab, 제이미터, nGrinder
멀티 쓰레드에 대한 부분은 WAS가 처리
개발자가 멀티 쓰레드 관련 코드를 신경쓰지 않아도 됨
개발자는 마치 싱글 쓰레드 프로그래밍을 하듯이 편리하게 소스 코드를 개발
멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)는 주의해서 사용

서블릿, 서블릿 컨테이너

zerone — Sun, 5 Jun 2022 14:48:32 +0900

서블릿

클라이언트의 요청을 처리하고, 그 결과를 반환하는 Servlet 클래스의 구현 규칙을 지킨 자바 웹 프로그래밍

개발자가 비즈니스 로직에 집중할 수 있도록 소켓 연결등의 잡일을 지원한다

@WebServlet(name = "helloServlet", urlPatterns = "/hello") 
public class HelloServlet extends HttpServlet {
    @Override protected void service(HttpServletRequest request, HttpServletResponse response){ 
    	//애플리케이션 로직 
    }
}

urlPatterns(/hello)의 URL 호출되면 서블릿 코드가 실행
HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest
HTTP 응답 정보를 편리하게 제공할 수 있는 HttpServletResponse
개발자는 HTTP 스펙을 매우 편리하게 사용

HTTP 요청시
WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체 호출
개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 꺼내서 사용
개발자는 Response 객체에 HTTP 응답 정보를 편리하게 입력
WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성

서블릿 컨테이너

톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함
서블릿 컨테이너는 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리
서블릿 객체는 싱글톤으로 관리
- 고객의 요청이 올 때 마다 계속 객체를 생성하는 것은 비효율
- 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용
- 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근
- 공유 변수 사용 주의
- 서블릿 컨테이너 종료시 함께 종료
JSP도 서블릿으로 변환 되어서 사용
동시 요청을 위한 멀티 쓰레드 처리 지원

웹 애플리케이션의 이해

zerone — Sun, 5 Jun 2022 13:41:36 +0900

웹 서버(Web Server)

HTTP 기반으로 동작
정적 리소스 제공, 기타 부가기능
정적(파일) HTML, CSS, JS, 이미지, 영상
예) NGINX, APACHE

웹 애플리케이션 서버(WAS - Web Application Server)

HTTP 기반으로 동작
웹 서버 기능 포함+ (정적 리소스 제공 가능)
프로그램 코드를 실행해서 애플리케이션 로직 수행
- 동적 HTML, HTTP API(JSON)
- 서블릿, JSP, 스프링 MVC
예) 톰캣(Tomcat) Jetty, Undertow

웹 서버, 웹 애플리케이션 서버(WAS) 차이

웹 서버는 정적 리소스(파일), WAS는 애플리케이션 로직 사실은 둘의 용어도 경계도 모호함
웹 서버도 프로그램을 실행하는 기능을 포함하기도 함
웹 애플리케이션 서버도 웹 서버의 기능을 제공함
자바는 서블릿 컨테이너 기능을 제공하면 WAS
서블릿 없이 자바코드를 실행하는 서버 프레임워크도 있음 WAS는 애플리케이션 코드를 실행하는데 더 특화

1. 웹 시스템 구성 - WAS, DB

WAS, DB 만으로 시스템 구성 가능
WAS는 정적 리소스, 애플리케이션 로직 모두 제공 가능

단점

WAS가 너무 많은 역할을 담당, 서버 과부하 우려
가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있음
WAS 장애시 오류 화면도 노출 불가능

2. 웹 시스템 구성 - WEB, WAS, DB ( 1 보다 좋다)

정적 리소스는 웹 서버가 처리
웹 서버는 애플리케이션 로직같은 동적인 처리가 필요하면 WAS에 요청을 위임
WAS는 중요한 애플리케이션 로직 처리 전담

장점

효율적인 리소스 관리
- 정적 리소스가 많이 사용되면 Web 서버 증설
- 애플리케이션 리소스가 많이 사용되면 WAS 증설
정적 리소스만 제공하는 웹 서버는 잘 죽지 않음 but, 애플리케이션 로직이 동작하는 WAS 서버는 잘 죽음
WAS, DB 장애시 WEB 서버가 오류 화면 제공 가능

빈 스코프

zerone — Sun, 22 May 2022 18:44:43 +0900

빈 스코프란?

빈이 존재할 수 있는 범위(기간)를 뜻한다.

싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다.
프로토타입: 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입, 초기화까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프이다.
웹 관련 스코프
request: 웹 요청이 들어오고 나갈때 까지 유지되는 스코프이다.
session: 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프이다.
application: 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프이다.

싱글톤과 프로토타입 빈 차이

1. 싱글톤 스코프의 빈을 스프링 컨테이너에 요청한다.
2. 스프링 컨테이너는 본인이 관리하는 스프링 빈을 반환한다.
3. 이후에 스프링 컨테이너에 같은 요청이 와도 같은 객체 인스턴스의 스프링 빈을 반환한다.

1. 프로토타입 스코프의 빈을 스프링 컨테이너에 요청한다.
2. 스프링 컨테이너는 이 시점에 프로토타입 빈을 생성하고, 필요한 의존관계를 주입한다.

3. 스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환한다.
4. 이후에 스프링 컨테이너에 같은 요청이 오면 항상 새로운 프로토타입 빈을 생성해서 반환한다.

*프로토타입 빈의 경우, 스프링 컨테이너에서 관리 안하므로 preDestroy같은 이벤트 발생안함!

프로토타입 스코프 - 싱글톤 빈과 함께 사용시 문제점

clientBean 은 싱글톤이므로, 보통 스프링 컨테이너 생성 시점에 함께 생성되고, 의존관계 주입도 발생한다.
1. clientBean 은 의존관계 자동 주입을 사용한다. 주입 시점에 스프링 컨테이너에 프로토타입 빈을 요청한다.

2. 스프링 컨테이너는 프로토타입 빈을 생성해서 clientBean 에 반환한다. 프로토타입 빈의 count 필드 값은 0이다.
이제 clientBean 은 프로토타입 빈을 내부 필드에 보관한다. (정확히는 참조값을 보관한다.)

클라이언트 A는 clientBean 을 스프링 컨테이너에 요청해서 받는다.싱글톤이므로 항상 같은 clientBean 이 반환된다.
3. 클라이언트 A는 clientBean.logic() 을 호출한다.
4. clientBean 은 prototypeBean의 addCount() 를 호출해서 프로토타입 빈의 count를 증가한다. count값이 1이 된다.

클라이언트 B는 clientBean 을 스프링 컨테이너에 요청해서 받는다.싱글톤이므로 항상 같은 clientBean 이 반환된다.
여기서 중요한 점이 있는데, clientBean이 내부에 가지고 있는 프로토타입 빈은 이미 과거에 주입이 끝난 빈이다. 주입 시점에 스프링 컨테이너에 요청해서 프로토타입 빈이 새로 생성이 된 것이지, 사용 할 때마다 새로 생성되는 것이 아니다!
5. 클라이언트 B는 clientBean.logic() 을 호출한다.
6. clientBean 은 prototypeBean의 addCount() 를 호출해서 프로토타입 빈의 count를 증가한다. 원래 count 값이 1이었으므로 2가 된다.

package hello.core.scope;

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Scope;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import static org.assertj.core.api.Assertions.*;

public class SingletonWithPrototypeTest1 {
    @Test
    void singletonClientUsePrototype() {
        AnnotationConfigApplicationContext ac = new
AnnotationConfigApplicationContext(ClientBean.class, PrototypeBean.class);
        ClientBean clientBean1 = ac.getBean(ClientBean.class);
        int count1 = clientBean1.logic();
        assertThat(count1).isEqualTo(1);
        ClientBean clientBean2 = ac.getBean(ClientBean.class);
        int count2 = clientBean2.logic();
        assertThat(count2).isEqualTo(2);
    }
    static class ClientBean {
        private final PrototypeBean prototypeBean;
        @Autowired
        public ClientBean(PrototypeBean prototypeBean) {
            this.prototypeBean = prototypeBean;
        }
        public int logic() {
            prototypeBean.addCount();
            int count = prototypeBean.getCount();
            return count;
        } 
    }
    @Scope("prototype")
    static class PrototypeBean {
        private int count = 0;
        public void addCount() {
            count++; 
        }
        public int getCount() {
             return count;
        }
        @PostConstruct
        public void init() {
             System.out.println("PrototypeBean.init " + this);
        }
        @PreDestroy
        public void destroy() {
            System.out.println("PrototypeBean.destroy");
        }
    } 
}

프로토타입 스코프 - 싱글톤 빈과 함께 사용시 Provider로 문제 해결

방안 1. Dependency Lookup (DL) 의존관계 조회(탐색) : 의존관계를 외부에서 주입(DI) 받는게 아니라 이렇게 직접 필요한 의존관계를 찾는 것

스프링 컨테이너에 의존
단위테스트 작성이 어렵다

@Autowired
private ApplicationContext ac;
public int logic() {
    PrototypeBean prototypeBean = ac.getBean(PrototypeBean.class);
    prototypeBean.addCount();
    int count = prototypeBean.getCount();
    return count;
}

더 나은 방안 2. ObjectFactory, ObjectProvider : 지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공하는 것

ObjectFactory + 편의기능 추가 -> ObjectProvider
스프링에 의존
기능이 단순하여 단위테스트 작성에 쉽다

@Autowired
private ObjectProvider<PrototypeBean> prototypeBeanProvider;
public int logic() {
    PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
    prototypeBean.addCount();
    int count = prototypeBean.getCount();
    return count;
}

더 나은 방안 3. JSR-330 Provider : javax.inject.Provider 라는 JSR-330 자바 표준 DL 서비스 제공

java 표준으로 스프링 의존 x
기능이 단순하여 단위테스트 작성에 쉽다

package javax.inject;
public interface Provider<T> {
      T get(); 
}

/implementation 'javax.inject:javax.inject:1' gradle 추가 필수 
@Autowired
private Provider<PrototypeBean> provider;

public int logic() {
      PrototypeBean prototypeBean = provider.get();
      prototypeBean.addCount();
      int count = prototypeBean.getCount();
      return count;
}

웹 스코프

웹 스코프의 특징

웹 스코프는 웹 환경에서만 동작한다.
웹 스코프는 프로토타입과 다르게 스프링이 해당 스코프의 종료시점까지 관리한다. 따라서 종료 메서드가 호출된다.

request 스코프 예제

웹 환경 추가 - build.gradle

//web 라이브러리 추가
implementation 'org.springframework.boot:spring-boot-starter-web'

spring-boot-starter-web 라이브러리를 추가하면 스프링 부트는 내장 톰켓 서버를 활용해서 웹 서버와 스프링을 함께 실행시킨다.

스프링 부트는 웹 라이브러리가 없으면 우리가 지금까지 학습한 AnnotationConfigApplicationContext 을 기반으로 애플리케이션을 구동한다. 웹 라이브러리가 추가되면 웹과 관련된 추가 설정과 환경들이 필요하므로
AnnotationConfigServletWebServerApplicationContext 를 기반으로 애플리케이션을 구동한다.

package hello.core.common;

import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import java.util.UUID;
@Component
@Scope(value = "request")
public class MyLogger {
    private String uuid;
    private String requestURL;
    public void setRequestURL(String requestURL) {
        this.requestURL = requestURL;
    }
    public void log(String message) {
        System.out.println("[" + uuid + "]" + "[" + requestURL + "] " + message); 
    }
    @PostConstruct
    public void init() {
        uuid = UUID.randomUUID().toString();
        System.out.println("[" + uuid + "] request scope bean create:" + this);
    }
    @PreDestroy
    public void close() {
        System.out.println("[" + uuid + "] request scope bean close:" + this);
    }
}

  package hello.core.web;
  import hello.core.common.MyLogger;
  import hello.core.logdemo.LogDemoService;
  import lombok.RequiredArgsConstructor;
  import org.springframework.stereotype.Controller;
  import org.springframework.web.bind.annotation.RequestMapping;
  import org.springframework.web.bind.annotation.ResponseBody;
  import javax.servlet.http.HttpServletRequest;
  @Controller
  @RequiredArgsConstructor
  public class LogDemoController {
           private final LogDemoService logDemoService;
        private final MyLogger myLogger;
        @RequestMapping("log-demo")
        @ResponseBody
        public String logDemo(HttpServletRequest request) {
            String requestURL = request.getRequestURL().toString();
            myLogger.setRequestURL(requestURL);
            myLogger.log("controller test");
            logDemoService.logic("testId");
            return "OK";
} }

package hello.core.logdemo;
    import hello.core.common.MyLogger;
    import lombok.RequiredArgsConstructor;
    import org.springframework.stereotype.Service;
       @Service
  @RequiredArgsConstructor
  public class LogDemoService {
      private final MyLogger myLogger;
      public void logic(String id) {
          myLogger.log("service id = " + id);
} }

스프링 애플리케이션을 실행하는 시점에 싱글톤 빈은 생성해서 주입이 가능하지만, request 스코프 빈은 아직 생성되지 않는다. 이 빈은 실제 고객의 요청이 와야 생성할 수 있다!

<Provider를 사용한 LogDemoService>

package hello.core.logdemo;
  import hello.core.common.MyLogger;
  import lombok.RequiredArgsConstructor;
  import org.springframework.beans.factory.ObjectProvider;
  import org.springframework.stereotype.Service;
  @Service
  @RequiredArgsConstructor
  public class LogDemoService {
      private final ObjectProvider<MyLogger> myLoggerProvider;
      public void logic(String id) {
          MyLogger myLogger = myLoggerProvider.getObject();
          myLogger.log("service id = " + id);
} }

<프록시를 사용한 myLogger>

 @Component
  @Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
  public class MyLogger {
  }

proxyMode = ScopedProxyMode.TARGET_CLASS 를 추가.

적용 대상이 인터페이스가 아닌 클래스면 TARGET_CLASS 를 선택
적용 대상이 인터페이스면 INTERFACES 를 선택

이렇게 하면 MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있다.

CGLIB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.

동작 정리

CGLIB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.
이 가짜 프록시 객체는 실제 요청이 오면 그때 내부에서 실제 빈을 요청하는 위임 로직이 들어있다.
가짜 프록시 객체는 실제 request scope와는 관계가 없다. 그냥 가짜이고, 내부에 단순한 위임 로직만 있고, 싱글톤 처럼 동작한다.

특징 정리

프록시 객체 덕분에 클라이언트는 마치 싱글톤 빈을 사용하듯이 편리하게 request scope를 사용할 수 있다.
사실 Provider를 사용하든, 프록시를 사용하든 핵심 아이디어는 진짜 객체 조회를 꼭 필요한 시점까지 지연처리 한다는 점이다.
단지 애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있다. 이것이 바로 다형성과 DI 컨테이너가 가진 큰 강점이다.
꼭 웹 스코프가 아니어도 프록시는 사용할 수 있다.

주의점

마치 싱글톤을 사용하는 것 같지만 다르게 동작하기 때문에 결국 주의해서 사용해야 한다.
이런 특별한 scope는 꼭 필요한 곳에만 최소화해서 사용하자, 무분별하게 사용하면 유지보수하기 어려워진다.

빈 생명주기 콜백

zerone — Sat, 7 May 2022 14:21:52 +0900

스프링 빈의 이벤트 라이프사이클

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 종료

* 생성자 주입의 경우, 스프링 빈 생성될 때 주입 발생

스프링은 크게 3가지 방법으로 빈 생명주기 콜백을 지원한다.

인터페이스(InitializingBean, DisposableBean)

package hello.core.lifecycle;

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;

public class NetworkClient implements InitializingBean, DisposableBean {
    private String url;

	public NetworkClient() { System.out.println("생성자 호출, url = " + url); }
    
    public void setUrl(String url) { this.url = url; }

	//서비스 시작시 호출
    public void connect() {
        System.out.println("connect: " + url);
    }
    
    public void call(String message) {
        System.out.println("call: " + url + " message = " + message);
    }
    
	//서비스 종료시 호출
    public void disConnect() {
        System.out.println("close + " + url);
    }
    
    @Override
    public void afterPropertiesSet() throws Exception {
    	connect();
        call("초기화 연결 메시지");
    }
    
    @Override
    public void destroy() throws Exception {
    	disConnect();
    }
}

설정 정보에 초기화 메서드, 종료 메서드 지정

package hello.core.lifecycle;

public class NetworkClient {

    private String url;

    public NetworkClient() {
        System.out.println("생정자 호출, url = " + url);
    }

    public void setUrl(String url) {
        this.url = url;
    }

    // 서비스 시작시 호출
    public void connect() {
        System.out.println("connect: " + url);
    }

    public void call(String message) {
        System.out.println("call: " + url + " message = " + message);
    }

    // 서비스 종료시 호출
    public void disconnect() {
        System.out.println("close: " + url);
    }

    public void init() {
        System.out.println("NetworkClient.init");
        connect();
        call("초기화 연결 메시지");
    }

    public void close() throws Exception {
        System.out.println("NetworkClient.close");
        disconnect();
    }
}

@Configuration
static class LifeCycleConfig {
    @Bean(initMethod = "init", destroyMethod = "close")
    public NetworkClient networkClient() {
        NetworkClient networkClient = new NetworkClient();
        networkClient.setUrl("http://hello-spring.dev");
        return networkClient;
    }
}

@PostConstruct, @PreDestroy 애노테이션 지원(권장)

package lifecycle;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

public class NetworkClient {

    private String url;

    public NetworkClient() {
        System.out.println("생정자 호출, url = " + url);
    }

    public void setUrl(String url) {
        this.url = url;
    }

    // 서비스 시작시 호출
    public void connect() {
        System.out.println("connect: " + url);
    }

    public void call(String message) {
        System.out.println("call: " + url + " message = " + message);
    }

    // 서비스 종료시 호출
    public void disconnect() {
        System.out.println("close: " + url);
    }

    @PostConstruct
    public void init() {
        System.out.println("NetworkClient.init");
        connect();
        call("초기화 연결 메시지");
    }

    @PreDestroy
    public void close() throws Exception {
        System.out.println("NetworkClient.close");
        disconnect();
    }
}

의존관계 자동 주입

zerone — Sat, 23 Apr 2022 17:41:53 +0900

다양한 의존관계 주입(@Autowired) 방법

생성자 주입
수정자 주입(setter 주입)
필드 주입
일반 메서드 주입

참고: @Autowired 의 기본 동작은 주입할 대상이 없으면 오류가 발생한다. 주입할 대상이 없어도 동작하게 하려면 @Autowired(required = false) 로 지정하면 된다.

생성자 주입

생성자 호출시점에 딱 1번만 호출되는 것이 보장된다.
불변, 필수 의존관계에 사용
중요! 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입 된다. 물론 스프링 빈에만 해당한다.

수정자 주입(setter 주입)

선택, 변경 가능성이 있는 의존관계에 사용
자바빈 프로퍼티 규약의 수정자 메서드 방식을 사용하는 방법이다.

필드 주입

코드가 간결해서 많은 개발자들을 유혹하지만 외부에서 변경이 불가능해서 테스트 하기 힘들다는 치명적인 단점이 있다.
DI 프레임워크가 없으면 아무것도 할 수 없다.
사용하지 말자!
애플리케이션의 실제 코드와 관계 없는 테스트 코드 또는 스프링 설정을 목적으로 하는 @Configuration 같은 곳에서만 특별한 용도로 사용

일반 메서드 주입

한번에 여러 필드를 주입 받을 수 있다.
일반적으로 잘 사용하지 않는다.

자동 주입 대상 옵션처리

@Autowired(required=false) : 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 안됨
org.springframework.lang.@Nullable : 자동 주입할 대상이 없으면 null이 입력된다.
Optional<> : 자동 주입할 대상이 없으면 Optional.empty 가 입력된다.

//호출 안됨
@Autowired(required = false)
public void setNoBean1(Member member) {
        System.out.println("setNoBean1 = " + member);
    }
//null 호출
@Autowired
public void setNoBean2(@Nullable Member member) {
        System.out.println("setNoBean2 = " + member);
    }
//Optional.empty 호출
@Autowired(required = false)
public void setNoBean3(Optional<Member> member) {
        System.out.println("setNoBean3 = " + member);
    }

결론 : 주입방식은 생성자 주입을 선택하라

불변

대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료시점까지 의존관계를 변경할 일이 없다. 오히려 대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안된다.(불변해야 한다.)
수정자 주입을 사용하면, setXxx 메서드를 public으로 열어두어야 한다.
누군가 실수로 변경할 수 도 있고, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아니다. 생성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 이후에 호출되는 일이 없다. 따라서 불변하게 설계할 수 있다.

누락

프레임워크 없이 순수한 자바 코드를 단위 테스트 하는 경우에 생성자 주입을 사용하면 컴파일 오류가 발생한다. -> 실행하기 전에 오류 캐치가능

롬복과 최신 트랜드

롬복 라이브러리가 제공하는 @RequiredArgsConstructor 기능을 사용하면 final이 붙은 필드를 모아서 생성자를 자동으로 만들어준다. (다음 코드에는 보이지 않지만 실제 호출 가능하다.)

 @Component
 @RequiredArgsConstructor
 public class OrderServiceImpl implements OrderService {
      private final MemberRepository memberRepository;
      private final DiscountPolicy discountPolicy;
}

class 파일에서 밑에 코드 추가된다.

public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy
  discountPolicy) {
      this.memberRepository = memberRepository;
      this.discountPolicy = discountPolicy;
  }

롬복을 이용하면 코드가 깔끔해진다.

조회 빈이 2개 이상 - 문제

 @Autowired
  private DiscountPolicy discountPolicy

@Component
  public class FixDiscountPolicy implements DiscountPolicy {}

@Component
  public class RateDiscountPolicy implements DiscountPolicy {}

결과 : 에러

  NoUniqueBeanDefinitionException: No qualifying bean of type
  'hello.core.discount.DiscountPolicy' available: expected single matching bean
  but found 2: fixDiscountPolicy,rateDiscountPolicy

해결방법

1. @Autowired 필드 명 매칭 (필드 명을 빈 이름으로 변경)

  @Autowired
  private DiscountPolicy rateDiscountPolicy

@Autowired 매칭 정리
1) 타입 매칭
2) 타입 매칭의 결과가 2개 이상일 때 필드 명, 파라미터 명으로 빈 이름 매칭

2. @Qualifier 사용
@Qualifier 는 추가 구분자를 붙여주는 방법이다. 주입시 추가적인 방법을 제공하는 것이지 빈 이름을 변경하는 것은 아니다

<빈 등록시 @Qualifier 붙임>

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}

<자동주입>

  @Autowired
  public OrderServiceImpl(MemberRepository memberRepository,
                          @Qualifier("mainDiscountPolicy") DiscountPolicy
  discountPolicy) {
      this.memberRepository = memberRepository;
      this.discountPolicy = discountPolicy;
}

@Qualifier 로 주입할 때 @Qualifier("mainDiscountPolicy") 를 못찾으면 어떻게 될까?

@Qualifier 정리
1) @Qualifier끼리 매칭
2) 빈 이름 매칭
3) NoSuchBeanDefinitionException 예외 발생

3. @Primary 사용

@Primary 는 우선순위를 정하는 방법이다. @Autowired 시에 여러 빈이 매칭되면 @Primary 가 우선권을 가진다

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

@Primary, @Qualifier 활용

메인 데이터베이스 커넥션을 획득하는 스프링 빈 - @Primary
서브 데이터베이스 커넥션을 획득하는 스프링 빈 - @Qualifier

우선순위

@Qualifer(상세) > @Primary(넓음)

애너테이션 직접 만들기

@Qualifier("mainDiscountPolicy") 이렇게 문자를 적으면 컴파일시 타입 체크가 안된다. 다음과 같은 애노테이션을 만들어서 문제를 해결할 수 있다.

package hello.core.annotataion;
import org.springframework.beans.factory.annotation.Qualifier;
import java.lang.annotation.*;
@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER,
ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Qualifier("mainDiscountPolicy")
public @interface MainDiscountPolicy {
}

@Component
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy {}

//생성자 자동 주입
@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
                          @MainDiscountPolicy DiscountPolicy discountPolicy) {
      this.memberRepository = memberRepository;
      this.discountPolicy = discountPolicy;
}
//수정자 자동 주입
@Autowired
public DiscountPolicy setDiscountPolicy(@MainDiscountPolicy DiscountPolicy discountPolicy) {
      return discountPolicy;
}

애노테이션에는 상속이라는 개념이 없다.
이렇게 여러 애노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능이다.-->???
@Qulifier 뿐만 아니라 다른 애노테이션들도 함께 조합해서 사용할 수 있다. 단적으로 @Autowired도 재정의 할 수 있다. 물론 스프링이 제공하는 기능을 뚜렷한 목적 없이 무분별하게 재정의 하는 것은 유지보수에 더 혼란만 가중할 수 있다.

조회한 빈이 모두 필요할 때, List, Map

public class AllBeanTest {
    @Test
    void findAllBean() {
    	// 컴포넌트 스캔(AutoAppConfig)으로 등록한 빈들을 DiscountService에 저장
          ApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);
          DiscountService discountService = ac.getBean(DiscountService.class);
          Member member = new Member(1L, "userA", Grade.VIP);
          int discountPrice = discountService.discount(member, 10000, "fixDiscountPolicy");
          assertThat(discountService).isInstanceOf(DiscountService.class);
          assertThat(discountPrice).isEqualTo(1000);
    }
    static class DiscountService {
    	private final Map<String, DiscountPolicy> policyMap;
        private final List<DiscountPolicy> policies;
        public DiscountService(Map<String, DiscountPolicy> policyMap, List<DiscountPolicy> policies) {
            this.policyMap = policyMap;
            this.policies = policies;
            System.out.println("policyMap = " + policyMap);
            System.out.println("policies = " + policies);
        }
        public int discount(Member member, int price, String discountCode) {
        	DiscountPolicy discountPolicy = policyMap.get(discountCode);
            System.out.println("discountCode = " + discountCode);
            System.out.println("discountPolicy = " + discountPolicy);
            return discountPolicy.discount(member, price);
        }
    }
}

주입 분석

Map<String, DiscountPolicy> : map의 키에 스프링 빈의 이름을 넣어주고, 그 값으로 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.
List<DiscountPolicy> : DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.
만약 해당하는 타입의 스프링 빈이 없으면, 빈 컬렉션이나 Map을 주입한다.

자동, 수동의 올바른 실무 운영 기준

편리한 자동 기능을 기본으로 사용하자.

업무 로직 빈: 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리등이 모두 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다. -> 잘 적용되는지 파악하기 어렵다. 자동 빈 등록
기술 지원 빈: 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다. 데이터베이스 연결이나, 공통 로그 처리 처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술들이다 -> 잘 적용되는지 파악하기 어렵다. 수동 빈 등록이 유지보수에 좋다

비즈니스 로직 중에서 다형성을 적극 활용할 때

의존관계 자동 주입 - 조회한 빈이 모두 필요할 때, List, Map을 다시 보자.
DiscountService 가 의존관계 자동 주입으로 Map<String, DiscountPolicy> 에 주입을 받는 상황을 생각해보자. 여기에 어떤 빈들이 주입될 지, 각 빈들의 이름은 무엇일지 코드만 보고 한번에 쉽게 파악할 수 있을까?

이런 경우 수동 빈으로 등록하거나 또는 자동으로하면 특정 패키지에 같이 묶어두는게 좋다! 핵심은 딱 보고 이해가 되어야 한다!

@Configuration
  public class DiscountPolicyConfig {
      @Bean
      public DiscountPolicy rateDiscountPolicy() {
          return new RateDiscountPolicy();
      }
      @Bean
      public DiscountPolicy fixDiscountPolicy() {
          return new FixDiscountPolicy();
      }
}

[Java] Collection 정렬

zerone — Sun, 3 Apr 2022 22:57:43 +0900

Collection.sort를 하기위해선 class 내에 Comparator나 comparable<T>를 구현해야 한다.

즉, compareTo 메서드를 오버라이딩 해야한다.

    @Override
    public int compareTo(Student o) {
    	// 구현
    }

이 때, 어떤 기준으로 1, 0, -1을 리턴해줘야 하는지 자주 헷갈려서 소스를 분석했다.

    public static <T extends Comparable<? super T>> void sort(List<T> list) {
        list.sort(null);
    }

Collections.sort()도 결국은 Array로 변환해 Arrays.sort를 호출한다

    default void sort(Comparator<? super E> c) {
        Object[] a = this.toArray();
        Arrays.sort(a, (Comparator) c);
        ListIterator<E> i = this.listIterator();
        for (Object e : a) {
            i.next();
            i.set((E) e);
        }
    }

Comparator가 있을 경우, LegacyMergerSort.userRequested 는 false로 TimSort를 수행한다

    public static <T> void sort(T[] a, Comparator<? super T> c) {
        if (c == null) {
            sort(a);
        } else {
            if (LegacyMergeSort.userRequested)
                legacyMergeSort(a, c);
            else
                TimSort.sort(a, 0, a.length, c, null, 0, 0);
        }
    }

Comparator가 없을 경우, LegacyMergerSort.userRequested 는 false로 ComparableTimSort를 수행한다

    public static void sort(Object[] a) {
        if (LegacyMergeSort.userRequested)
            legacyMergeSort(a);
        else
            ComparableTimSort.sort(a, 0, a.length, null, 0, 0);
    }

Comparartor가 있던 없던, TimSort과 ComparableTimSort 내부에서 countRunAndMakeAscending, binarySort를 실행한다.

    static <T> void sort(T[] a, int lo, int hi, Comparator<? super T> c,
                         T[] work, int workBase, int workLen) {
        assert c != null && a != null && lo >= 0 && lo <= hi && hi <= a.length;

        int nRemaining  = hi - lo;
        if (nRemaining < 2)
            return;  // Arrays of size 0 and 1 are always sorted

        // If array is small, do a "mini-TimSort" with no merges
        if (nRemaining < MIN_MERGE) {
            int initRunLen = countRunAndMakeAscending(a, lo, hi, c);
            binarySort(a, lo, hi, lo + initRunLen, c);
            return;
        }

        /**
         * March over the array once, left to right, finding natural runs,
         * extending short natural runs to minRun elements, and merging runs
         * to maintain stack invariant.
         */
        TimSort<T> ts = new TimSort<>(a, c, work, workBase, workLen);
        int minRun = minRunLength(nRemaining);
        do {
            // Identify next run
            int runLen = countRunAndMakeAscending(a, lo, hi, c);

            // If run is short, extend to min(minRun, nRemaining)
            if (runLen < minRun) {
                int force = nRemaining <= minRun ? nRemaining : minRun;
                binarySort(a, lo, lo + force, lo + runLen, c);
                runLen = force;
            }

            // Push run onto pending-run stack, and maybe merge
            ts.pushRun(lo, runLen);
            ts.mergeCollapse();

            // Advance to find next run
            lo += runLen;
            nRemaining -= runLen;
        } while (nRemaining != 0);

        // Merge all remaining runs to complete sort
        assert lo == hi;
        ts.mergeForceCollapse();
        assert ts.stackSize == 1;
    }

여기서 compareTo가 실행된다.

    private static int countRunAndMakeAscending(Object[] a, int lo, int hi) {
        assert lo < hi;
        int runHi = lo + 1;
        if (runHi == hi)
            return 1;

        // Find end of run, and reverse range if descending
        if (((Comparable) a[runHi++]).compareTo(a[lo]) < 0) { // Descending
            while (runHi < hi && ((Comparable) a[runHi]).compareTo(a[runHi - 1]) < 0)
                runHi++;
            reverseRange(a, lo, runHi);
        } else {                              // Ascending
            while (runHi < hi && ((Comparable) a[runHi]).compareTo(a[runHi - 1]) >= 0)
                runHi++;
        }

        return runHi - lo;
    }

즉, compareTo는 이전 배열원소들이랑 비교하여 0보다 작은 값을 return하면 자리를 스왑한다!!!

컴포넌트 스캔

zerone — Sun, 3 Apr 2022 19:02:25 +0900

스프링은 자바코드의 @Bean이나 XML의 <bean> 같은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 @ComponentScan이라는 기능을 제공한다.

또, 의존관계도 자동으로 주입하는 @Autowired라는 기능도 제공한다.

package hello.core;
    
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.FilterType;
import static org.springframework.context.annotation.ComponentScan.*;

@Configuration
@ComponentScan(
        excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = Configuration.class))
public class AutoAppConfig {

}

@ComponentScan은 @Component애노테이션이 붙은 클래스를 스캔해서 스프링 빈으로 등록한다.

참고로, @Component를 상속(스프링이 지원하는 기능)받는 @Configuration과 같은 애노테션이 붙은 클래스도 같이 등록된다.

@Component
public class MemberServiceImpl implements MemberService {
	private final MemberRepository memberRepository;
    @Autowired
    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
}

@Autowired 는 의존관계를 자동으로 주입해준다

컴포넌트 스캔과 자동 의존관계 주입 동작 단계

1. @ComponentScan

@ComponentScan 은 @Component 가 붙은 모든 클래스를 스프링 빈으로 등록한다.
이때 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용한다.

빈 이름 기본 전략: MemberServiceImpl 클래스 memberServiceImpl
빈 이름 직접 지정: 만약 스프링 빈의 이름을 직접 지정하고 싶으면 @Component("memberService2") 이런식으로 이름을 부여하면 된다.

2. @Autowired 의존관계 자동 주입

생성자에 @Autowired 를 지정하면, 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입한다.
이때 기본 조회 전략은 타입이 같은 빈을 찾아서 주입한다.
getBean(MemberRepository.class) 와 동일하다고 이해하면 된다.

생성자에 파라미터가 많아도 다 찾아서 자동으로 주입한다.

탐색 위치와 기본 스캔 대상

탐색할 패키지의 시작 위치 지정

@ComponentScan(
          basePackages = "hello.core", "hello.service"
}

basePackages = {"hello.core", "hello.service"} 이렇게 여러 시작 위치를 지정할 수도 있다.
만약 지정하지 않으면 @ComponentScan 이 붙은 설정 정보 클래스의 패키지가 시작 위치가 된다.

권장하는 방법

개인적으로 즐겨 사용하는 방법은 패키지 위치를 지정하지 않고, 설정 정보 클래스의 위치를 프로젝트 최상단에 두는 것이다. 최근 스프링 부트도 이 방법을 기본으로 제공한다.

컴포넌트 스캔 기본 대상

@Component : 컴포넌트 스캔에서 사용
@Controlller : 스프링 MVC 컨트롤러에서 사용, 스프링 MVC 컨트롤러로 인식
@Service : 스프링 비즈니스 로직에서 사용, 특별한 처리 없음, 개발자들이 핵심 비즈니스 로직이 여기 있껬구나 인식하는데 도움
@Repository : 스프링 데이터 접근 계층에서 사용, 스프링 데이터 접근 계층으로 인식하고 데이터 계층의 예외를 스프링 예외로 변환
@Configuration : 스프링 설정 정보에서 사용

필터

useDefaultFilters : 옵션은 기본으로 켜져있는데, 이 옵션을 끄면 기본 스캔 대상들이 제외된다.
includeFilters : 컴포넌트 스캔 대상을 추가로 지정한다.
excludeFilters : 컴포넌트 스캔에서 제외할 대상을 지정한다.

 @ComponentScan(
    includeFilters = @Filter(type = FilterType.ANNOTATION, classes = MyIncludeComponent.class),
    excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = MyExcludeComponent.class)
  )

FilterType

ANNOTATION: 기본값, 애노테이션을 인식해서 동작한다.
ex) org.example.SomeAnnotation
ASSIGNABLE_TYPE: 지정한 타입과 자식 타입을 인식해서 동작한다.
ex) org.example.SomeClass
ASPECTJ: AspectJ 패턴 사용
ex) org.example..*Service+
REGEX: 정규 표현식
ex) org\.example\.Default.*
CUSTOM: TypeFilter 이라는 인터페이스를 구현해서 처리
ex) org.example.MyTypeFilter

중복 등록과 충돌

컴포넌트 스캔에서 같은 빈 이름을 등록하면 어떻게 될까? 다음 두가지 상황이 있다.

자동 빈 등록 vs 자동 빈 등록
컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록되는데, 그 이름이 같은 경우 스프링은 오류를 발생시킨다.
ConflictingBeanDefinitionException 예외 발생
수동 빈 등록 vs 자동 빈 등록
수동 빈 우선권 (스프링은 명시적인 것을 우선하는 경향이 있다) -> 최근에는 스프링 부트 에러 발생시킨다.

싱글톤 컨테이너

zerone — Sat, 2 Apr 2022 23:15:20 +0900

순수 자바를 이용한 AppConfig의 문제점

우리가 만들었던 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때 마다 객체를 새로 생성한다.
고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸된다! 메모리 낭비가 심하다.
해결방안은 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다. => 싱글톤 패턴

싱글톤 패턴

클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다.

그래서 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다.

- private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다.

package hello.core.singleton;

public class SingletonService {
	//1. static 영역에 객체를 딱 1개만 생성해둔다.
	private static final SingletonService instance = new SingletonService();
	
    //2. public으로 열어서 객체 인스터스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용한다.
    public static SingletonService getInstance() {
    	return instance;
	}
  	//3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다. 
    private SingletonService() {
	}
	public void logic() { System.out.println("싱글톤 객체 로직 호출");
}

싱글톤 패턴 문제점

싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
의존관계상 클라이언트가 구체 클래스에 의존한다.
DIP를 위반한다.
클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
테스트하기 어렵다.
내부 속성을 변경하거나 초기화 하기 어렵다.
private 생성자로 자식 클래스를 만들기 어렵다.
결론적으로 유연성이 떨어진다.
안티패턴으로 불리기도 한다.

싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다.
스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.
스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.
스프링 컨테이너의 이런 기능 덕분에 싱글턴 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.
싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.
DIP, OCP, 테스트, private 생성자로 부터 자유롭게 싱글톤을 사용할 수 있다.

싱글톤 방식의 주의점

싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너를 사용하든, 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다. 즉, 무상태(stateless)로 설계해야 한다!

특정 클라이언트에 의존적인 필드가 있으면 안된다.
특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다!
가급적 읽기만 가능해야 한다.
필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터 ThreadLocal 등을 사용해야 한다.

스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다!!

그럼에도 불가피하게 사용해야 될 경우는? 옵션을 제공한다.

@Configuration과 싱글톤

 @Configuration
  public class AppConfig {
      @Bean
      public MemberService memberService() {
          return new MemberServiceImpl(memberRepository());
      }
      @Bean
      public OrderService orderService() {
          return new OrderServiceImpl(
                  memberRepository(),
                  discountPolicy());
}
      @Bean
      public MemberRepository memberRepository() {
          return new MemoryMemberRepository();
      }
... }

memberService 빈을 만드는 코드를 보면 memberRepository() 를 호출한다. 이 메서드를 호출하면 new MemoryMemberRepository() 를 호출한다. orderService 빈을 만드는 코드도 동일하게 memberRepository() 를 호출한다. 이 메서드를 호출하면 new MemoryMemberRepository() 를 호출한다.

결과적으로 각각 다른 2개의 MemoryMemberRepository 가 생성되면서 싱글톤이 깨지는 것 처럼 보인다. 아무리 스프링 컨테이너라지만 자바의 문법을 바꿀 순 없다. 스프링 컨테이너는 이 문제를 어떻게 해결할까?

@Configuration과 바이트코드 조작의 마법

스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다.
모든 비밀은 @Configuration 을 적용한 AppConfig 에 있다.

사실 AnnotationConfigApplicationContext 에 파라미터로 넘긴 값은 스프링 빈으로 등록된다. 그래서 AppConfig 도 스프링 빈이 된다.

AppConfig 스프링 빈을 조회해서 클래스 정보를 출력해보자.

@Test
void configurationDeep() {
    ApplicationContext ac = new
	AnnotationConfigApplicationContext(AppConfig.class);
	
    //AppConfig도 스프링 빈으로 등록된다.
	AppConfig bean = ac.getBean(AppConfig.class);
	
    System.out.println("bean = " + bean.getClass());
    //출력: bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70
}

순수한 클래스라면 다음과 같이 출력되어야 한다.

// class hello.core.AppConfig

그런데 예상과는 다르게 클래스 명에 xxxCGLIB가 붙으면서 상당히 복잡해진 것을 볼 수 있다. 이것은 내가 만든 클래스가 아니라 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것이다!

AppConfig@CGLIB 예상 코드

@Bean
public MemberRepository memberRepository() {
    if (memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으면?) { 
    	return 스프링 컨테이너에서 찾아서 반환;
	} else { //스프링 컨테이너에 없으면
		기존 로직을 호출해서 MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록 return 반환
	} 
}

@Configuration이 없으면 싱글톤 보장하지 않는다!

스프링 컨테이너와 스프링 빈

zerone — Sat, 2 Apr 2022 19:40:07 +0900

스프링 컨테이너의 생성 과정

1. 스프링 컨테이너 생성

구성정보(AppConfig.class) 지정이 필요하다.

2. 스프링 빈 등록

빈 이름은 메서드 이름을 사용한다

빈 이름을 직접 부여할 수도 있다.

생성자 주입의 경우 객체를 만들어야 하므로, 이 단계에서 주입이된다.

주의: 빈 이름은 항상 다른 이름을 부여해야 한다. 같은 이름을 부여하면, 다른 빈이 무시되거나, 기존 빈을 덮어버리거나 설정에 따라 오류가 발생한다

3. 스프링 빈 의존관계 설정 - 준비

4. 스프링 빈 의존관계 설정 - 완료

스프링 컨테이너는 설정 정보를 참고해서 의존관계를 주입(DI)한다.

싱글톤 방식

스프링 빈 조회 - 기본

ac.getBean(빈이름, 타입)
ac.getBean(타입)
조회 대상 스프링 빈이 없으면 예외 발생

     NoSuchBeanDefinitionException: No bean named 'xxxxx' available

스프링 빈 조회 - 동일한 타입이 둘 이상

타입으로 조회시 같은 타입의 스프링 빈이 둘 이상이면 오류가 발생한다. 이때는 빈 이름을 지정하자.
ac.getBeansOfType() 을 사용하면 해당 타입의 모든 빈을 조회할 수 있다.

스프링 빈 조회 - 상속 관계

부모 타입으로 조회하면, 자식 타입도 함께 조회한다.
그래서 모든 자바 객체의 최고 부모인 Object 타입으로 조회하면, 모든 스프링 빈을 조회한다.

BeanFactory와 ApplicationContext

BeanFactory

스프링 컨테이너의 최상위 인터페이스다.
스프링 빈을 관리하고 조회하는 역할을 담당한다.
getBean() 을 제공한다.
지금까지 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능이다

ApplicatonContext가 제공하는 부가기능

메시지소스를 활용한 국제화 기능
예를 들어서 한국에서 들어오면 한국어로, 영어권에서 들어오면 영어로 출력
환경변수
로컬, 개발, 운영등을 구분해서 처리
애플리케이션 이벤트
이벤트를 발행하고 구독하는 모델을 편리하게 지원
편리한 리소스 조회
파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회

정리

ApplicationContext는 BeanFactory의 기능을 상속받는다.
ApplicationContext는 빈 관리기능 + 편리한 부가 기능을 제공한다.
BeanFactory를 직접 사용할 일은 거의 없다. 부가기능이 포함된 ApplicationContext를 사용한다.
BeanFactory나 ApplicationContext를 스프링 컨테이너라 한다.

다양한 설정 형식 지원 - 어노테이션 기반 자바 코드, XML

스프링 컨테이너는 다양한 형식의 설정 정보를 받아드릴 수 있게 유연하게 설계되어 있다.

XML을 사용하면 컴파일 없이 빈 설정 정보를 변경할 수 있는 장점도 있으므로 한번쯤 배워두는 것도 괜찮다.

스프링 빈 설정 메타 정보 - BeanDefinition

스프링은 어떻게 이런 다양한 설정 형식을 지원하는 것일까? 그 중심에는 BeanDefinition 이라는 추상화가 있다.

쉽게 이야기해서 역할과 구현을 개념적으로 나눈 것이다!

XML을 읽어서 BeanDefinition을 만들면 된다.
자바 코드를 읽어서 BeanDefinition을 만들면 된다.
스프링 컨테이너는 자바 코드인지, XML인지 몰라도 된다. 오직 BeanDefinition만 알면 된다.

BeanDefinition 을 빈 설정 메타정보라 한다.

@Bean , <bean> 당 각각 하나씩 메타 정보가 생성된다.

스프링 컨테이너는 이 메타정보를 기반으로 스프링 빈을 생성한다.

코드레벨

AnnotationConfigApplicationContext 는 AnnotatedBeanDefinitionReader 를 사용해서 AppConfig.class 를 읽고 BeanDefinition 을 생성한다.
GenericXmlApplicationContext 는 XmlBeanDefinitionReader 를 사용해서 appConfig.xml 설정 정보를 읽고 BeanDefinition 을 생성한다.
새로운 형식의 설정 정보가 추가되면, XxxBeanDefinitionReader를 만들어서 BeanDefinition 을 생성하면 된다.

BeanDefinition 정보

BeanClassName: 생성할 빈의 클래스 명(자바 설정 처럼 팩토리 역할의 빈을 사용하면 없음)
factoryBeanName: 팩토리 역할의 빈을 사용할 경우 이름, 예) appConfig
factoryMethodName: 빈을 생성할 팩토리 메서드 지정, 예) memberService
Scope: 싱글톤(기본값)
lazyInit: 스프링 컨테이너를 생성할 때 빈을 생성하는 것이 아니라, 실제 빈을 사용할 때 까지 최대한 생성을 지연처리 하는지 여부
InitMethodName: 빈을 생성하고, 의존관계를 적용한 뒤에 호출되는 초기화 메서드 명
DestroyMethodName: 빈의 생명주기가 끝나서 제거하기 직전에 호출되는 메서드 명
Constructor arguments, Properties: 의존관계 주입에서 사용한다. (자바 설정 처럼 팩토리 역할의 빈을 사용하면 없음)

결론 : BeanDefinition에 대해서는 너무 깊이있게 이해하기 보다는, 스프링이 다양한 형태의 설정 정보를 BeanDefinition으로 추상화해서 사용하는 것 정도만 이해하면 된다

스프링 핵심 원리 이해 - 객체 지향 원리 적용

zerone — Sat, 2 Apr 2022 17:20:00 +0900

기존의 문제점

client가 객체를 생성하고 연결하면 중간에 서버에서 객체에 대한 설정이 바뀔 경우 클라이언트의 소스를 같이 고쳐야한다.

AppConfig 등장

애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스를 만들자.

package hello.core;

import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;

public class AppConfig {
    public MemberService memberService() {
        return new MemberServiceImpl(new MemoryMemberRepository());
	}
    public OrderService orderService() {
    	return new OrderServiceImpl(
        	new MemoryMemberRepository(),
            	new FixDiscountPolicy());
    }
}

객체의 생성과 연결은 AppConfig 가 담당한다.
DIP 완성: MemberServiceImpl 은 MemberRepository 인 추상에만 의존하면 된다. 이제 구체 클래스를 몰라도 된다.
관심사의 분리: 객체를 생성하고 연결하는 역할과 실행하는 역할이 명확히 분리되었다. MemberServicdImpl, OrderServiceImpl 은 기능을 실행하는 책임만 지면 된다.

AppConfig 리팩토링

중복을 제거하고, 역할에 따른 구현이 보이도록 리팩터링 하자.

package hello.core;

import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
public class AppConfig {
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }
    public OrderService orderService() {
    	return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
	}
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
	}
    public DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();
	}
}

new MemoryMemberRepository() 이 부분이 중복 제거되었다. 이제 MemoryMemberRepository 를 다른 구현체로 변경할 때 한 부분만 변경하면 된다.
AppConfig 를 보면 역할과 구현 클래스가 한눈에 들어온다. 애플리케이션 전체 구성이 어떻게 되어있는지 빠르게 파악할 수 있다

결론 : AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었다.
SRP, DIP, OCP 적용.

IoC, DI, 그리고 컨테이너

IoC(Inversion of Control) : 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)이라 한다.

프레임워크 vs 라이브러리
프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다. (JUnit)
반면에 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리다.

의존관계 주입 DI(Dependency Injection)

정적인 클래스 의존 관계

클래스 다이어그램

실행 시점에 결정되는 동적인 객체(인스턴스) 의존 관계

객체 다이어그램

AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 IoC 컨테이너 또는 DI 컨테이너라 한다. (어셈블러, 오브젝트 팩토리)

AppConfig 스프링 기반으로 변경

package hello.core;

import hello.core.discount.DiscountPolicy;
import hello.core.discount.RateDiscountPolicy;
import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration

public class AppConfig {
	@Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }
    
    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
    }
    
    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
    
	@Bean       
    public DiscountPolicy discountPolicy() {
          return new RateDiscountPolicy();
	} 
}

AppConfig에 설정을 구성한다는 뜻의 @Configuration 을 붙여준다.

각 메서드에 @Bean 을 붙여준다. 이렇게 하면 스프링 컨테이너에 스프링 빈으로 등록한다.

//        AppConfig appConfig = new AppConfig();
//        MemberService memberService = appConfig.memberService();

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
MemberService memberService = applicationContext.getBean("memberService", MemberService.class);

순수 java 코드에서 선언한 AppConfig 대신 스프링 컨테이너를 적용한다.

스프링 컨테이너

ApplicationContext 를 스프링 컨테이너라 한다.
스프링 컨테이너는 @Configuration 이 붙은 AppConfig 를 설정(구성) 정보로 사용한다. 여기서 @Bean 이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라 한다.
스프링 빈은 @Bean 이 붙은 메서드의 명을 스프링 빈의 이름으로 사용한다. ( memberService , orderService )

HTTP 헤더1 - 일반 헤더

zerone — Sun, 13 Mar 2022 23:30:48 +0900

HTTP 헤더

header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
field-name은 대소문자 구문 없음

헤더 분류

Request 헤더: 요청 정보, 예) User-Agent: Mozilla/5.0 (Macintosh; ..)
Response 헤더: 응답 정보, 예) Server: Apache
General 헤더: 메시지 전체에 적용되는 정보, 예) Connection: close
Entity 헤더: 엔티티 바디 정보, 예) Content-Type: text/html, Content-Length: 3423

HTTP 표준 변경

1999년 RFC2616 (폐기) -> 2014년 RFC7230~7235 등장
엔티티(Entity) -> 표현(Representation)
Representation = representation Metadata + Representation Data
표현 = 표현 메타데이터 + 표현 데이터

HTTP BODY

메시지바디 = payload
표현은 요청이나 응답에서 전달할 실제 데이터
표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공

표현 헤더

Content-Type: 표현 데이터의 형식
Content-Encoding: 표현 데이터의 압축 방식
Content-Language: 표현 데이터의 자연 언어
Content-Length: 표현 데이터의 길이

표현 헤더는 전송, 응답 둘다 사용

협상(컨텐츠 네고시에이션)

Accept: 클라이언트가 선호하는 미디어 타입 전달
Accept-Charset: 클라이언트가 선호하는 문자 인코딩
Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
Accept-Language: 클라이언트가 선호하는 자연 언어

협상 헤더는 요청시에만 사용

협상과 우선순위

Quality Values(q)

0~1, 클수록 높은 우선순위, 생략하면 1

Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

ko-KR;q=1 (q생략)
ko;q=0.9
en-US;q=0.8
en:q=0.7

구체적인 것이 우선한다.

Accept: text/*, text/plain, text/plain;format=flowed, */*

text/plain;format=flowed
text/plain
text/*
*/*

구체적인 것을 기준으로 미디어 타입을 맞춘다.

Media Type	Quality
text/html;level=1	1
text/plain	0.3
image/jpeg	0.5
text/html;level=2	0.4
text/html;level=3	0.7
text/html;level=1	0.7

전송 방식

단순 전송 | Content-Length: 3423
압축 전송. | Content-Encoding: gzip
분할 전송. | Transfer-Encoding: chunked
범위 전송. Range:bytes=1001-2000| Content-Range: bytes 1001-2000 / 2000(끝길이)

일반 정보

From: 유저 에이전트의 이메일 정보
Referer: 이전 웹 페이지 주소 (referrer의 오타)
User-Agent: 유저 에이전트 애플리케이션 정보
Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보 Date: 메시지가 생성된 날짜

특별한 정보

Host: 요청한 호스트 정보(도메인)
Location: 페이지 리다이렉션
201 (Created): Location 값은 요청에 의해 생성된 리소스 URI
3xx (Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴
-> 해당 Location으로 자동 이동
Allow: 허용 가능한 HTTP 메서드
405 (Method Not Allowed) 에서 응답에 포함해야함
ex) Allow: GET, HEAD, PUT
Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
503 (Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT (날짜 표기)
Retry-After: 120 (초단위 표기)

인증

Authorization: 클라이언트 인증 정보를 서버에 전달
WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의

쿠키

예) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure
사용처
- 사용자 로그인 세션 관리
- 광고 정보 트래킹
쿠키 정보는 항상 서버에 전송됨
- 네트워크 트래픽 추가 유발
- 최소한의 정보만 사용(세션 id, 인증 토큰)
- 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 (localStorage, sessionStorage) 참고
주의!
- 보안에 민감한 데이터는 저장하면 안됨(주민번호, 신용카드 번호 등등)
생명주기
- Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
- Set-Cookie: max-age=3600 (3600초), 0이나 -1일 경우 즉시 삭제
- 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
- 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지
도메인
- 명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
domain=example.org를 지정해서 쿠키 생성시, example.org는 물론이고 dev.example.org도 쿠키 접근
- 생략: 현재 문서 기준 도메인만 적용
example.org 에서 쿠키를 생성하고 domain 지정을 생략시, example.org 에서만 쿠키 접근, dev.example.org는 쿠키 미접근
경로
- 이 경로를 포함한 하위 경로 페이지만 쿠키 접근
- 일반적으로 path=/ 루트로 지정
보안
1) Secure
- 쿠키는 http, https를 구분하지 않고 전송
- Secure를 적용하면 https인 경우에만 전송
2) HttpOnly
- XSS 공격 방지
- 자바스크립트에서 접근 불가(document.cookie)
- HTTP 전송에만 사용
3) SameSite
- XSRF 공격 방지
- 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

HTTP 상태코드

zerone — Sun, 13 Mar 2022 15:32:42 +0900

상태코드 : 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

1xx (Informational): 요청이 수신되어 처리중
2xx (Successful): 요청 정상 처리
3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면?

클라이언트는 상위 상태코드로 해석해서 처리 -> 미래에 상태 코드가 추가되어도 클라이언트 변경하지 않아도 됨

2xx

200 OK. 요청성공 GET
201 Created. 새로운 리소스가 생성됨
202 Accepted 요청이 접수되었으나 처리가 완료되지 않았음. 배치처리 같은 곳에서 사용 or 1시간 뒤에 요청을 처리하는 경우
204 No Content 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음. 웹 문서 편집기에서 save할 경우 결과 로 아무 내용이 없어도 된다.

3xx

300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
307 Temporary Redirect
308 Permanent Redirect

리다이렉트 : 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동

영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동, 원래의 URL 사용 X, 검색 엔진 등에서도 변경 인지

예) /members -> /users
예) /event -> /new-event

일시 리다이렉션 - 일시적인 변경, 따라서 검색 엔진 등에서 URL을 변경하면 안됨

주문 완료 후 주문 내역 화면으로 이동
PRG: Post/Redirect/Get

특수 리다이렉션

결과 대신 캐시를 사용

영구 리다이렉션 301, 308

301 - 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
308 - 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

일시적인 리다이렉션 302, 307, 303

302 Found - 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
307 Temporary Redirect - 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)
303 See Other - 리다이렉트시 요청 메서드가 GET으로 변경
307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용
자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제 없음

PRG: Post/Redirect/Get - 일시적인 리다이렉션 예시

주문(POST) 후 새로고침하면 재주문(POST) 되면 안된다. 이 경우는, 새로고침 시 GET으로 리다이렉트하여 결과 화면만 조회

기타 리다이렉션 300, 304

300 Multiple Choices: 안쓴다.
304 Not Modified : 캐시를 목저으로 사용, 캐시가 수정 안되었으므로 캐시로 리다이렉트 시켜준다. (메시지 바디 포함하면 안됨). 조건부로 GET, HEAD 요청시 사용

4xx

400 Bad Request : 요청 구문, 메시지 등등 오류
401 Unauthorized : 인증(Authentication): 본인이 누구인지 확인 (로그인) <-> 인가(Authorization): 권한부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음), 오류 메시지가 Unauthorized로 나오지만 의미는 Unauthenticted임(아쉬운부분)
403 Forbidden : 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
404 Not Found : 요청 리소스가 서버에 없음 혹은 권한 부족한 클라이언트에게 특정 리소스 숨기고 싶은 경우

5xx

500 Internal Server Error : 서버 문제로 오류 발생, 애매하면 500 오류
503 Service Unavailable : 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음. Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음

[ Algorithm][Template] 이진 탐색, 파라메트릭 서치

zerone — Fri, 11 Mar 2022 00:20:58 +0900

이진탐색을 사용하기 위한 조건 : 정렬되어 있어야 한다.

찾으려는 데이터와 중간점(middle)위치에 있는 데이터를 반복적으로 비교해서 원하는 데이터를 찾는다.

시간 복잡도 : O(log(N))

1) 재귀를 이용한 구현

#include <iostream>
#include <vector>

using namespace std;

int n, target;
vector<int> v;

int binarySearch(int s, int e, int t) {
    if (s > e)
        return -1;

    int mid = (s + e) / 2;
    if (v[mid] == t) {
        return mid;
    }
    else if (v[mid] < t) {
        return binarySearch(mid+1, e, t);
    }
    else {
        return binarySearch(s, mid-1, t);
    }
}

int main(void) {
    cin >> n >> target;

    for (int i = 0; i < n; i++) {
        int a;
        cin >> a;
        v.push_back(a);
    }

    cout << binarySearch(0, n-1, target) + 1 << "\n";

    return 0 ;
}

2) while문을 이용한 구현

#include <iostream>
#include <vector>

using namespace std;

int n, target;
vector<int> v;

int binarySearch(int t) {
    int s = 0;
    int e = v.size() - 1;

    while (s <= e) {
        int mid = (s + e) / 2;
        if (v[mid] == t) {
            return mid;
        }
        else if (v[mid] < t) {
            s = mid+1;
        }
        else {
            e = mid - 1;
        }
    }

    return - 1;
}
int main(void) {
    cin >> n >> target;

    for (int i = 0; i < n; i++) {
        int a;
        cin >> a;
        v.push_back(a);
    }

    cout << binarySearch(target) + 1 << "\n";

    return 0 ;
}

나의 경우 2번이 편하다.

1번, 2번 아무거나 사용하여도 상관 없다!

파라메트릭 서치(Parametric Search)

최적화 문제(문제의 상황을 만족하는 특정 변수의 최솟값, 최댓값을 구하는 문제)를 결정 문제(decision problem)로 바꾸어 해결하는 기법
예를 들어 범위 내에서 조건을 만족하는 가장 큰 값을 찾으라는 최적화 문제라면 이분 탐색으로 결정 문제를 해결하면서 범위를 좁혀갈 수 있다.

Lower Bound, Upper Bound

이진 탐색으로 돌음
countByRange 처럼 정렬된 배열에서 a~b까지의 숫자의 개수를 O(logN)으로 찾고자 할때 주로 사용한다.

Lower Bound

키값보다 크거나 같은 첫번째 값
찾으려고 하는 key 값이 없으면, key 값 초과인 값들 중, 가장 작은 값

Upper Bound

키값보다 큰 첫번째 값
최댓값보다 더 큰 값을 찾고자 하는 경우에는, 마지막 요소 다음 메모리를 가리키는 iterator(end()와 같은)를 반환한다. 따라서, 이 iterator에 접근하면 쓰레기값을 반환.

직접 구현할 경우는 기존 이진 탐색에서 값을 찾았을 경우 left를 이동할지 right를 이동할지를 생각해 로직을 수정하면된다.

또한 증명하는 방법은 이진탐색은 l~r의 크기가 1 또는 2일 경우를 결국은 지나므로 해당하는 경우를 모두생각해보면 편하다.

1) 직접 구현

#include <iostream>
#include <vector>

using namespace std;

int n, key;
vector<int> v;

// Key 보다 크거나 같은 첫번째 값 반환
int lowerBound() {
    int l = 0, r = n-1;

    while (l <= r) {
        int mid = (l + r) / 2;
        if (v[mid] < key) {
            l = mid + 1;
        }
        else {
            r = mid - 1;
        }
    }

    return l;
}

// Key보다 큰 첫번째 값
int upperBound() {
    int l = 0, r = n-1;

    while (l <= r) {
        int mid = (l + r) / 2;
        if ( v[mid] <= key) {
            l = mid + 1;
        }
        else {
            r = mid - 1;
        }
    }

    return l;
}

// 값이 [left, right]인 데이터의 개수를 반환하는 함수
int countByRange() {
    int left = lowerBound();
    int right = upperBound();

    return right - left;
}

int main(void) {
    cin >> n >> key;
    for (int i = 0; i < n; i++) {
        int x;
        cin >> x;
        v.push_back(x);
    }

    int cnt = countByRange();
    if (cnt == 0) {
        cout << -1 << "\n";
    }
    else {
        cout << cnt << "\n";
    }

    return 0 ;
}

2) STL

#include <iostream>
#include <vector>
#include <algorithm>

using namespace std;

int n, key;
vector<int> v;

// 값이 [left, right]인 데이터의 개수를 반환하는 함수
int countByRange() {
    // Key 보다 크거나 같은 첫번째 값 반환
    vector<int>::iterator left = lower_bound(v.begin(), v.end(), key);
    // Key보다 큰 첫번째 값
    vector<int>::iterator right = upper_bound(v.begin(), v.end(), key);

    return right - left;
}

int main(void) {
    cin >> n >> key;
    for (int i = 0; i < n; i++) {
        int t;
        cin >> t;
        v.push_back(t);
    }

    int cnt = countByRange();
    if (cnt == 0) {
        cout << -1 << "\n"; 
    }
    else {
        cout << cnt << "\n";
    }

    return 0 ;
}

HTTP 메서드 활용

zerone — Sun, 6 Mar 2022 17:37:05 +0900

클라이언트에서 서버로 데이터 전송

2가지 전달방식

쿼리 파라미터를 통한 데이터 전송

- GET

- 주료 정렬 필터(검색어)

메시지 바디를 통한 데이터 전송

- POST, PUT, PATCH

- 처리, 리소스 등록, 리소스 변경

4가지 상황

정적 데이터 조회

- 이미지, 정적 텍스트 문서

동적 데이터 조회

- 주로 검색, 게시판 목록에서 정렬 필터(검색어)

- GET - query(쿼리 파라미터, 쿼리 스트링) 사용

HTML Form을 통한 데이터 전송

- HTML 액션을 통합 데이터 전송

1) POST 전송

Content-Type: application/x-www-form-urlencoded 사용

form의 내용을 메시지 바디를 통해서 전송(key=value, 쿼리 파라미터 형식)

전송 데이터를 url encoding 처리

2) GET 전송

- 회원 가입, 상품 주문, 데이터 변경

3) 파일 업로드

- Content-Type: multipart/form-data

- 파일 업로드 같은 바이너리 데이터 전송시 사용

- 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능(그래서 이름이 multipart)

참고 : HTML Form 전송은 GET, POST만 지원

HTTP API를 통한 데이터 전송

- 회원 가입, 상품 주문, 데이터 변경

- 서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax)

- Content-Type: application/json을 주로 사용 (사실상 표준), TEXT, XML, JSON 등등

참고하면 좋은 URI 설계 개념

문서(document)

단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)

예) /members/100, /files/star.jpg

컬렉션(collection)

서버가 관리하는 리소스 디렉터리 서버가 리소스의 URI를 생성하고 관리

예) /members

스토어(store)

클라이언트가 관리하는 자원 저장소 클라이언트가 리소스의 URI를 알고 관리

예) /files

컨트롤러(controller), 컨트롤 URI

문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행 동사를 직접 사용
예) /members/{id}/delete

HTTP 메서드

zerone — Sat, 5 Mar 2022 22:52:59 +0900

API URI 설계

좋은 URI 설계란 ? 리소스 식별이 가장 중요하다.

즉, 리소스와 행위를 분리

리소스 - 명사 - 회원
행위 - 동사 - 조회, 등록, 삭제, 변경

URI는 리소스만 식별

HTTP 메서드 종류

주요 메서드

GET: 리소스 조회
POST: 요청 데이터 처리, 주로 등록에 사용
PUT: 리소스를 대체, 해당 리소스가 없으면 생성
PATCH: 리소스 부분 변경
DELETE: 리소스 삭제

기타 메서드

HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

주요메서드 분석

GET

리소스 조회
서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)으로 전달

메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음

request	/members/100	response
GET /members/100 HTTP/1.1 Host: localhost:8080	{ "username": "young", "age": 20 }	HTTP/1.1 200 OK Content-Type: application/json Content-Length: 34 { "username": "young", "age": 20 }

post

요청 데이터 처리
메시지 바디를 통해 서버로 요청 데이터 전달
서버는 요청 데이터를 처리
메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행
주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

request	/members -> /members/100 신규 리소스 식별자 생성	response
POST /members HTTP/1.1 Content-Type: application/json { "username": "young", "age": 20 }	{ "username": "young", "age": 20 }	HTTP/1.1 201 Created Content-Type: application/json \ Content-Length: 34 Location: /members/100 { "username": "young", "age": 20 }

POST처리에 정해진 것이 없다 -> 리소스 URI에 POST 요청이 오면 요청 데이터틑 어떻게 처리할지 리소스마다 따로 정해야 한다

주로, 다음과 같은 경우에 많이 사용한다.

새 리소스 생성(등록)
요청 데이터 처리
다른 메서드로 처리하기 애매한 경우

put

리소스 대체(있으면 대체 : 전체 삭제후 생성 / 없으면 생성)
클라이언트가 리소스를 식별(URI 지정)

request	/members/100
(1) 생성 PUT /members/100 HTTP/1.1 Content-Type: application/json { "username": "young", "age": 20 } (2) 리소스 완전 대체 PUT /members/100 HTTP/1.1 Content-Type: application/json { // username 없음 "age": 50 }	(1) 생성 { "username": "young", "age": 20 } (2) 리소스 완전 대체 { // username 삭제 "age": 50 }

patch

리소스 부분 변경 (put과의 차이)

request	/members/100
PATCH /members/100 HTTP/1.1 Content-Type: application/json { // username 없음 "age": 50 }	{ "username": "young", "age": 20 } 리소스 부분 변경 { "username": "young", "age": 50 }

delete

request	/members/100 리소스 제거
DELETE /members/100 HTTP/1.1 Host: localhost:8080	x

HTTP 메서드의 속성

안전(Safe Methods)

호출해도 리소스를 변경하지 않는다

멱등(Idempotent Methods)

한번 호출하든 두번 호출하든 결과가 똑같다.
GET, PUT, DELETE (POST x)
자동 복구 메커니즘에 활용 가능 : 서버 Time out 등르로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시해도 되는가? 판단 근거, 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다

캐시가능(Cacheable Methods)

응답 결과 리소스를 캐시해서 사용해도 되는가?
GET, HEAD, POST, PATCH 캐시가능
실제로는 GET, HEAD 정도만 캐시로 사용, POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음

HTTP웹_기본지식_20201226 출처: https://ko.wikipedia.org/wiki/HTTP

[C++][STL] fill, fill_n

zerone — Tue, 1 Mar 2022 20:05:53 +0900

가끔 배열이나 벡터를 전부 초기화 해야할 일이 생긴다.

평소에 for문을 돌려서 초기했다면 fill, fiil_n을 사용해서 코드를 간결하게 만들자.

1) fill

template< class ForwardIt, class T >
void fill( ForwardIt first, ForwardIt last, const T& value );

fill(초기 위치, 마지막 위치, 초기화값); (초기위치<= arr < 마지막위치)

예제 : fill(arr,arr+5,1);

2) fill_n

template< class OutputIt, class Size, class T >
void fill_n( OutputIt first, Size count, const T& value );

fill_n(초기 위치, 사이즈, 초기화값);

예제 : fill_n(arr,5,1);

0으로 초기화하려면 memset(arr, 0, sizeof(arr)); 이 제일 좋다.

그러나, fill, fill_n을 써도 문제 없다.

그리고 2차원 이상의 배열의 경우 fill_n은 1차원으로 인식하는 문제가 있으므로 fill을 사용하는 습관을 들이자.

예제 : fill(&arr[0][0], &arr[5][3], 7);

결론 : fill 마스터하자

HTTP 기본

zerone — Tue, 1 Mar 2022 18:23:49 +0900

HTTP : HyperText Transfer Protocol

HTML, TEXT
IMAGE, 음성, 영상, 파일
JSON, XML (API)
거의 모든 형태의 데이터 전송 가능
서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

클라이언트 - 서버

Request - Response 구조

Stateful, Stateless

상태유지

- 항상 같은 서버가 유지되어야 한다.

- 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지, 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지

- 상태 유지는 최소한만 사용

무상태

- 아무 서버나 호출 가능하다. 무한한 서버 증설 가능 (Scale out - 수평확장에 유리)

- 서버 개발자가 가장 어려워 하는 부분 - 같은 시간에 딱 맞추어 대규모 트래픽이 발생하는 것을 해결하기 위해 적절히 필요

Connectionless

HTTP는 기본이 비연결성(connectionless)

한계

TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수 많은 자원이 함께 다운로드

극복

지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
HTTP/2, HTTP/3에서 더 많은 최적화

HTTP 메시지

<요청 메시지>

start-line = request-line / status-line
request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)

method 종류 : GET, POST, PUT, DELETE...
request target : absolute-path[?query] (절대경로[?쿼리]) 참고) *, http://...?x=y 와 같이 다른 유형의 경로지정 방법도 있다.
HTTP-version : ex) HTTP/1.1

ex) GET /search?q=hello&hl=ko HTTP/1.1

Host: www.google.com

<응답 메시지>

start-line = request-line / status-line
status-line = HTTP-version SP status-code SP reason-phrase CRLF

HTTP-version : ex) HTTP/1.1
status-code : HTTP 상태코드 - 요청 성공, 실패를 나타냄 ex) 200 성공, 400 클라이언트 요청 오류, 500 서버 내부 오류

ex) HTTP/1.1 200 OK

Content-Type: text/html;charset=UTF-8 Content-Length: 3423

</html>

HTTP 헤더 / 메시지 바디

HTTP 헤더

HTTP 전송에 필요한 모든 부가정보
header-field = field-name ":" OWS field-value OWS. (OWS : Optional WhiteSpace : 띄어쓰기 허용)
field-name은 대소문자 구문 없음

ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 캐시 관리 정보 ...

(표준 헤더가 너무 많음, 필요시 임의의 헤더 추가 가능 - hellowordl:hi)

HTTP 메시지 바디

실제 전송할 데이터
HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능

< 요청 메시지 예제>

요청 메시지	GET /search?q=hello&hl=ko HTTP/1.1
HTTP 헤더	Host: www.google.com

< 응답 메시지 예제>

응답 메시지	HTTP/1.1 200 OK
HTTP 헤더	Content-Type: text/html;charset=UTF-8 Content-Length: 3423
HTTP 메시지 바디	<html> <body>...</body> </html>

HTTP는 단순핟고 확장가능한 기술이다.

URI와 웹 브라우저 요청 흐름

zerone — Thu, 24 Feb 2022 00:33:07 +0900

URI(Uniform Resource Identifier) : 자원을 식별하는 통일된 방식

URL(Resource Locator)
URN(Resource Name)

URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않아 URL을 보통 URI로 사용한다.

foo://example.com:8042/over/there?name=ferret#nose - URL

\_/ \________________/\_________/ \_________/ \__/

| | | | |

scheme authority path query fragment
| _____________________|__

/\ / \

urn:example:animal:ferret:nose - URN

URL

scheme://[userinfo@]host[:port][/path][?query][#fragment]

ex ) https://www.google.com:443/search?q=hello&hl=ko

- 프로토콜(https)
- 호스트명(www.google.com) - 도메인명 또는 IP주소
- 사용자정보 - 거의 사용하지 않음
- 포트 번호(443) - 일반적으로 생략, 디폴트로 http 80, https 443
- 패스(/search) - 경로, 계층적 구조
- 쿼리 파라미터(q=hello&hl=ko) - key=value 형태, ?로 시작, &로 추가, 웹서버에 제공하는 파라미터, 문자형태,
query string으로도 불림
- fragment - html 내부 북마크 등에 사용, 서버에 전송 안함. (->자세히는 나중에)

웹 브라우저 요청 흐름

1) URL을 분석해 HTTP 메시지를 만든다

2) 인터넷 네트워크 편에서 설명한 것처럼 HTTP 메시지에 TCP/IP 패킷이 붙고 Ethernet Frame도 씌워진다.

3) 요청 패킷 전달

4) 요청 패킷 도착

5) 응답 메시지도 요청 메시지와 동일하게 HTTP 메시지에 TCP/IP 패킷이 붙고 Ethernet Frame도 씌워져 전달된다

6) 응답 패킷 전달

7) 응답 패킷 도착

8) 응답 받은 메시지 렌더링

인터넷 네트워크

zerone — Tue, 15 Feb 2022 00:28:25 +0900

인터넷 프로토콜 스택의 4계층 (TCP/IP 4계층)

계층	프로토콜 종류
애플리케이션	HTTP, FTP
전송	TCP, UDP
인터넷	IP
네트워크 인터페이스	LAN 드라이버, LAN 장비

송신시 동작 순서

각 Layer에서 저장되는 정보

3-way-handshake

- 데이터 전송전 연결을 확인한다.

접속요청 : SYN ->
<- ACK+SYN : 요청 수락 + 접속요청
요청수락 : ACK ->
데이터 전송 (참고 : 3.ACK와 함께 데이터 전송 가능)

TCP와 UDP 차이

	TCP	UDP
연결지향	연결지향 - 3 way handshake (가상 연결)	x, 기능이 거의 없음
데이터 전달 보증	데이터 전달 보증	x
순서 보장 (packet 1, 2, 3 -> 1, 2, 3)	순서 보장	x
신뢰성	신뢰할 수 있다	x
속도	느림	빠름

결론	현재는 대부분 TCP 사용	IP와 거의 같다. + port + 체크섬 정도만 추가 애플리케이션에서 추가작업 필요.

PORT

같은 IP 내 프로세스 구분 ( 서버에 두개의 애플리케이션이 띄워져 있고 두개의 애플리케이션에 접근하고자 한다면 Port를 이용해 구분하여 붙을 수 있다 )
따라서 TCP 세그먼트에 출발지, 목적지 PORT 추가.

DNS

Domain Name System
IP 기억하기 어려우니 사용

<참고>

해당 포스팅은 인프런의 김영한님이 강의하신 HTTP 강의 를 수강하고, 이해를 정리한 기록들이며 모든 자료의 출처는 강의의 강의자료이다.

[Algorithm][오답노트] [이코테] 4. 만들 수 없는 금액

zerone — Sat, 12 Feb 2022 15:56:32 +0900

문제

편의점 주인인 동빈이는 N개의 동전을 가지고 있다.
N개의 동전을 이용하여 만들 수 없는 양의 정수 금액 중 최솟값을 구하라.

예를 들어,

N = 5이고, 각 동전이 각각 3원, 2원, 1원, 1원, 9원짜리 동전이라고 가정하자. 이때 동빈이가 만들 수 없는 양의 정수 금액 중 최솟값은 8원이다.

N = 3이고 각 동전이 각각 3원, 5원, 7원이면, 만들 수 없는 양의 정수 금액 중 최솟값은 1원이다.

입력

첫째 줄에는 동전의 개수를 나타내는 양의 정수 N이 주어진다. ( 1 <= N 1,000)
둘째 줄에는 각 동전의 화폐 단위를 나타내는 N개의 자연수가 주어지며 각 자연수는 공백으로 구분된다. 각 화폐 단위는 1,000,000 이하의 자연수이다.

출력

첫째 줄에 주어진 동전들로 만들 수 없는 양의 정수 금액 중 최솟값을 출력한다.

입력 예시

입력

5
3 2 1 1 9

느낀점

이 문제는 처음 보면 그리디 알고리즘이라고 생각하기 힘든 문제였다.

하지만 알고나면 너무 쉬운 문제다.

하나의 유형이라고 생각하고 외워두면 좋을 것 같다.

문제를 풀어내는 사고방식은 다음과 같다.

작은 동전부터 탐색하면서, 만들고자 하는 금액(target)을 아직 이용하지 않고 가장 작은 금액의 동전이 만들고자 하는 금액 이하이면 해당 금액을 그 전에 이용한 동전과 조합해 만들 수 있다.

그 전에 이용했던 동전들로 1~target-1의 금액을 만들 수 있고 이용하지 않은 가장 작은 금액의 동전이 target 보다 작다면
이용하지 않은 가장 작은 금액의 동전 ( <= target) + (1~target-1) ∋ target

이 성립한다.

따라서 동전들을 정렬한 후, 하나씩 뽑으면서 다음 target을 업데이트해주면 된다.

#include <iostream>
#include <vector>

using namespace std;

int n;

vector<int> v;
int main(void) {
    cin >> n;
    for (int i = 0; i < n; i++) {
        int x;
        cin >> x;
        v.push_back(x);
    }

    // 1. 정렬
    sort(v.begin(), v.end());

    // 2. 첫번째 target은 1, 이용하기 전의 가장 작은 동전이 target이하여야 target을 만들 수 있다.
    int target = 1;
    for (int i = 0; i < n; i++) {
        if (v[i] <= target) {
            target += v[i];
        }
        else {
            // 만들 수 없는 금액 종료
            break;
        }
    }

    cout << target << "\n";

    return 0 ;
}

[Algorithm] 정렬

zerone — Mon, 7 Feb 2022 23:35:31 +0900

정렬에는 여러가지 방식이 있고 다음 4가지 정렬만 우선 다루려고 한다.

설명은 오름차순 기준으로 진행하므로 내림차순은 반대로 생각하면 된다.

1. 선택정렬(Selection Sort)

- O(N^2)

- k번째 작은 데이터를 가져와 k번째 위치에 놓는다.

#include <iostream>
#include <vector>

using namespace std;

vector<int> arr {7, 5, 9, 0, 3, 1, 6, 2, 4, 8};

int main(void) {

    // 삽입정렬
    for (int i = 0; i < arr.size(); i++) {
        for (int j = i; j > 0; j--) {
            if (arr[j] < arr[j-1]) {
                swap(arr[j], arr[j-1]);
            }
        }
    }

    for (int i = 0; i < arr.size(); i++) {
        cout << arr[i] << " ";
    }
    cout << "\n";
    return 0 ;
}

2. 삽입정렬(Insertion Sort)

- O(N^2)

- 데이터를 하나씩 확인하며, 각 데이터를 적절한 위치에 삽입한다.

#include <iostream>
#include <vector>

using namespace std;

vector<int> arr {7, 5, 9, 0, 3, 1, 6, 2, 4, 8};

int main(void) {

    // 선택정렬
    for (int i = 0; i < arr.size(); i++) {
        int min_index = i;
        for (int j = i+1; j < arr.size(); j++) {
            if (arr[min_index] > arr[j]) {
                min_index = j;
            }
        }
        swap(arr[min_index], arr[i]);
    }

    for (int i = 0; i < arr.size(); i++) {
        cout << arr[i] << " ";
    }
    cout << "\n";
    return 0 ;
}

3. 퀵정렬(Quick Sort)

- O(N^2)

- 호어 분할 방식 : 리스트에서 첫번째 데이터를 pivot으로 정한다. 이외에도 많은 pivot의 기준을 잡는 방식은 많다.

1) pivot을 기준으로 왼쪽에서부터 pivot보다 큰 데이터를 찾고 오른쪽부터 pivot보다 작은 데이터를 찾아 교환한다.

2) 1) 을 반복하다 작은 데이터와 큰 데이터가 바뀌면 작은 데이터와 pivot을 바꾼다.

3) pivot으로 분할된 왼쪽 리스트와 오른쪽 리스트에 대해 각각 1), 2)를 반복수행한다.

*C++ sort의 경우 퀵 정렬을 기반으로 하지만 피벗값을 설정할 때 추가적인 로직을 더해 O(NlogN)을 보장한다.

#include <iostream>
#include <vector>

using namespace std;

vector<int> arr {7, 5, 9, 0, 3, 1, 6, 2, 4, 8};

void quickSort(int start, int end) {
    // 원소가 한개인 경우 종료
    if (start >= end) {
        return;
    }

    // 호어 분할 방식 : pivot은 첫번째 원소
    int pivot = start;
    int left = pivot+1;
    int right = end;

    while (left <= right) {
        // pivot보다 큰 데이터를 찾을 때까지 반복 (배열을 초과하지 않을 정도로만)
        while (left <= end && arr[left] <= arr[pivot]) {
            left++;
        }
        // pivot보다 작은 데이터를 찾을 때까지 반복 (pivot index보다 커야함)
        while (right > start && arr[right] >= arr[pivot]) {
            right--;
        }
        // 엇갈렸다면 작은 데이터와 pivot을 교체
        if (left > right) {
            swap(arr[right], arr[pivot]);
        }
        // 엇갈리지 않았다면 큰 데이터와 작은 데이터를 교체
        else {
            swap(arr[left], arr[right]);
        }
    }

    // 분할 후, 왼쪽 리스트와 오른쪽 리스트에서 각각 반복수행
    quickSort(start, right-1);
    quickSort(right+1, end);

}

int main(void) {

    quickSort(0, arr.size()-1);

    for (int i = 0; i < arr.size(); i++) {
        cout << arr[i] << " ";
    }
    cout << "\n";
    return 0 ;
}

계수 정렬(Counting Sort)

O(N+K)
정렬된 리스트에 가장 작은 데이터부터 큰 데이터까지의 빈도를 세서 저장해주는 것이다. 말 그대로 count다.
가장 큰 데이터와 가장 작은 데이터의 차이가 1,000,000을 넘지 않을 때 효과적이다. (이를 넘어가면 공간 복잡도를 초과한다.)
즉, 시간 복잡도를 위해 공간 복잡도를 희생한다.
말도 안되게 빠른 정렬을 요하는 문제는 무조건 계수정렬이다.

#include <iostream>
#include <vector>

#define MAX_VALUE 9

using namespace std;

int n = 15;
// 모든 원소의 값이 0보다 크거나 같다고 가정
int arr[15] = {7, 5, 9, 0, 3, 1, 6, 2, 9, 1, 4, 8, 0, 5, 2};
// 모든 범위를 포함하는 배열 선언(모든 값은 0으로 초기화)
int cnt[MAX_VALUE + 1];

int main(void) {
    for (int i = 0; i < n; i++) {
        cnt[arr[i]] += 1; // 각 데이터에 해당하는 인덱스의 값 증가
    }
    for (int i = 0; i <= MAX_VALUE; i++) { // 배열에 기록된 정렬 정보 확인
        for (int j = 0; j < cnt[i]; j++) {
            cout << i << ' '; // 띄어쓰기를 기준으로 등장한 횟수만큼 인덱스 출력
        }
    }
}

[Algorithm][Template] DFS와 BFS

zerone — Sat, 5 Feb 2022 18:42:19 +0900

	DFS	BFS
동작원리	스택	큐
구현방법	*재귀함수 이용	큐 자료구조 이용
시간복잡도	O(N)	O(N)

*재귀함수 : 자기 자신을 다시 호출하는 함수, 종료조건을 반드시 명시해야 한다.

DFS 동작과정

탐색 시작 노드를 스택에 삽입하고 방문 처리를 한다.
스택의 최상단 노드에 방문하지 않은 인접 노드가 있으면 그 인접 노드를 스택에 넣고 방문 처리를 한다. 방문하지 않은 인접 노드가 없으면 스택에서 최상단 노드를 꺼낸다. (방문처리 순서가 중요하다. 스택에 삽입되면서 준비상태가 되면 방문처리가 되어야 한다.)
2번 과정을 더 이상 수행할 수 없을 때까지 반복한다.

- 재귀함수 자체가 스택형식으로 작동한다. (함수호출 - 스택에 삽입, 함수 종료 - 스택에서 제거)

- 즉, DFS는 재귀함수를 이용하면 스택을 따로 선언하여 사용할 필요가 없다. 따라서 BFS보다 구현이 간편하다.

#include <iostream>
#include <vector>

using namespace std;

vector<vector<int> > graph = {
    vector<int> {},
    vector<int> {2, 3, 8},
    vector<int> {1, 7},
    vector<int> {1, 4, 5},
    vector<int> {3, 5},
    vector<int> {3, 4},
    vector<int> {7},
    vector<int> {2, 6, 8},
    vector<int> {1, 7}
};
bool visited[101];

// DFS 함수 정의
// 탐색 시작 노드 스택 삽입
void dfs(int now) {
    // 현재 노드를 방문 처리
    visited[now] = true;
    cout << now << " ";
    // 현재 노드의 인접 노드 중 방문하지 않은 노드 재귀적으로 방문
    for (int next : graph[now]) {
        if (!visited[next]) {
            dfs(next);
        }
    }
// 현재(최상단) 노드 스택에서 꺼내기
}
int main(void) {

    dfs(1);
    cout << "\n";

    return 0 ;
}

BFS 동작과정

탐색 시작 노드를 큐에 삽입하고 방문 처리를 한다.
큐에서 노드를 꺼내 해당 노드의 인접 노드 중에서 방문하지 않은 노드를 전부 큐에 삽입하고 방문처리를 한다. (방문처리 순서가 중요하다. 큐에 삽입되면서 준비상태가 되면 방문처리가 되어야 한다.)
2번 과정을 더 이상 수행할 수 없을 때까지 반복한다.

- 일반적인 경우 BFS가 DFS보다 성능이 좋다.

#include <iostream>
#include <vector>
#include <queue>

using namespace std;

vector<vector<int> > graph = {
    vector<int> {},
    vector<int> {2, 3, 8},
    vector<int> {1, 7},
    vector<int> {1, 4, 5},
    vector<int> {3, 5},
    vector<int> {3, 4},
    vector<int> {7},
    vector<int> {2, 6, 8},
    vector<int> {1, 7}
};
bool visited[101];

// BFS 함수 정
void bfs(int start) {
    queue<int> q;

    // 탐색 시작 노드 큐에 삽입
    q.push(start);
    // 현재 노드를 방문 처리
    visited[start] = true;
    
    // 큐가 빌때까지 반복
    while(!q.empty()) {
        // 큐에서 원소 하나 뽑기
        int now = q.front();
        cout << now << " ";
        q.pop();

        // 해당 원소와 연결된, 아직 방문하지 않은 노 큐에 삽입 후 방문처리
        for (int next : graph[now]){
            if (!visited[next]) {
                q.push(next);
                visited[next] = true;
            }
        }
    }
}
int main(void) {

    bfs(1);
    cout << "\n";

    return 0 ;
}

결론

트리의 깊이를 묻는 문제는 BFS를 사용하자. 둘 다 사용할 수 있어도 BFS를 쓰자.

[Algorithm] 그리디 알고리즘

zerone — Sat, 5 Feb 2022 17:53:06 +0900

그리디 알고리즘(Greedy algorithm) : 탐욕법, 현재 상황에서 지금 당장 좋은 것만 고르는 방법

그리디 알고리즘의 대표적인 예제는 거스름돈이다.

마트에 가서 현금으로 결제하면 직원은 우리에게 '가장 큰 화폐단위'부터 돈을 거슬러 준다.

그것이 가장 적은 화폐수로 거스름돈을 줄 수 있는 방법이기 때문이다.

정당성을 어떻게 보장하는가?

그리디 알고리즘의 정당성 : 그리디 알고리즘을 이용해도 '최적의 해'를 찾을 수 없는 경우가 많다.

거스름돈의 예에서, 어떤 화폐는 그것보다 작은 단위의 배수이므로 작은 단위의 동전들을 종합해 다른 해가 나올 수 없나는 사실이 정당성을 증명한다.

우리나라 화폐는 10, 50, 100, 500, 1000, 5000, 10000, 50000이다. 즉 배수로 증가함을 확인할 수 있다.

반면에, 600원짜리 화폐가 등장한다면 그리디 알고리즘의 정당성을 충족하지 못한다.

이처럼 그리디 알고리즘의 문제에서는 문제풀이 아이디어를 그리디로 접근했다면 이것이 정당한지를 검토할 수 있어야 한다.

객체지향 프로그래밍이란?

zerone — Mon, 31 Jan 2022 20:19:52 +0900

객체지향 프로그래밍이란?

객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지 를 주고받고, 데이터를 처리할 수 있다. (협력)
객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다.

객체지향의 특징 4가지

추상화
캡슐화
상속
다형성

역할과 구현으로 분리(다형성)

자바 언어의 다형성을 활용
역할 = 인터페이스
구현 = 클래스, 객체
단순해져 변경에 유연해진다.
클라이언트를 변경하지 않고, 서버의 유현기능만을 유연하게 변경 가능하다.
확장에 유연
인터페이스를 안정적으로 잘 설계하는 것이 중요하다

객체지향에선 다형성이 가장 중요한다.

스프링은 다형성을 극대화하여 사용할 수 있게 도와준다. ex) IoC, DI

SOLID
클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리

SRP: 단일 책임 원칙(single responsibility principle)

- 한 클래스는 하나의 책임만 가져야 한다.

- 변경이 있을 때 파급효과가 적어야 한다.

OCP: 개방-폐쇄 원칙 (Open/closed principle)

- 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

- 다음과 같이 다형성을 활용해 역할과 구현을 분리해도 서버단의 구현객체를 변경하려면 클라이언트 코드를 변경해야 한다.

MemberRepository m = new MemoryMemberRepository(); //기존 코드
MemberRepository m = new JdbcMemberRepository(); //변경 코드

- 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.

LSP: 리스코프 치환 원칙 (Liskov substitution principle)
- 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- 부모 클래스의 행동규약을 자식 클래스가 위반하지 말아야 한다.

ex) 오버라이딩 잘 못 하는 경우 :
```
  1. 자식 클래스가 부모 클래스의 변수의 타입을 바꾸거나 메소드의 파라미터 또는 리턴값의 타입 or 갯수를 바꾸는 경우
  2. 자식 클래스가 부모 클래스의 의도와 다르게 메소드를 오버라이딩 하는 경우
```
ISP: 인터페이스 분리 원칙 (Interface segregation principle)

- 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.

즉, 역할을 여러 개로 구별하여 쪼개자.

DIP: 의존관계 역전 원칙 (Dependency inversion principle)

- 추상화에 의존해야지 구체화에 의존하면 안된다.

즉, 인터페이스에 의존하게 만들자.

- 위의 OCP 예제 코드도 구현에 의존되어 있다.

결론 : 다형성만으로는 OCP, DIP를 지킬 수 없다.

이를 spring에서 지원해준다.

[Algorithm][Template] 2차원 배열 동서남북 움직이기

zerone — Sat, 29 Jan 2022 14:46:05 +0900

지도(그래프)에서 동서남북으로 움직이는 문제는 자주 출제되는 문제유형인 것 같다.

2차원 배열에서 상하좌우로 1칸씩 움직일 수 있고 배열의 범위를 초과하는 것을 다뤄야 할 경우가 많다.

그래서 2차원 배열 동서남북 움직이기를 템플릿으로 만들어 두면 좋을 것 같다.

다음은 R, L, U, D를 입력 받아 동서남북으로 움직이는 전형적인 문제의 답안이다.

움직이는 좌표를 설정하고 공간을 벗어나는 경우를 continue로 무시하여 깔끔하게 코드를 작성하는 법이라 생각한다.

#include <iostream>
#include <vector>

using namespace std;

int r = 1, c = 1;
int n;
string plans;

// 동, 서, 남, 북 방향
int dr[4] = {0, 0, 1, -1};
int dc[4] = {1, -1, 0, 0};
char move_types[4] = {'R', 'L', 'D', 'U'};

int main(void) {
    cin >> n;
    cin.ignore();
    getline(cin, plans);

    // 이동 계획을 하나씩 확인
    for (int i = 0; i < plans.size(); i++) {
        char plan = plans[i];

        // 이동 후 좌표 구하기
        int tr = r, tc = c;
        for (int j = 0; j < 4; j++) {
            if (plan == move_types[j]) {
                tr += dr[j];
                tc += dc[j];
            }
        }

        // 공간을 벗어나는 경우 무시
        if (tr < 1 || tr > n || tc < 1 || tc > n) {
            continue;
        }

        r = tr;
        c = tc;
    }

    cout << r << " " << c << "\n";

    return 0;
}

[Algorithm][Template] 순열과 조합

zerone — Sat, 22 Jan 2022 15:42:16 +0900

C++에서는 순열과 조합을 각각 next_permutation, prev_permutation을 이용해 쉽게 구할 수 있다.

next_permutation

C++의 algorithm 헤더에는 n개의 원소의 순열을 구할 수 있는 next_permutation이라는 함수가 있습니다. 기본적 문법은 다음과 같습니다.

// default

bool next_permutation (BidirectionalIterator first,

BidirectionalIterator last);

// custom

bool next_permutation (BidirectionalIterator first,

BidirectionalIterator last, Compare comp);

next_permutation은 순열을 구할 컨테이너(쉽게 말해 배열)의 시작과 끝 iterator를 인자로 받습니다. 만약 해당 컨테이너에 다음 순열이 존재하면 그 컨테이너의 원소를 해당 순열 순서로 바꾸고 true를 반환하고, 다음 순열이 없다면 false를 반환합니다. 위 코드의 custom에서 볼 수 있듯이 비교 함수 comp를 인자로 넘기는 것도 가능합니다.

next_permutation을 사용할 때는 몇 가지 주의할 점이 있습니다.

오름차순으로 정렬된 값을 가진 컨테이너로만 사용가능합니다.
default로 operator < 를 사용해 순열을 생성합니다. 즉 오름차순으로 순열을 생성합니다.
중복이 있는 원소들은 중복을 제외하고 순열을 만들어줍니다.

3번의 예시를 들자면 {0, 0, 1}과 같은 배열의 순열을 구한다면 중복을 제외한

{0, 0, 1}, {0, 1, 0}, {1, 0, 0}이 됩니다. 이를 이용해 조합(Combination)을 구할 수 있습니다.

출처: https://mjmjmj98.tistory.com/38 [Live passionate ]

<순열 - 중복 포함하지 않음>

#include <iostream>
#include <vector>
#include <algorithm>

using namespace std;

vector<int> v{2, 1, 3};

int main(void) {

    // 1. next_permutation 사용을 위한 v 오름차순 정렬
    sort(v.begin(), v.end());

    // 2. 오름차순으로 정렬된 순열 출력
    do {
        for (auto it = v.begin(); it != v.end(); it++) {
            cout << *it << " ";
        }
        cout << endl;
    }
    while (next_permutation(v.begin(), v.end()));

    return 0 ;
}

<조합 - 중복 포함하지 않음>

#include <iostream>
#include <vector>
#include <algorithm>
#include <functional>

using namespace std;

vector<int> v{2, 1, 3};
vector<int> t{1, 1, 0};

int main(void) {

    // 1. prev_permutation 사용을 위한 t 내림차순 정렬
    sort(t.begin(), t.end(), greater<int>());

    // 2. 내림차순으로 정렬된 데이터를 받아서 순열로 뽑고 그 부분만 v에서 뽑아내 조합으로 만들기
    do {
        for (int i = 0; i < v.size(); i++) {
            if (t[i]) {
                cout << v[i] << " ";
            }
        }
        cout << endl;
    }
    while (prev_permutation(t.begin(), t.end()));

    return 0 ;
}

do-while은 쓰면 안 좋다지만, 위의 경우는 예외로 쓰도록 하자.

참고로, next_permutation, prev_permutation 함수는 터미널에서는 기본 제공되지만, 백준과 같은 사이트에서 사용하려면

#include <algorithm>을 해줘야 한다.

시간복잡도

- next_permutation 자체가 O(n)이고 nPr 자체는 O(n!) 이므로 위 템플릿처럼 순열 조합을 구현하면 O(n*n!)이 된다.

[Algorithm][Template] Prefix Sum, 구간 합 계산

zerone — Thu, 20 Jan 2022 17:19:35 +0900

Prefix Sum : 여러 개의 누적합, 구간합을 묻는 쿼리에 대해 효율적인 알고리즘

누적합 : [0, Right] 구간의 합
구간합 : [Left, Right] 구간의 합

하나의 구간합을 구하는 것이 O(N)이고 구간합을 구하라는 M개의 쿼리가 들어온다면 시간복잡도는 O(NM)이다.

N = 1,000,000 이고 M = 1,000,000이라면 시간복잡도가 너무 안좋다.

이런 경우 사용하는 것이 Prefix Sum 이다.

누적합을 구해놓고 누적합 간에 -연산을 하면 구간합이기 때문이다.

- 시간복잡도 : O(N+M)

- 동작과정

1) N개의 수에 대하여 접두사 합(Prefix Sum)을 계산하여 배열 P에 저장한다.

2) 매 M개의 쿼리 정보 [L, R]을 확인할 때 구간 합은 P[R]-P[L-1]이다.

▪️ 이때, P[0] 에 0을 넣고 L >= 1 을 만들면 코드가 간결해진다.

#include <iostream>
#include <vector>

using namespace std;

int n = 5;
vector<int> data = {10, 20, 30, 40, 50};
vector<int> prefix_sum;

int main(void) {
    // 첫 배열 0 대입
    prefix_sum.push_back(0);

    int sum_value = 0;
    for (auto d : data) {
        sum_value += d;
        prefix_sum.push_back(sum_value);
    }

    int left = 3;
    int right = 4;
    cout << prefix_sum[right] - prefix_sum[left-1] << endl;


    return 0 ;
}

다만 위 코드는 90도 회전할 때마다 vector를 선언해 heap영역에 계속 쌓이게 된다.

여러번 돌리면 메모리 관점에서 좋지 않다.

그렇기 때문에 4번이 넘어가는 회전은 4로 나눈 나머지만 회전하는 등 사용에 주의가 필요하다.

[Algorithm][Template] 투 포인터

zerone — Thu, 20 Jan 2022 16:19:27 +0900

투 포인터(Two Pointer) 알고리즘 : 리스트에 순차적으로 접근해야 할 때 2개의 점의 위치를 기록하면서 처리

투 포인터는 다음 2가지 케이스가 대표적인 문제 유형이다.

1. 특정한 합(M)을 가지는 부분 연속 수열 찾기

- 시간복잡도 : O(N) { O(2*N)}

- 동작과정

1) 시작점(s)와 끝점(e)를 첫 번째 원소의 인덱스(0)로 지정한다

2) s부터 e까지 현재 부분합이 특정한 합(M)과 같다면 카운트한다.

3) s부터 e까지 현재 부분합이 특정한 합(M)보다 작다면 e를 1 증가시킨다.

4) s부터 e까지 현재 부분합이 특정합 합(M)보다 크다면 s를 1 증가시킨다.

5) 모든 경우를 확인할 떄까지 2)번부터 4)까지의 과정을 반복한다.

#include <iostream>
#include <vector>

using namespace std;

int n = 5, m = 5; // 데이터의 개수 n, 찾고자 하는 부분합 m

int arr[] = {1, 2, 3, 2, 5};

int main(void) {
    int cnt = 0;
    int interval_sum = 0;
    int e = 0;

    // start를 차례때로 증가시키며 반복
    for (int s = 0; s < n; s++) {
        // end를 가능한 만큼 이동시키기
        while (interval_sum < m && e < n) {
            interval_sum += arr[e++];
        }

        // 부분합이 m일 때 카운트 증가
        if (interval_sum == m) {
            cnt++;
        }

        interval_sum -= arr[s];
    }

    cout << cnt << endl;

    return 0 ;
}

2. 정렬되어 있는 두 리스트의 정렬된 합집합

- 시간복잡도 : O(N+M) [N: a 크기, M: b 크기]

- 동작과정

1) 정렬된 리스트 a와 b를 입력 받는다.

2) 리스트 a에서 처리되지 않은 원소의 인덱스를 i로 지정한다.

3) 리스트 b에서 처리되지 않은 원소의 인덱스를 j로 지정한다.

4) a[i]와 b[j]중 저 작은 원소를 결과(result) 리스트에 담고 해당 리스트의 인덱스(i 또는 j)를 1 증가시킨다.

5) a와 b에 처리할 원소가 없을 때까지 2) ~ 4) 과정을 반복한다.

#include <iostream>
#include <vector>

using namespace std;

// 사전에 정렬된 리스트 a, b 선언
int n = 3, m =4;
vector<int> a = {1, 3, 5};
vector<int> b = {2, 4, 6, 8};

int main(void) {
    int i = 0;
    int j = 0;
    // 리스트 a와 b의 모든 원소 담을 수 있는 결과 리스트
    vector<int> result;

    // 더 이상 리스트 a와 b에 처리할 원소가 없을 때까지 반복
    while (i < n || j < m) {
        // 리스트 b의 모든 원소가 처리되었거나, 리스트 a의 원소가 더 작을 경우
        if (j >= m || (i < n && a[i] <= b[j])) {
            result.push_back(a[i++]);
        }
        // 처리되지 않은 리스트 b의 원소가 존재하고 리스트 a의 모든 원소가 처리되었거나, 리스트 b의 원소가 더 작을 경우
        else {
            result.push_back(b[j++]);
        }
    }

    for (int r : result) {
        cout << r << " ";
    }
    cout << endl;

    return 0 ;
}

2번 코드에서 while문 안의 if-else구문에 조건이 여러개 들어가는데 이 부분이 익숙하지 않다.

익숙해지도록 하자.

[Algorithm][Template] 2차원 리스트 90도 돌리기

zerone — Thu, 20 Jan 2022 15:39:22 +0900

2차원 리스트를 반시계방향으 90도 돌리는 함수 템플릿이다.

자주 사용될 것 같아 template으로 등록한다.

java, python을 이용한 코드는 많지만 c++을 이용한 코드는 찾기 어려워 따로 정리한다.

시계방향으로 90도 돌리고 싶은 경우 해당함수를 3번 돌리자.

#include <iostream>
#include <vector>

using namespace std;

vector<vector<int> > rotate_a_matrix_by_90_degree(vector<vector<int> > &graph)
{
    int row_len = graph.size();
    int col_len = graph[0].size();

    vector<vector<int> > res(col_len, vector<int>(row_len, 0));    

    for (int i = 0; i < row_len; i++) {
        for (int j = 0; j < col_len; j++) {
            res[col_len-j-1][i] = graph[i][j];
        }
    }
    
    return res;
}
int main(void) {

    vector<int> t1 = {1,2,3,4};
    vector<int> t2 = {5,6,7,8};
    vector<int> t3 = {9,10,11,12};

    vector<vector<int> > a = {t1, t2, t3};


    // 반시계 방향 90도 돌리기
    vector<vector<int> > b = rotate_a_matrix_by_90_degree(a);

    for (int i = 0; i < b.size(); i++) {
        for (int j = 0; j < b[i]. size(); j++) {
            cout << b[i][j] << " ";
        }
        cout << endl;
    }

    // 시계 방향 90도 돌리기 =  반시계 방향 90도* 3 돌리기
    vector<vector<int> > c = rotate_a_matrix_by_90_degree(a);
    vector<vector<int> > d = rotate_a_matrix_by_90_degree(c);
    vector<vector<int> > e = rotate_a_matrix_by_90_degree(d);

    for (int i = 0; i < e.size(); i++) {
        for (int j = 0; j < e[i]. size(); j++) {
            cout << e[i][j] << " ";
        }
        cout << endl;
    }

    return 0 ;
}

[Algorithm][Template] 소수의 판별

zerone — Thu, 20 Jan 2022 15:28:54 +0900

1. 가장 기본적인 소수 판별

- 시간복잡도 : O(N)

#include <iostream>
#include <vector>

using namespace std;

int x;

bool isPrime(int x) {
    for (int i = 2; i < x; i++) {
        if (x % i == 0) {
            return false;
        }
    }
    return true;
}

int main(void) {
    cin >> x;

    cout << isPrime(x) << endl;

    return 0 ;
}

2. 성능을 높인 소수 판별

- 시간복잡도 : O(sqrt(N))

#include <iostream>
#include <vector>
#include <cmath>

using namespace std;

int x;

bool isPrime(int x) {
    for (int i = 2; i <= sqrt(x); i++) {
        if (x % i == 0) {
            return false;
        }
    }
    return true;
}

int main(void) {
    cin >> x;

    cout << isPrime(x) << endl;

    return 0 ;
}

2. 에라토스테네스의 체(성능 업그레이드 버전)

- 시간복잡도 : O(N*log(log(N)))

- 다수의 소수를 구할 경우에 사용한다.

- 동작 과정

1) 2부터 N까지의 모든 자연수를 나열한다.

2) 남은 수 중에서 아직 처리하지 않은 가장 작은 수 i를 찾는다.

3) 남은 수 중에서 i의 배수를 모두 제거한다.(i를 제거하지는 않는다, N까지의 i의 배수 제거)

4) 더 이상 반복할 수 없을 때까지 2), 3) 과정을 반복한다.

#include <iostream>
#include <vector>
#include <cmath>

using namespace std;

int n = 1000;
vector<bool> prime(n+1, true);

// 에라토스테네스의 체
void makePrime(int n) {
    for (int i = 2; i <= sqrt(n); i++) {
        if (prime[i]) {
            int j = 2;
            while (i * j <= n) {
                prime[i * j] = false;
                j++;
            }
        }
    }
}

int main(void) {

    makePrime(n);

    // 0, 1 은 소수가 아니다.
    prime[0] = false;
    prime[1] = false;

    for (int i = 0; i <= n; i++) {
        if (prime[i])
            cout << i << " ";
    }
    cout << endl;

    return 0;
}

총정리 : 다수의 소수를 판별할 땐 3번[O(N*log(log(N)))]을, 적은 수의 소수를 판별할 땐 2번[O(sqrt(N))]을 사용하자.

[Algorithm][오답노트][이코테] 45. 최종 순위

zerone — Sun, 16 Jan 2022 20:02:11 +0900

문제

올해 ACM-ICPC 대전 인터넷 예선에는 총 n개의 팀이 참가했다. 팀은 1번부터 n번까지 번호가 매겨져 있다. 놀랍게도 올해 참가하는 팀은 작년에 참가했던 팀과 동일하다.

올해는 인터넷 예선 본부에서는 최종 순위를 발표하지 않기로 했다. 그 대신에 작년에 비해서 상대적인 순위가 바뀐 팀의 목록만 발표하려고 한다. (작년에는 순위를 발표했다) 예를 들어, 작년에 팀 13이 팀 6 보다 순위가 높았는데, 올해 팀 6이 팀 13보다 순위가 높다면, (6, 13)을 발표할 것이다.

창영이는 이 정보만을 가지고 올해 최종 순위를 만들어보려고 한다. 작년 순위와 상대적인 순위가 바뀐 모든 팀의 목록이 주어졌을 때, 올해 순위를 만드는 프로그램을 작성하시오. 하지만, 본부에서 발표한 정보를 가지고 확실한 올해 순위를 만들 수 없는 경우가 있을 수도 있고, 일관성이 없는 잘못된 정보일 수도 있다. 이 두 경우도 모두 찾아내야 한다.

입력

첫째 줄에는 테스트 케이스의 개수가 주어진다. 테스트 케이스는 100개를 넘지 않는다. 각 테스트 케이스는 다음과 같이 이루어져 있다.

팀의 수 n을 포함하고 있는 한 줄. (2 ≤ n ≤ 500)
n개의 정수 ti를 포함하고 있는 한 줄. (1 ≤ ti ≤ n) ti는 작년에 i등을 한 팀의 번호이다. 1등이 가장 성적이 높은 팀이다. 모든 ti는 서로 다르다.
상대적인 등수가 바뀐 쌍의 수 m (0 ≤ m ≤ 25000)
두 정수 ai와 bi를 포함하고 있는 m줄. (1 ≤ ai < bi ≤ n) 상대적인 등수가 바뀐 두 팀이 주어진다. 같은 쌍이 여러 번 발표되는 경우는 없다.

출력

각 테스트 케이스에 대해서 다음을 출력한다.

n개의 정수를 한 줄에 출력한다. 출력하는 숫자는 올해 순위이며, 1등팀부터 순서대로 출력한다. 만약, 확실한 순위를 찾을 수 없다면 "?"를 출력한다. 데이터에 일관성이 없어서 순위를 정할 수 없는 경우에는 "IMPOSSIBLE"을 출력한다.

느낀점

그래프 문제를 풀면서 어렵다고 느낀 부분은 말로 풀어진 문제를 그래프로 스스로 해석하여 풀어내는 사고방식이다.
이 문제는 '정해진 우선순위에 맞게 전체 팀들의 순서를 나열해야 한다'는 점에서 '위상정렬'을 떠올릴 수 있어야 한다.
'각 팀'들을 '노드'로 작년 순위를 토대로 '팀 간 우선순위'를 방향성 간선으로 그린다.
이후 제시해주는 바뀐 팀간 우선순위를 토대로 간선의 방향을 바꿔 그린다.
이후 위상정렬을 통해 그래프를 그릴 수 있는지 확인해본다.
위상정렬은 2가지 주의사항이 있다.
1. 사이클이 발생하는 경우 => 일관성이 없다.
2. 위상정렬의 경우의 수가 2가지 이상인 경우 => 확실한 순위를 찾을 수 없다.

원본문제 : https://www.acmicpc.net/problem/3665

3665번: 최종 순위

올해 ACM-ICPC 대전 인터넷 예선에는 총 n개의 팀이 참가했다. 팀은 1번부터 n번까지 번호가 매겨져 있다. 놀랍게도 올해 참가하는 팀은 작년에 참가했던 팀과 동일하다. 올해는 인터넷 예선 본부에

www.acmicpc.net

#include <iostream>
#include <vector>
#include <queue>
#include <algorithm>

using namespace std;

int t;
int n;
int m;
int indegree[501];
bool graph[501][501];

void topologySort() {
    queue<int> q;

    for (int i = 1; i <= n; i++) {
        if (indegree[i] == 0) {
            q.push(i);
        } 
    }

    vector<int> ans;
    bool not_certain = false;
    bool cycle = false;
    for (int i = 0; i < n; i++) {
        if (q.size() == 0) {
            cycle = true;
            break;
        }
        if (q.size() > 1) {
            not_certain = true;
            break;
        }

        int now = q.front();
        ans.push_back(now);
        q.pop();

        int chk_double = 0;
        for (int j = 1; j <= n; j++) {
            if (graph[now][j]) {
                indegree[j]--;
                if (indegree[j] == 0) {
                    q.push(j);
                }
            }
        }
    }

    if (cycle) {
        cout << "IMPOSSIBLE" << endl;
        return;
    }
    if (not_certain) {
        cout << "?" << endl;
        return;
    }
    
    for (int i = 0; i < n; i++) {
        cout << ans[i] << " ";    
    }
    cout << endl;

}

int main(void) {
    cin >> t;
    for (int i = 0; i < t; i++) {
        cin >> n;

        fill(indegree, indegree+501, 0);
        fill(graph[0], graph[0]+501*501, false);

        vector<int> v;
        for (int j = 0; j < n; j++) {
            int a;
            cin >> a;
            v.push_back(a);
        }

        for (int j = 0; j < n; j++) {
            for (int k = j+1; k < n; k++) {
                graph[v[j]][v[k]] = true;
                indegree[v[k]]++;
            }
        }

        cin >> m;
        for (int j = 0; j < m; j++) {
            int  a, b;
            cin >> a >> b;
            if (graph[a][b]) {
                indegree[a]++;
                indegree[b]--;
            }
            if (graph[b][a]) {
                indegree[a]--;
                indegree[b]++;
            }
            swap(graph[a][b], graph[b][a]);
        }

        topologySort();
    }
    return 0 ;
}

[Algorithm][오답노트][이코테] 42. 탑승구

zerone — Sun, 16 Jan 2022 19:47:07 +0900

문제

공항에는 G개의 탑승구가 있으며, 각각의 탑승구는 1번부터 G번까지 번호로 구분된다. 공항에는 P개의 비행기가 차례대로 도착할 예정이며, $i$ 번째 비행기를 1번부터 $g_{i}$ (1 <= $g_{i}$ <= G) 탑승구 중 하나에 영구적으로 도킹하려 한다. 이 때, 다른 비행기가 도킹하지 않은 탑승구에만 도킹이 가능하다. 또한 P개의 비행기를 순서대로 도킹하다가 만약에 어떠한 탑승구에도 도킹할 수 없는 비행기가 나오는 경우, 그 시점에서 공항의 운행을 중단한다. 공항의 관리자는 최대한 많은 비행기를 공항에 도킹하고자 한다. 비행기를 최대 몇 대 도킹할 수 있는지를 출력해라

입력

첫째 줄에는 탑승구의 수 G(1 <= G <= 100,000)가 주어진다.
둘째 줄에는 비행기의 수 P(1 <= P <= 100,000)가 주어진다.
다음 P개의 줄에는 각 비행기가 도킹할 수 있는 탑승구의 정보 $g$ (1 <= $g$ <= G)가 주어진다. 이는 $i$ 번째 비행기가 1번부터 $g_{i}$ 번째(1 <= $g_{i}$ <= G) 탑승구 중 하나에 도킹할 수 있다는 의미이다.

출력

첫째 줄에 도킹할 수 있는 비행기의 최대 개수를 출력해라.

느낀점

이 문제는 처음에 단순 구현이 떠올랐다. 그래프 카테고리에 있음에도..이 문제는 추가적인 테스트케이스가 제공되지 않아 정답임을 확인할 수는 없었다. 아마 틀렸을 것이다. 그리고 답안을 보니 너무 쉽다.
또한 union-find가 서로소를 판별하기 위한 알고리즘으로 대표적이지만 집합의 제한을 하기에도 사용됨을 깨닫게 해준 문제다.
이 문제를 다시 푼다고 해도 union-find를 떠올릴지 의아하다...
'공항'을 root탑승구를 가진 하나의 '집합'으로 바라보고 하나의 비행기가 탑승구에 집합할 때마다 union 한다.
"더 이상 union할 수 있는 탑승구가 없다 == 0번 탑승구에 도킹해야 한다" 가 나오면 더이상 도킹할 수 없으므로 공항의 운행을 중단한다.

#include <iostream>
#include <vector>

using namespace std;

int g, p;
int parent[100001];

int findParent(int a) {
    if (parent[a] != a) {
        parent[a] = findParent(parent[a]);
    }
    return parent[a];
}

void unionParent(int a, int b) {
    a = findParent(a);
    b = findParent(b);

    if (a < b) {
        parent[b] = a;
    }
    else {
        parent[a] = b;
    }
}

int main(void) {
    cin >> g >> p;

    for (int i = 1; i <= g; i++) {
        parent[i] = i;
    }

    int ans = 0;
    for (int i = 0; i < p; i++) {
        int a;
        cin >> a;
        int root = findParent(a);
        if (root != 0) {
            ans++;
            unionParent(root, root-1);
        }
        else {
            break;
        }
    }

    cout << ans << endl;


    return 0 ;
}

[Algorithm][Template] 위상 정렬(Topology Sort)

zerone — Sat, 15 Jan 2022 18:30:59 +0900

위상정렬이란, 방향 그래프의 모든 노드를 '방향성에 거스르지 않도록 순서대로 나열하는 것'이다.

키 포인트는 '진입차수(indegree)'이다.

1) 진입차수가 0인 노드를 큐에 넣는다.

2) 큐가 빌 때까지 다음의 과정을 반복한다.

2-1) 큐에서 원소를 꺼내 해당 노드에서 출발하는 간선을 그래프에서 제거한다.

2-2) 새롭게 진입차수가 0이 된 노드를 큐에 넣는다.

위상정렬의 시간복잡도는 O(V+E)이다.

차례대로 모든 노드를 확인하면서 해당노드에서 출발하는 간선을 제거한다.

즉, 노드와 간선을 전부 한번씩 탐색한다고 생각하면 된다.

큐에 I/O하는 시간은 V와 같으므로 무시한다.

주의사항은 다음과 같다.

1. 위상정렬 도중, 사이클이 발생할 수도 있다.

2. 위상정렬로 나열한 경우의 수가 2가지 이상일 수 있다.

#include <iostream>
#include <vector>
#include <queue>

using namespace std;

// 노드의 개수(v)와 간선의 개수(e)
// 노드의 개수는 최대 100000개 라고 가정
int v, e;
// 모든 노드에 대한 진입차수는 0으로 초기화
int indegree[100001];
// 각 노드에 연결된 간선 정보를 담기위한 인접 리스트 초기화
vector<int> graph[100001];

// 위상 정렬 함수
void topologySort() {
    vector<int> result; // 알고리즘 수행 결과를 담을 리스트
    queue<int> q; // 진입차수 0인 노드를 넣을 큐


    // 처음 시작할 때는 진입차수 0인 노드를 큐에 삽입
    for (int i = 1; i <= v; i++) {
        if (indegree[i] == 0) {
            q.push(i);
        }
    }

    // 큐가 빌때까지 반복
    while (!q.empty()) {
        // 큐에서 원소 꺼내기
        int now = q.front();
        q.pop();
        result.push_back(now);

        // 해당 원소와 연결된 노드들의 진입차수에서 1 빼기
        for (int e : graph[now]) {
            indegree[e]--;    
            // 새롭게 진입차수가 0이 되는 노드 큐에 삽입
            if (indegree[e] == 0) {
                q.push(e);    
            }
        }
    }

    // 위상 정렬을 수행한 결과 출력
    for (int x: result) {
        cout << x << " ";
    }
    cout << endl;

}

int main(void) {
    cin >> v >> e;
    // 방향그래프의 모든 간선 정보를 입력 받기
    for (int i = 0; i < e; i++) {
        int a, b;
        cin >> a >> b;
        graph[a].push_back(b); // 정점 a에서 b로 이동 가능
        // 진입 차수를 1 증가
        indegree[b] += 1;
    }

    topologySort();

    return 0 ;
}

[Algorithm][Template] 크루스칼 알고리즘

zerone — Mon, 3 Jan 2022 23:56:49 +0900

신장트리(Spanning Tree) : 하나의 그래프가 있을 때 모든 노드를 포함하면서 사이클이 존재하지 않는 부분 그래프

크루스칼 알고리즘 : 신장 트리 중에서 최소 비용으로 만들 수 있는 신장 트리를 찾는 알고리즘, Union-FInd를 이용

1) 간선 데이터를 비용에 따라 오름차순으로 정렬한다.

2) 간선을 하나씩 확인하며 현재의 간선이 사이클을 발생시키는지 확인한다.

2-1) 사이클 발생하지 않는 경우 : 최소 신장트리에 포함시킨다.

2-2) 사이클이 발생하는 경우 : 최소 신장트리에 포함시키지 않는다.

3) 모든 간선에 대하여 2번의 과정을 반복한다.

#include <iostream>
#include <vector>
#include <algorithm>
#include <tuple>

using namespace std;

// 노드의 개수(v)와 간선(e)의 개수
// 노드의 개수는 최대 100000개라고 가정
int v, e;
int parent[100001];

// 특정 원소가 속한 집합을 찾기
int findParent(int x) {
     if (parent[x] != x) {
         parent[x] = findParent(parent[x]);
     }
     return parent[x];
 }

// 두 원소가 속한 집합을 합치기
void unionParent(int x, int y) {
    x = findParent(x);
    y = findParent(y);

    if (x < y) {
        parent[y] = x;
    }
    else {
        parent[x] = y;
    }
}

int main(void) {
    vector<tuple<int, int, int> > edge;

    cin >> v >> e;

    // 부모테이블 상에서, 부모를 자기 자신으로 초기화
    for (int i = 1; i <= v; i++) {
        parent[i] = i;
    }

    // union 연산을 각각 수행
    for (int i = 0; i < e; i++) {
        int a, b, d;
        cin >> a >> b >> d;
        edge.push_back(make_tuple(d, a, b));
    }

    // 간선 거리별 오름차순 정렬
    sort(edge.begin(), edge.end()); // greater<int>()

    int sum = 0;
    for (auto t : edge) {
        int a, b, d;
        tie(d, a, b) = t;
        if (findParent(a) != findParent(b)) {
            unionParent(a, b);
            sum += d;
        }
    }
    
    cout << sum << endl;

    return 0 ;
}

유의사항 : template에서 사용한 tuple은 c++11버전에서만 사용할 수 있다.

[Algorithm][Template] 서로소 집합(Disjoint Set), Union-Find

zerone — Sun, 2 Jan 2022 23:50:54 +0900

서로소 집합(Disjoint Set) : 공통 원소가 없는 두 집합

서로소 부분 집합들로 나누어진 원소들을 데이터를 처리하기 위한 자료구조이다.

union과 find 2개의 연사으로 조작할 수 있다.

트리 자료구조로 표현한다.

✔️union-find 방식

1. union(합집합)

1) A와 B의 부모노드 A', B'을 각각 찾는다.

2) A'를 B'의 부모 노드로 설정한다. (if. A' < B')

2. find(부모노드 찾기)

루트 노드 탐색

<1번째 소스 : 수정 전>

#include <iostream>
#include <vector>

using namespace std;

// 노드의 개수(v)와 간선(e)의 개수
// 노드의 개수는 최대 100000개라고 가정
int v, e;
int parent[100001];

// 특정 원소가 속한 집합을 찾기
int findParent(int x) {
    if (parent[x] != x) {
        return findParent(parent[x]);
    }
    return x;
}

// 두 원소가 속한 집합을 합치기
void unionParent(int x, int y) {
    x = findParent(x);
    y = findParent(y);

    if (x < y) {
        parent[y] = x;
    }
    else {
        parent[x] = y;
    }
}

int main(void) {

    cin >> v >> e;

    // 부모테이블 상에서, 부모를 자기 자신으로 초기화
    for (int i = 1; i <= v; i++) {
        parent[i] = i;
    }

    // union 연산을 각각 수행
    for (int i = 0; i < e; i++) {
        int a, b;
        cin >> a >> b;
        unionParent(a, b);
    }

    // 각 원소가 속한 집할 출력
    cout << "각 원소가 속한 집합: ";
    for (int i = 1 ; i <= v; i++) {
        cout << findParent(i) << " ";
    }
    cout << endl;

    // 부모 테이블 내용 출력
    cout << "부모 테이블: ";
    for (int i = 1 ; i <= v; i++) {
        cout << parent[i] << " ";
    }
    cout << endl;

    return 0 ;
}

위의 소스는 노드의 개수(V)이고 union연산의 개수(M)일때, 시간복잡도가 O(VM)이다.

따라서 findParent 함수 부분을 다음과 같이 변경해준다.

int findParent(int x) {
    if (parent[x] != x) {
        parent[x] = findParent(parent[x]);
    }
    return parent[x];
}

수정 후에는 시간복잡도가

이다.

해당 부분의 시간복잡도 증명은 다음에 다루겠다

즉, 최종 소스는 다음과 같다.

<2번째 소스 : 수정 후>

#include <iostream>
#include <vector>

using namespace std;

// 노드의 개수(v)와 간선(e)의 개수
// 노드의 개수는 최대 100000개라고 가정
int v, e;
int parent[100001];

// 특정 원소가 속한 집합을 찾기
int findParent(int x) {
     if (parent[x] != x) {
         parent[x] = findParent(parent[x]);
     }
     return parent[x];
 }

// 두 원소가 속한 집합을 합치기
void unionParent(int x, int y) {
    x = findParent(x);
    y = findParent(y);

    if (x < y) {
        parent[y] = x;
    }
    else {
        parent[x] = y;
    }
}

int main(void) {

    cin >> v >> e;

    // 부모테이블 상에서, 부모를 자기 자신으로 초기화
    for (int i = 1; i <= v; i++) {
        parent[i] = i;
    }

    // union 연산을 각각 수행
    for (int i = 0; i < e; i++) {
        int a, b;
        cin >> a >> b;
        unionParent(a, b);
    }

    // 각 원소가 속한 집할 출력
    cout << "각 원소가 속한 집합: ";
    for (int i = 1 ; i <= v; i++) {
        cout << findParent(i) << " ";
    }
    cout << endl;

    // 부모 테이블 내용 출력
    cout << "부모 테이블: ";
    for (int i = 1 ; i <= v; i++) {
        cout << parent[i] << " ";
    }
    cout << endl;

    return 0 ;
}

[Algorithm][Template] 플로이드 워셜 알고리즘

zerone — Wed, 29 Dec 2021 17:58:52 +0900

문제풀이 전략

- 다익스트라 : 한 지점에서 다른 특정 지점까지의 최단 경로를 구해야 하는 경우

1) 시간복잡도 O(E*logV), 다익스트라를 플로이드처럼 모든 지점에서 모든지점까지의 경로를 구할 경우 더 좋은 시간 성능으로 사용할 수 있을 것이라 예상 O(E*logV*V)

2) 그래프 표현방법 : 인접리스트

3) 문제 접근 방식 : 그리드 알고리즘

- 플로이드 워셜 : 모든 지점에서 다른 모든 지점까지의 최단 경로를 모두 개야 하는 경우

1) 시간복잡도 O(N^3)

2) 그래프 표현방법 : 인접행렬

3) 문제 접근 방식 : 다이나믹 프로그래밍

플로이드 워셜 알고리즘은 코드가 간결하다.

따라서 N이 작고 모든 지점에서 다른 모든 지점까지의 최단경로를 모두 구해야 하는경우 사용하자.

#include <iostream>
#include <vector>
#include <algorithm>

#define INF 1e9

using namespace std;

// 노드의 개수(n), 간선의 개수(m)
int n, m;
int graph[501][501];

int main(void)
{
    cin >> n >> m;

    // 최단거리 테이블 전부 무한대로 초기화
    //fill(graph, graph + 500*500, INF);
    for (int i = 1; i <= 500; i++) {
        fill(graph[i], graph[i]+500, INF);
    }

    // 자기자신으로 가는 거리 0
    for (int i = 1; i <= 500; i++) {
        graph[i][i] = 0;
    }

    // 간선 입력 받아서 세팅
    int s, e, d;
    for (int i = 0; i < m; i++) {
        cin >> s >> e >> d;
        graph[s][e] = d;
    }

    for (int i = 1; i <= n; i++) {
        for (int j = 1; j <= n; j++) {
            for (int k = 1; k <= n; k++) {
                graph[j][k] = min(graph[j][k], graph[j][i] + graph[i][k]);
            }
        }
    }

    for (int i = 1; i <= n; i++) {
        for (int j = 1; j <= n; j++) {
            if (graph[i][j] == INF) {
                cout << "INF ";
            }
            else {
                cout << graph[i][j] << " ";
            }
        }
        cout << endl;
    }

    return 0;
}

[Algorithm][Template] Dijkstra 최단거리 탐색

zerone — Sat, 18 Dec 2021 16:45:07 +0900

Dijkstra 알고리즘을 이론 그대로 구현한 코드다.

시간복잡도는 O(V^2)이다.

#include <iostream>
#include <vector>
#include <algorithm>

#define INF 1e9	// 무한을 의마하는 값으로 10억 설정

using namespace std;

int N, M, start;
vector<pair<int, int> > graph[10001];
int sd[10001];
bool visited[10001] = {false};

int getSmallestNode() {
	int min_value = INF;
	int min_index = 0;
	for (int i = 0; i < N; i++) {
		if (!visited[i] && sd[i] < min_value) {
			min_index = i;
			min_value = sd[i];
		}
	}
	return min_index;
}

void dijkstra(int start) {
	// 시작 노드에 대해서 초기화
	sd[start] = 0;
	visited[start] = true;

	for (int i = 0; i < graph[start].size(); i++) {
		sd[graph[start][i].first] = sd[start] + graph[start][i].second;
	}

	for (int i = 0; i < N-1; i++) {
		//현재 노드와 연결된 다른 노드를 꺼내서, 방문 처리
		int now= getSmallestNode();	
		visited[now] = true;

		// 현재 노드의 연겱된 다른 노드를 확인
		for (int j = 0; j < graph[now].size(); j++) {
			int cost = sd[now] + graph[now][j].second;
			
			sd[graph[now][j].first] = min(sd[graph[now][j].first], cost);
		}
	}
	
}

int main(void)
{
	cin >> N >> M;
	cin >> start;

	for (int i = 0; i < M; i++) {
		int s, e, d;
		cin >> s >> e >> d;
		
		graph[s].push_back(make_pair(e, d));
	}	

	// 최단 거리 테이블을 모두 무한으로 초기화
	fill_n(sd, 10001, INF);
	
	// 다익스트라 알고리즘 수행
	dijkstra(start);

	for (int i = 1; i <= N; i++) {
		// 도달할 수 없는 경우, 무한(INFINITY)이라고 출력
		if (sd[i] == INF)
			cout << "INFINITY" << endl;
		else
			cout << sd[i] << endl;
	}

	return 0;
}

Dijkstra 알고리즘을 우선순위 큐를 이용해 시간복잡도를 줄인 코드다.

우선순위 큐에 pair를 넣으면 pair의 first 값으로 내림차순 정렬을 하므로 pair의 first 값으로 노드간 거리 * -1 (-cost)을 넣어서 정렬한다. 그리고 pair의 second 값으로 도착 노드를 넣는다.

우선순위 큐에서 최단거리 노드를 뽑아 최단거리를 탐색한다.

시간복잡도는 O(Elog(V))이다.

1번보다 2번의 시간복잡도가 좋으므로 2번 코드만 보면 될 것 같다.

#include <iostream>
#include <vector>
#include <queue>
#include <algorithm>
#include <utility>

#define INF 1e9

using namespace std;

int n, m, start;
vector<pair<int, int> > graph[10001];
int sd[100001];

void dijkstra(int start) {
    priority_queue<pair<int, int> > pq;

    // 시작 노드 거리 0 으로 우선순위 큐에 삽입
    pq.push(make_pair(0, start));
    sd[start] = 0;
    while(!pq.empty()) {
        // 가장 최단거리가 짧은 노드 뽑기
        int dist = -pq.top().first;
        int now = pq.top().second;
        pq.pop();

        // 처리된 적이 있는 노드 무시
        if (sd[now] < dist) continue;
        
        // 현재 노드와 연결된 다른 인접한 노드들을 확인
        for (int i = 0; i < graph[now].size(); i++) {
            int cost = dist + graph[now][i].second; // sd[now] == dist
            // 현재 노드를 거쳐서, 다른 노드로 가는 거리가 더 짧은 경우
            if (cost < sd[graph[now][i].first]) {
                sd[graph[now][i].first] = cost;
                pq.push(make_pair(-cost, graph[now][i].first));
            }
        }
    }
}

int main(void) 
{
    cin >> n >> m >> start;

    int s, e, d;
    for (int i = 0; i < m; i++) {
        cin >> s >> e >> d;
        graph[s].push_back(make_pair(e, d));
    }
       // 최단 거리 테이블을 모두 무한으로 초기화
    fill(sd, sd + 100001, INF);
    
    // 다익스트라 알고리즘을 수행
    dijkstra(start);

    // 모든 노드로 가기 위한 최단 거리를 출력
    for (int i = 1; i <= n; i++) {
        // 도달할 수 없는 경우, 무한(INFINITY)이라고 출력
        if (sd[i] == INF) {
            cout << "INFINITY" << '\n';
        }
        // 도달할 수 있는 경우 거리를 출력
        else {
            cout << sd[i] << '\n';
        }
    }

    return 0;
}

[C++][STL] set과 unordered_set의 차이

zerone — Thu, 11 Nov 2021 23:19:02 +0900

set

키들을 이진 탐색 트리를 기반으로 저장한다. 따라서 자동 정렬되는 컨테이너이고 탐색 시간은 O( log n ) 입니다. 삽입과 제거가 빈번해지면 느리다.

undorderd_set

해쉬 테이블 기반으로 저장한다. 어떤 해쉬를 쓰느냐에 따라 다르겠지만, 같은 해쉬값을 중복적으로 저장한다면 최대 O(n)의 시간복잡도를 갖는다. 따라서 탐색시간이 기본적으론 O(1) 이지만 최악의 경우 O(n) 입니다. 자동 정렬되지 않는 set이다. 버킷 때문에 메모리 사용량이 증가할 수 있다.

결론 : 알고리즘 문제의 경우 최악의 복잡도가 중요하므로 기본 set을 이용하여 풀자. (이진탐색의 경우 set을 쓰면 좋다.)

[C++][STL] Hash Set

zerone — Thu, 21 Oct 2021 21:06:26 +0900

Set은 중복을 찾기에 최적화된 자료구조다.

#include <unordered_set>                // 0. include the library

int main() {
    // 1. initialize a hash set
    unordered_set<int> hashset;   
    // 2. insert a new key
    hashset.insert(3);
    hashset.insert(2);
    hashset.insert(1);
    // 3. delete a key
    hashset.erase(2);
    // 4. check if the key is in the hash set
    if (hashset.count(2) <= 0) {
        cout << "Key 2 is not in the hash set." << endl;
    }
    // 5. get the size of the hash set
    cout << "The size of hash set is: " << hashset.size() << endl; 
    // 6. iterate the hash set
    for (auto it = hashset.begin(); it != hashset.end(); ++it) {
        cout << (*it) << " ";
    }
    cout << "are in the hash set." << endl;
    // 7. clear the hash set
    hashset.clear();
    // 8. check if the hash set is empty
    if (hashset.empty()) {
        cout << "hash set is empty now!" << endl;
    }
}

[Algorithm][Template] Divide and Conquer

zerone — Wed, 20 Oct 2021 20:43:02 +0900

분할정복 template

Type divide_and_conquer( S ) {
    // (1). Divide the problem into a set of subproblems.
    [S1, S2, ... Sn] = divide(S)

    // (2). Solve the subproblem recursively,
    //   obtain the results of subproblems as [R1, R2... Rn].
    rets = [divide_and_conquer(Si) for Si in [S1, S2, ... Sn]]
    [R1, R2,... Rn] = rets

    // (3). combine the results from the subproblems.
    //   and return the combined result.
    return combine([R1, R2,... Rn])

}

[Algorithm][Template] Backtracking

zerone — Wed, 20 Oct 2021 20:39:36 +0900

Backtracking 전용 template

Type backtrack(candidate) {

    if find_solution(candidate):
        output(candidate)
        return
    
    // iterate all possible candidates.
    for next_candidate in list_of_candidates:
        if is_valid(next_candidate):
            // try this partial candidate solution
            place(next_candidate)
            // given the candidate, explore further.
            backtrack(next_candidate)
            // backtrack
            remove(next_candidate)

}

[Algorithm][Leetcode] 208. Implement Trie (Prefix Tree)

zerone — Sun, 17 Oct 2021 23:22:06 +0900

Trie를 c++로 구현해봤다.

원문 : https://leetcode.com/problems/implement-trie-prefix-tree/

트라이(Trie) : 문자열을 저장하고 효율적으로 탐색하기 위한 트리 형태의 자료구조이다.
자식으로 a-z까지 TreeNode들과 문자의 끝을 표시하는 end flag를 갖는다.

class TrieNode {
private:
    bool endFlag;
    TrieNode* next[27 + 'a'];
public:
    TrieNode() {
        endFlag = false;
        memset(next, NULL, sizeof(next));
    }

    TrieNode* getNext(char c) {
        return next[c];
    }

    void setNext(char c) {
        next[c] = new TrieNode();
        // setEndFlag(false);
    }

    bool getEndFlag() {
        return endFlag;
    }

    void setEndFlag(bool endFlag) {
        this->endFlag = endFlag;
    }
};

class Trie {
private:
    TrieNode* root;
public:
    Trie() {
        root = new TrieNode();
    }

    void insert(string word) {
        TrieNode* node = root;
        for (char c : word) {
            if (node->getNext(c)) {
            }
            else {
                node->setNext(c);
            }
            node = node->getNext(c);
        }
        node->setEndFlag(true);
    }

    bool search(string word) {
        TrieNode* node = root;
        for (char c : word) {
            if (node->getNext(c)) {
                node = node->getNext(c);
            }
            else {
                return false;
            }
        }
        return node->getEndFlag();
    }

    bool startsWith(string prefix) {
        TrieNode* node = root;
        for (char c : prefix) {
            if (node->getNext(c)) {
                node = node->getNext(c);
            }
            else {
                return false;
            }
        }
        return true;       
    }
};

/**
 * Your Trie object will be instantiated and called as such:
 * Trie* obj = new Trie();
 * obj->insert(word);
 * bool param_2 = obj->search(word);
 * bool param_3 = obj->startsWith(prefix);
 */

[C++][STL] sort

zerone — Mon, 4 Oct 2021 12:04:49 +0900

LeetCode : Sort an Array 문제를 풀다가 의문점이 생겼다.

제약조건은 다음과 같다.

1 <= nums.length <= 5 * 10^4
-5 * 104 <= nums[i] <= 5 * 10^4

즉, nlog(n)으로 sorting해야하는 간단한 문제다.

근데 C++의 STL인 sort는 내부적으로 quick sort를 사용한다는데 어떻게 STL을 사용해 통과했을까?

quick sort는 최악의 경우 O(N^2)이다.

당연히, merge sort 같은 O(Nlog(N))을 사용해야할 줄 알았다.첫번째 풀이 merge sort다.

class Solution {
    public:
    void mergeSort(vector<int>& nums, int s, int e) {
        if (s != e) {
            int mid = (s+e)/2;
            mergeSort(nums, s, mid);
            mergeSort(nums, mid+1, e);
            merge(nums, s, mid, e);
        }
    }
    void merge(vector<int>& nums, int s, int m, int e) {
        int i = s;
        int j = m+1;
        int k = e;
        vector<int> tmp;
        while(i <= m && j <= e) {
            if (nums[i] < nums[j]) {
                tmp.push_back(nums[i++]);
            }
            else {
                tmp.push_back(nums[j++]);
            }
        }

        while (i <= m) {
            tmp.push_back(nums[i++]);
        }
        while (j <= e) {
            tmp.push_back(nums[j++]);
        }

        for (int i = s; i <= e; i++) {
            nums[i] = tmp[i-s];
        }
    }

    vector<int> sortArray(vector<int>& nums) {
        mergeSort(nums, 0, nums.size()-1);
        return nums;
    }
};

Runtime: 133 ms

두번째 풀이, sort STL이다.

class Solution {
    public:
    vector<int> sortArray(vector<int>& nums) {
        sort(nums.begin(), nums.end());
        return nums;
    }
};

Runtime: 22 ms

성공했다. 심지어 시간도 훨씬 빠르다.

테스트 케이스도 1~50000의 정렬된 vector를 넣어봤다.

왜 되는 걸까?

내부적으로, sort는 단순히 quick sort가 아니라 최악의 경우를 대비한 로직이 있다고 한다.

따라서 문제풀때는 닥치고 sort쓰면 된다.

[Algorithm][LeetCode] 1293. Shortest Path in a Grid with Obstacles Elimination

zerone — Tue, 28 Sep 2021 23:20:00 +0900

처음으로 leetcode hard 문제를 풀었다.

BFS와 Memoization을 적용한 풀이다.

초반엔 구조체 만들어서 풀었지만, tuple과 tie라는 STL을 적용하니 훨씬 깔끔해졌다.

그리고 {}를 이용해 데이터를 묶어주면 tuple, vector형식으로 자동 변환해준다.

시간복잡도는 m * n * k, 즉 40*40*1600이다.

class Solution {
public:
    int shortestPath(vector<vector<int>>& grid, int k) {
        vector<vector<vector<int>>> dp;       
        dp.assign(41, vector<vector<int>>(41, vector<int>(1601, 0)));
        
        int ms = grid.size(); 
        int ns = grid[0].size();
        int rb, cb, kb;
        int cnt = 0;
        
        queue<tuple<int, int, int> > q;
        q.push({0, 0, k});
        
        while (!q.empty()) {
            tie(rb, cb, kb) = q.front();
            q.pop();
            int nb = dp[rb][cb][kb];
            
            if (rb == ms-1 && cb == ns-1) {
                continue;
            }
            if (rb < ms-1) {
                if (grid[rb+1][cb] == 1 && kb > 0) {
                    if (!dp[rb+1][cb][kb-1]) {
                        dp[rb+1][cb][kb-1] = nb+1;                     
                        q.push({rb+1, cb, kb-1});
                    }
                }
                else if (grid[rb+1][cb] == 0) {
                    if (!dp[rb+1][cb][kb]) {
                        dp[rb+1][cb][kb] = nb+1;
                        q.push({rb+1, cb, kb});
                    }
                }
            }
            if (cb < ns-1) {
                if (grid[rb][cb+1] == 1 && kb > 0) {
                    if (!dp[rb][cb+1][kb-1]) {
                        dp[rb][cb+1][kb-1] = nb+1;
                        q.push({rb, cb+1, kb-1});                        
                    }
                }
                else if (grid[rb][cb+1] == 0) {
                    if (!dp[rb][cb+1][kb]) {
                        dp[rb][cb+1][kb] = nb+1;
                        q.push({rb, cb+1, kb});                        
                    }
                }
            }
            if (rb > 0) {
                if (cb == 0)
                    continue;
                if (grid[rb-1][cb] == 1 && kb > 0) {
                    if (!dp[rb-1][cb][kb-1]) {
                        dp[rb-1][cb][kb-1] = nb+1;
                        q.push({rb-1, cb, kb-1});                        
                    }
                }
                else if (grid[rb-1][cb] == 0) {
                    if (!dp[rb-1][cb][kb]) {
                        dp[rb-1][cb][kb] = nb+1;
                        q.push({rb-1, cb, kb});
                    }
                }
            }
            if (cb > 0) {
                if (rb == 0)
                    continue;
                if (grid[rb][cb-1] == 1 && kb > 0) {
                    if (!dp[rb][cb-1][kb-1]) {
                        dp[rb][cb-1][kb-1] = nb+1;
                        q.push({rb, cb-1, kb-1});                        
                    }
                }
                else if (grid[rb][cb-1] == 0) {
                    if (!dp[rb][cb-1][kb]) {
                        dp[rb][cb-1][kb] = nb+1;
                        q.push({rb, cb-1, kb});                        
                    }
                }
            }
        }
        
        int mini = 1601;
        for (int i = 0; i < 1601; i++) {
            if (dp[ms-1][ns-1][i] != 0)
                mini = min(mini, dp[ms-1][ns-1][i]);
        }
        
        if (ms == 1 && ns == 1)
            return 0;
        
        if (mini != 1601)
            return mini;
        else
            return -1;
    }
};