이번 글에서는 댓글 목록을 조회하는 API를 만들어 보겠습니다. 요청 및 응답은 아래와 같습니다. API 문서 요청 ? 응답 ? 이제 댓글 목록을 가져오는 기능을 구현해봅시다. Repository 테스트 코드 작성

이번엔 전시 상품에 대해서 상세한 정보를 조회하는 API를 만들겠습니다.먼저 API는 아래와 같습니다.문서를 보면 필요한 값들이 매우 많습니다. 이는 DTO 객체에서 문서를 생성하는 부분의 코드가 길어지고, 책임이 많아진다는 것을 의미합니다.따라서 DTO 객체들이 문서

지금까지 해왔던 것과 앞으로 해야할 것을 정리해봅시다.카테고리 목록 구하기상품 목록 구하기프로모션 정보 구하기전시 상세 정보 구하기댓글 목록 구하기지금까지 카테고리, 전시 상품, 프로모션 총 3개의 API를 만들었습니다. 그런데 지금 생각해보면 3개의 도메인으로 이루어

이번엔 프로모션 정보를 조회하는 API를 제작해보겠습니다.프로모션 정보를 조회하는 API 문서를 보면 아래와 같습니다.위의 API를 만들기 위해서 Repository를 작성해보겠습니다.}이 쿼리를 토대로 Repository를 구현해봅시다.응답에 보낼 DTO 객체들을 만

이번엔 상품 목록을 조회하는 API를 만들어봅시다. API 문서 생성 이전에 만들었던 Controller 테스트 코드에서 새로운 API 문서를 명세해 줍시다. > ### ReservationControllerTest /api/displayinfos 경로로 GET

이제부터 실제 API를 개발해보겠습니다.먼저 카테고리 조회 API 입니다. API 문서는 아래와 같습니다.응답으로 값들이 채워져 있지 않은 이유는 실제 코드를 개발하기 전, 테스트 코드로 API 문서를 먼저 생성하기 위해서 아무런 값도 주지 않았기 때문입니다. 우선,

이번 시간엔 스프링부트에 Rest Docs를 설정해보겠습니다.API 문서 관리를 위한 방식으로 Swagger와 Rest Docs를 고민하였는데, Swagger를 이용하여 프로젝트를 만들어보니까 Swagger는 메인 코드에 여러 어노테이션을 통해 API를 문서로 관리하다

원형 패턴은 흔히 프로토타입 패턴이라고 불립니다.프로토타입 패턴이 무엇일까요?생성할 객체의 종류를 명세하는 데에 원형이 되는 예시물을 이용하고, 그 원형을 복사함으로써 새로운 객체를 생성하는 패턴입니다.글로만 읽어서는 쉽게 이해되지 않으니 예시를 보며 이해해봅시다.우선

Dynamic Proxy는 Proxy Factory에 의해 Runtime시 만들어지는 오브젝트이다.Proxy Factory에게 Interface 정보만 제공해주면 해당 Interface를 구현한 클래스의 오브젝트를 자동으로 만들어준다.Dynamic Proxy가 Inte

이번 장에서도 역시 예시 코드를 통해 팩토리 메서드 패턴에 대해 이해해보겠습니다. 우선 팩토리 메서드 패턴이 무엇인지 알아봅시다. 팩토리 메서드 패턴이란? > 객체를 생성하는 인터페이스는 미리 정의하되, 인스턴스를 만들 클래스의 결정은 서브 클래스 쪽에서 내리는

자바에서는 두 객체를 비교할 때 equals( ) 와 hashCode( ) 를 이용하여 비교하게 된다. ( 이들을 이해하기 위해선 동등성과 동일성에 대한 사전 지식이 필요하므로 혹시나 모르신다면 동일성과 동등성이란? 을 참고해주세요 )

동일성과 동등성에 대해 알아보려면 객체가 필요합니다. 간단한 객체를 하나 만들어볼까요? User 클래스 사용자 정보를 담는 클래스를 선언해봅시다. 간단하게 두 개의 필드만 선언했습니다. 이제 이 User 클래스로 동일성과 동등성에 대해 알아봅시다. 동일성?

이번 장에서는 빌더 패턴에 대해 알아봅시다.먼저 빌더 패턴이 무엇인지 알아야겠죠.복합 객체의 생성 과정과 표현 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴입니다.이 역시 이전 패턴 설명에서와 같이 이해가 가질 않는다. 쉽게 빌더

이 글에서는 먼저 추상 팩토리 패턴을 적용하기 전과 후를 나누어 구현함으로써 패턴에 대해 좀 더 이해하고 직접 코드로 비교해보는 방식으로 진행하겠습니다.우선 추상 팩토리 패턴이 무엇인지 알아야겠죠.구체적인 클래스를 지정하지 않고 관련성을 갖는 객체들의 집합을 생성하거나

아래는 TDD를 프로그래머 각자의 습관에 통합시켜 나가는 과정에서 숙고해볼 수 있는 몇 가지 질문들이다. 여기서는 답이나 힌트를 제시하기도 하며, 직접 탐험해볼 수 있도록 답을 남기지 않기도 한다.사실 여기에는 두 가지 질문이 숨어 있다.각 테스트가 다뤄야 할 범위는

구체적인 클래스를 지정하지 않고 관련성을 갖는 객체들의 집합을 생성하거나 서로 독립적인 객체들의 집합을 생성할 수 있는 인터페이스를 제공하는 패턴입니다.복합 객체의 생성 과정과 표현 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴입

개발을 하다보면 많은 요인들이 우리를 깔끔한 코드에서 멀어지게 만든다. 이는 '깔끔한 코드'를 얻는 것 뿐만 아니라, 단순히 동작하는 코드조차 만들기 힘들게 한다. 이럴때 우리가 해야 할 것은 자동화된 테스트로 개발을 주도해 나가는 것이다.테스트 주도 개발은 아주 단순

서블릿과 JSP의 한계 서블릿으로 개발할 때는 뷰(View) 화면을 위한 HTML을 만드는 작업이 자바 코드에 섞여서 지저분하고 복잡했다. 이러한 문제를 JSP를 사용함으로써 뷰를 생성하는 HTML 작업을 깔끔하게 가져가고 동적으로 변경이 필요한 부분에만 자바 코드를

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 빈 사용 -> 소멸 전 콜백 -> 스프링 종료초기화 콜백 : 빈이 생성되고, 의존관계까지 모두 주입됐을 때 실행소멸 전 콜백 : 빈이 소멸되기 직전에 호출인터페이스(Initializi