1. 개요
주문/체결 및 백오피스 권한 처리 등 복잡한 비즈니스 로직을 처리할때는 그 특성상 반드시 validate(검증) 선제 과정이 필요하다.
일급 객체, 일급 클래스의 핵심은 결국 재사용성, 그리고 추가적으로 알게된 것은 단일 책임 원칙 즉 하나의 책임만을 수행할 수 있다는 것이다.
나는 일급 객체를 재사용성 관점에서만 생각했는데, 단일책임원칙을 사용하면 로직을 간결하고, 유지보수성을 더 높일 수 있음을 알게 되었다(간결명확하게).
성능개선의 관점보다는 리팩토링 관점에서 알게된 점을 정리한다.
일급 객체 관련 게시글 정리한 내용과 함께 기억하면 좋을 것 같다.
2. 단일 책임 원칙 확보(결합도 완화) 방안
MVC 패턴 뿐만 아니라, 모든 패턴에서 로직을 처리하는 계층은 서비스 계층 혹은 특정되어있는 계층 혹은 특정 컴포넌트(React에서)일 것이다.
그렇다면 그 계층에서 전산 처리를 수행하고자 할 때, 수반해야하는 검증 로직을 한줄 한줄 넣어야 할 것인가, 한줄한줄 넣으면 중복이고 다른 곳에서도 같은 로직이 반복될 것인데,
결론적으로는 어느 책임에 몰아 넣을 것인가, 이제 이 생각을 하면서 작성해야 한다.
예를 들어 권한을 등록하는 서비스가 있다고 하자.
이 권한을 등록하기 위해선
- 권한코드의 중복 여부
- 권한의 직책과 부서의 중복 여부
상기 두가지의 검증을 거쳐야 한다.
이때 리팩토링, 로직 구조화만 생각하지 말고 아예 권한검증이라는 책임을 한 곳에 몰아 넣을 수 있지 않을까는 생각을 해보자.
현재 프로젝트 구조에서 권한에 대한 정보는
1) item
2) list 형태로 받는다.
그렇다면
권한이라는 item
권한리스트라는 list를 각각 일급 객체, 일급 컬렉션화해야 한다.
이걸 생각하다보니까, 지금 프로젝트에서는 DTO를 각 서비스마다 다 개별로 만들었는데..아예 도메인별로 만들어버리면 더 효율적인 구조로 접근할 수 있겠구나라는 생각이 들었다.
public class RoleList {
private final List<T> RoleList;
public RoleList() {
this.RoleList = new ArrayList<>();
} //기본 생성자
public RoleList(List<T> RoleList) {
this.RoleList = RoleList;
} //특정 생성자
public void validateDuplicated() {
for (T role : RoleList) {
if(DTaUserRole.selectByPrimaryKey(role) != null)
throw new Exception //권한 중복
}
} //권한 리스트의 중복을 검증(이 메서드를 실행할 시점에는 이미 생성자로 멤버변수 할당이 완료된 상태)
public void validateJbttlAndDept() {
if (DTaUserRole.selectByPrimaryKey(role) != null || DTaUserRole.selectByPrimaryKey(dept) != null) {
throw new Exception //직책 및 부서 중복
}
} //권한 리스트의 직책과 부서의 중복을 검증
}서비스 계층에서는 RoleList를 그대로 사용해서 저 검증 메서드를 사용해주기만 하면 된다. 더불어 검증하는 메서드들도 private 처리를 통해 안전하게 사용할 수 있게 되었다.
재사용성과 단일 책임 원칙이 서로 밀접한 관련이 있으므로 항상 염두에 두고 사용해야 좋을 것 같다.
**일급 객체는 연산, 매개변수 전달이 가능한 만능 리터럴이다.
