인프런 커뮤니티 질문&답변
작성한 질문수
SpringBoot Dto를 InnerClass로 작성시 네이밍
작성
·
109
·
수정됨
0
안녕하세요.
Dto를 InnerClass로 작성시 네이밍 규칙에대해 궁금하여 질문드립니다.
예를들어서 UserDto 와 ProductDto가 있다고 하였을때
public class UserDto {
@Builder
@Getter
@NoArgsConstructor
@AllArgsConstructor
public static class Response {
private String name;
private String email;
}
@Getter
@NoArgsConstructor
public static class Request {
private String userId;
}
}
--------------------------------------------------
public class ProductDto {
@Builder
@Getter
@NoArgsConstructor
@AllArgsConstructor
public static class Response {
private String name;
private Integer prise;
private String brand;
}
@Getter
@NoArgsConstructor
public static class Request {
private String productId;
}
}이런식으로 간단하게 Dto가 작성되어있다고 가정했을때 UserDto는 UserDto.Request , UserDto.Response 를 사용할거고 ProdectDto는 ProductDto.Request , ProductDto.Response 를 사용하게 될텐데 Dto의 네이밍을 UserDto.UserRequest, ProductDto.ProductRequest 로 만들지 않고 Request로 명명 가능한지 궁금합니다.
제 생각엔 가능은 할지라도 다른 사람이 보기에 헷갈리지 않을까 싶은데, 검색을 해봐도 많은 사람들이 Request로만 작성을 하는걸 보아하니 될것같기도해서 질문 드립니다.
또한 프로젝트에 예외처리와 Controller의 응답을 확인할 수 있도록 response라는 디렉토리를 만들었는데 혹시나 이 경우 다른 사람들이 헷갈려 할 가능성이 있을까요?? 만약 헷갈려 할 가능성이 있다면 UserDto.UserRequest, ProductDto.ProductRequest 로 작성하는게 맞는 방법일까요?
답변 1
0
안녕하세요, 인프런 AI 인턴입니다.
제공된 정보에는 직접적으로 DTO의 네이밍 규칙에 대한 내용이 포함되어 있지 않아, 일반적인 프로그래밍 관행에 따라 답변드립니다.
DTO를 Inner Class로 작성할 때 UserDto.Request 와 UserDto.Response와 같은 방식으로 네이밍하는 것은 일반적으로 허용되며, 실제로 널리 사용됩니다. 이러한 방식은 코드의 가독성과 유지보수성을 높일 수 있으며, 각 DTO가 속한 도메인을 명확하게 표현해 줍니다. UserDto.UserRequest와 같이 중복되는 이름을 사용하는 것보다는 UserDto.Request의 방식이 더 간결하고 명확합니다.
다만, 네이밍에 있어서 가장 중요한 것은 일관성과 팀 내에서의 합의입니다. 프로젝트나 팀 내에서 사용하는 네이밍 규칙에 따라 결정하는 것이 바람직합니다.
응답 디렉토리의 경우, 디렉토리의 의미와 내용이 명확하다면 크게 혼동될 요소는 없을 것입니다. 하지만, 프로젝트의 구조가 복잡해지거나 팀원 사이에 디렉토리 구조에 대한 충분한 소통이 이루어지지 않는 경우 오해의 소지가 있을 수 있습니다. 이 경우에도 팀 내 커뮤니케이션을 통해 명확히 하거나, 필요하다면 네이밍을 조금 더 구체적으로 변경하는 것도 고려할 수 있습니다.
결국, 네이밍은 코드의 명확성과 가독성을 높이는 동시에, 팀 내에서 충분한 합의가 이루어지는 방향으로 결정하는 것이 좋습니다.