Java 를 공부하다보면 객체지향 설계 5가지 원칙인 SOLID 를 만나게 된다.
이걸 다 지켜야지 라고 생각하고 코드를 작성해오진 않았지만 어느순간부터 왜 이렇게 작성했는가 를 생각하기도 코드리뷰를 받아보기도 하면서 SOLID 원칙을 자주 접하게 되었다.
5가지의 원칙이지만 그중 첫번째 단일책임 원칙 만으로도 많은 고민을 하게 되어서 포스팅하게 되었다.
현재 작업하려는 프로젝트는 일반 유저는 회원가입 등의 절차가 필요하지 않다.
구단주인 유저가 팀을 등록하고 그 팀에 팀원들의 ID 를 입력하면 추가되는 방식이다.
설계 단계부터 팀원을 String 으로 관리할까 Entity 로 관리할까 라는 고민이 생겨서 글을 포스팅 하게 되었다.
우선 팀원은 구단주 또는 관리자에 의해서만 관리되며
회원이 사용되는 기능은
- 팀 정보
- 경기후 결과 입력
- 각 시즌 기록
이렇게 세가지 이며 별도로 로그인을 할 이유도 할수있는 기능도 없다.
하지만 Team 이라는 객체는 팀 만을 관리하고 싶은데 이때 팀원에 대한 정보들을 포함한다면 SRP 를 위반하는것은 아닐까 싶은 생각이 들었고 그렇다고 별도의 기능도 없는 팀원을 Entity 로 빼야하나 라는 생각도 동시에 들어서 무엇이 정답인지 헷갈렸다.
다시 처음으로 돌아가자.
SRP 에 위반 또는 Team Entity 의 책임이 너무 커진다고 생각하여 이게 옳은가 에 대한 고민을 하였다.
가장 단순하게 Member 를 분리하자.
그럼 우선적으로 고민하게된 원인이 사라진다.
하지만 팀원은 본인만의 고유 기능을 가지고있지 않다.
따라서 컨트롤러는 필요하지 않다.
별도의 Entity 와 Service , Repository 만을 생성하여 사용하도록 정하고 그후에 코드를 다시 살펴보기로 했다.
