지난 고민에서 내린 결론은 user와 team의 관계를 저장하는 userTeam을 서비스 계층에서 생성하고 플러시 하는 방식이다.
하지만 이 방법은 객체지향적이지 못하다는 생각이 들어 더 좋은 방법을 계속 고민했다.
성능도 좋으면서 객체지향적인 코드에 대한 고민을 계속한 끝에 내린 결론은
지금 너무 객체지향적인 코드에 집착하고 있다는 것이다.
객체지향적인 코드를 작성하는 것은 물론 중요하다.
객체지향적인 코드가 주는 장점은 너무나 많다.
그러나 객체지향적인 코드는 결국 목적이 아니라 도구이다.
객체지향은 더 효율적으로 일하기 위한 도구이고 다른 도구를 쓰더라도 중요한 것은 목적을 달성하는 것이다.
나는 지금 더 효율적인 코드를 찾았음에도 이 방식은 객체지향이라는 도구를 쓰지 않았다는 이유로 더 고민하고 있었다.
진짜 중요한 것은 어떤 도구를 사용하던 목적을 달성하는 것인데 말이다.
그리고 user와 team의 객체 그래프 탐색에 집착하고 있었다.
책에서 객체 그래프 탐색이 원활하게 하는 것이 좋다고 하였다.
그래서 user와 team 의 멤버로 userTeams 를 추가하여 사용했다.
그리고 이 데이터 동기화를 위해 setter 메서드를 어떻게 작성할지 많이 고민했다.
그러나 user와 team 에서 userTeam을 접근하는 양방향 관계가 정말 필요한 것인가에 대해 고민해보지 않았다.
user와 team에서 getUserTeam을 하지 않는다면 양방향 관계가 필요하지 않다.
그럼 userTeams 를 멤버로 사용하지 않아도 되고 데이터 동기화를 위해 setter 메서드를 고민하지 않아도 된다.
결론
가끔 방법에 집착하여 목적을 까먹는 경우가 있다.
항상 내가 하는 행위의 목적을 생각하며 그 목적을 위해 진짜 필요한 고민을 하자
