스프링으로 개발을 하다보면, api response 객체에는 굳이 담을 것이 없지만 이 api가 성공적인 동작을 했다는것은 클라이언트에게 알려야할 수도 있다. 이럴때는 어떤식으로 만들어야 할까? 보통 API response를 그대로 쓰는 경우, 혹은 이것을 살짝만 매핑해서 쓰는 경우가 많을텐데 이럴때는 응답을 안 보낼수도 없고, 보내야만 한다. public ResponseEntity insertUser(Request request) { // ... if(request.id == null) return new ResponseEntity(HttpStatus.NO_CONTENT); // 오류 메시지도 같이 던지면 좋을거같다. return new ResponseEntity(HttpStatus.OK); } 이렇게..

scope dependency 하위에 포함되는 항목 해당 dependency가 포함되는 범위에 대한 타입 scope 종류 compile : 기본 scope. 미입력시에도 기본 적용 모든 상황에서 포함됨 provided : compile과 유사하게 모든 상황에서 수행된다 하지만, 다른 외부 컨테이너에서 기본 제공되는 API인경우 provided로 지정 시 마지막 패키징할 때 포함되지 않음 예를 들면 tomcat에서 기본적으로 servlet api를 제공하기 때문에 servlet api를 provided로 지정하면 패키징시 제외된다. runtime : 컴파일 시에는 불필요 실행시에 필요한 경우. 런타임 및 테스트 시 classpath에 추가 되지만, 컴파일시에는 추가 되지 않음 test : 테스트시에만 사용..

템플릿 메서드 패턴 - 상속을 통해 기능을 확장해서 사용하는 부분이다. 변하지 않는 부분은 슈퍼클래스에 두고 변하는 부분은 추상 메소드로 정의해둬서 서브클래스에서 오버라이드하여 새롭게 정의해 쓰도록 하는것이다. 단점 : 접근 제한이 많다. 로직마다 상속을 통해 클래스를 만들어야 한다. 관계에 대한 유연성이 떨어진다. 전략 패턴 - 개방 폐쇄 원칙(OCP)를 잘 지키는 구조이면서도 템플릿 메소드 패턴보당 유연하고 확장성이 뛰어난 것이, 오브젝트를 아예 둘로 분리하고 클래스 레벨에서는 인터페이스를 통해서만 의존하도록 만드는 전략 패턴이다. OCP 관점에 보면 확장에 해당하는 변하는 부분을 별도의 클래스로 만들어 추상화된 인터페이스를 통해 위임하는 방식이다. 필요에 따라 컨텍스트는 그대로 유지하면서 전략을 바..