작성한 질문수 2

0

관심사라는 것을 어떻게 정의하고 보는지에 따라서 사실 얼마든지 다르게 분리할 수 있습니다. 클래스는 가장 작은 단위의 모듈인데, 이보다 더 큰 패키지나 jar 파일, 서버도 같은 관심사의 분리라는 관점으로 나눌 수가 있죠. 이때의 관심사 단위는 꽤 큽니다.

관심사가 혼재되어있으면 앞으로 코드가 발전하고 변경되고, 나중에 코드를 이해할 때 어떤 불편함이 있을지를 생각해보시면 좋습니다. 사실 예제의 Client 수준에서야 그 정도의 관심사가 섞여 있어도 괜찮아 보입니다. 그래서 저도 처음부터 그걸 나누지 않고 자연스럽게 Client main() 안에 만들었죠. 하지만 책임을 명확하게 구분해보면, 의존관계설정 책임은 대상이 점점 늘어나서 나중에 수백 개가 될 수도 있겠죠. 그게 페이먼트라는 기능 하나를 이용하는 클라이언트, 실전이라면 아마 컨트롤러가 되겠죠. 그 안에 들어가 있으면 이상하겠죠? 그래서 그런 명확한 관심사가 다른 코드는 분리하는 습관을 들이시면 좋습니다. 그렇다고 너무 급하게 하지는 않으셔도 됩니다.

스프링의 @Controller, @Service, @Repository로 대표되는 스테레오타입 애노테이션은, 정말 이건 꼭 분리해야한다는 오래된 경험에서 나온 관심사 분리를 적용할 대상을 명시하도록 하는, 최소한의 작업에 쓰라고 만든 것이죠. 실제로는 이보다 더 자세히, 비즈니스 관점에서 혹은 기능적인 관점에서 관심사가 다르다고 느껴지면 적절한 시점에 분리하는 습관이 중요합니다.

클래스가 그 중에서 가장 기본적인 단위이기 때문에 클래스부터 분리하는 연습을 하면 좋습니다. 리팩터링을 공부하시면 어떤 경우에 클래스를 나누는지, 혹은 인터페이스나 수퍼 클래스로 추출하는지 등에 관한 좋은 아이디어를 얻으실 수 있을 겁니다.