7.2. 인터페이스의 분리와 자기참조 빈 & 7.3. 서비스 추상화 적용

SQL을 읽어오는 작업을 시작해보자.

 

SqlService라는 인터페이스를 만들고 구현하면 끝일까?

 

이는 인터페이스를 사용하는 척만 하고 구현체에 방대한 서브시스템을 몰아넣게 될 것이다.

 

변화를 위한 준비 : 인터페이스 분리

1) XML에서 SQL 데이터를 가져오고

2) HashMap 맵 오브젝트에 저장을 해두는

XmlSqlService를 잘 만들었다.

 

하지만, 스프링의 유연한 확장구조를 경험한 개발자라면 당연히 수정을 해야한다.

 

만약, XML 대신 다른 포맷의 파일에서 SQL을 읽어온다면? XmlSqlService를 뜯어 고쳐야 한다.

 

다른 ...SqlService를 똑같이 만든다면 코드의 중복이 일어날테고, 그렇다고 XmlSqlService를 뜯어고치는 것도 잘못된 방법이다. 왜냐하면 수정되는 이유가 현재 1), 2) 두가지 이기 떄문에 단일 책임 원칙에 위배된다.

서로 변하는 시기와 성질이 다른 것, 변하는 것과 변하지 않는 것을 함께 두는건 바람직한 설계구조가 아니다. 서로 관심이 다른 코드들은 분리하고, 서로 코드에 영향을 주지 않으면서 유연하게 확장 가능 하도록 DI를 적용해보자.

책임에 따른 인터페이스 정의

SqlService는 크게 2가지 책임으로 나눌 수 있다.

이 코드에서 불편한 점을 찾아보자. 

• XML을 읽어오는 경우 Jaxb에서 만들어준 SQL 클래스가 리턴 될 것이다. 이는 특정 기술에 종속되는 코드이기 때문에 범용으로 사용할 수 있는 Map으로 변환을 해주었다.

자기 참조 빈으로 시작하기

이제 세가지 관심과 책임을 분리해야 한다.

클래스의 코드는 단지 인터페이스에 대해서만 알고 있고, 인터페이스를 통해서만 의존 오브젝트에 접근해야 한다.

 

일단 3가지 책임을 분리하기 위해 준비 작업인 3가지 인터페이스를 만들어 기존 클래스가 implement 하도록 수정을 해보자. 코드가 분리되진 않았지만 일단 기능을 직접 접근하지 않고 인터페이스를 통해 간접적으로 사용하도록 변경되었다.

아래와 같이 자기 자신을 참조하는 것은 일반적인 형태는 아니지만, 일단 유연한 구조를 만들기 위해 리팩토링의 첫 시도라 보면 된다.

 

확장 가능한 기반 클래스

서비스 추상화 적용

아직 개선해야 할 부분이 남아있다.

• 자바에는 JAXB 외에도 다양한 XML과 자바오브젝트를 매핑하는 기술이 있다.
• XML 파일을 좀 더 다양한 소스에서 가져올 수 있게 만들어야 한다.