개요
개발을 하다보면 응답의 반환 값으로 엔티티를 직접 사용하는 경우를 종종 볼 수 있는데요, 왜 많은 개발자들이 엔티로 직접 반환하는 것이 아닌 별도의 응답 클래스를 생성하는지 알아보도록 하겠습니다.
1. 단일 책임 원칙 (SRP)
객체 지향의 5원칙이라고 하면 흔히들 SOLID 를 이야기 합니다. 그 중에서도 단일 책임 원칙은 SOLID의 S를 맡고 있습니다. 그렇다면 응답 클래스를 사용하는 것과 단일 책임 원칙을 준수하는 것이 어떠한 연관 관계를 갖고 있을까요?
예를 들어 설명하겠습니다.
클라이언트는 서버 개발자에게 한가지 요청 사항을 제시합니다. 블로그의 제목을 10글자 미만으로 반환해달라는 것이었습니다.
해당 요구에 따라 서버 개발자는 Post 엔티티에 다음과 같은 작업을 진행했습니다.
public class Post {
String title;
String content;
...
public String getTitle(){
return this.title.substring(0,10);
}
}
Java
복사
하지만, 이러한 방법은 몇 가지 문제점을 가지고 있습니다.
첫째, Post 엔티티의 getTitle 메소드는 원래의 제목을 반환하는 것이 기본적인 책임이어야 하지만, 이제 10글자로 제한하는 추가적인 책임이 생겼습니다. 즉, 단일 책임 원칙(Single Responsibility Principle, SRP)을 위반하게 되었습니다.
둘째, 만약 다른 클라이언트나 서비스에서 전체 제목이 필요한 경우, 현재의 getTitle 메소드를 사용할 수 없게 됩니다. 이렇게 되면 코드의 재사용성이 저하됩니다.
예를 들어 설명하자면 다음과 같습니다.
서버 개발자는 제목을 온전히 반환하는 getRss() 메서드를 정의하였습니다. 하지만 Post 엔티티를 그대로 적용하니 앞 전에 적용했던 getTitle()로 인해 10자 미만의 제목이 반환되고 있습니다.
셋째, 나중에 요구사항이 변경되어 제목의 길이 제한을 변경하거나 제거해야 할 경우, Post 엔티티 클래스를 수정해야 합니다. 이러한 변경이 다른 부분에 영향을 미칠 수 있으며, 유지보수가 어려워집니다.
이러한 문제를 해결하기 위한 응답 클래스는 다음과 같습니다.
public class PostResponse {
String title;
String content;
public PostResponse(Post post) {
this.title = post.getTitle().substring(0, 10);
this.content = post.getContent();
}
public String getTitle() {
return this.title;
}
public String getContent() {
return this.content;
}
}
Java
복사
