클래스 구조 고민 - 소규모 기능별 세분화 인터페이스

배경

회원가입 유저 인증 방식이 sms, email 두 가지가 있다. 기존에는 각각의 Handler에서 EmailUtilService, SmsUtilService 를 has-a 관계로 가지고 있었다. 처음 이런 클래스 구조에 대해 의문을 갖게 된 계기는 이런 관계는 테스트하기에 용이하지 않았다는 점이었다. 변경 전 구조에서 mock 테스트를 하려면 세부적인 부분(캐시 데이터 같은 것들)을 검증하지 못했다.

 

 

해결 방법 모색

1. 각 UtilService에 인터페이스를 implements 하기 이렇게 하면 테스트에만 용이한 구조이고 다른 부분에서는 이점을 찾아볼 수 없었다. 관리 해야 할 클래스(대표적으로 인터페이스), 패키지만 늘어나고 테스트 용이성만 가져가는 구조로 판단 된다.
2. 하나의 인터페이스 클래스만 두고 각 UtilService 들이 implements 하기 이 구조는 클래스는 안늘어나지만 유연하지 않은 구조였다. 지금은 각 UtilService 클래스들에 있는 메소드들 성격이 비슷하지만, 해당 인터페이스의 구현체의 성격이 Util인 점을 감안하면 앞으로 추가 될 메소드의 성격이 갈라질 가능성이 많을 예정이라서 유연하지 않은 구조라고 판단 된다.
3. 기능별로 세분화 한 클래스를 UtilService에서 필요 한 기능별로 다중 구현 하기 각 UtillService가 강제적으로 오버라이딩 해야 하는 메소드가 없기 때문에 필요 없는 메소드가 없을 것이다. 그리고 클래스의 기능에 맞게 세부적인 기능을 붙일 수 있어서 유연한 구조가 될 것이고, 테스트도 용이할 것으로 판단 된다.

 

결론

3번 방법을 채택 했다. 클래스 다이어그램은 다음과 같다. 각 handler 가 필요한 기능들을 의존해서 사용할 수 있고 각각 핸들러 테스트도 용이하게 된다.

 

 

그리고 EmailUtilService에만 있는 기능은 EmailUtilService 에 해당 기능을 이중 구현 해서 필요 없는 오버라이드를 막고, 테스트 용이한 유연한 코드가 될 것으로 판단했다.