[3.4.1] JdbcContext의 분리, [3.4.2] 코드를 이용하는 수동 DI

[sootudio]

3.4.1 장을 보면 jdbcContextWithStatementStrategy()를 다른 Dao에서도 사용하게 하기 위해 JdbcContext라는 클래스를 만들어 아래 그림처럼 UserDao와 분리시킵니다.

해당 방식을 사용하면 다른 Dao에서 JdbcContext를 사용하려고 해도, 싱글톤 패턴으로 만들어진 하나의 객체를 계속 돌려 쓰는(?) 것이기 때문에 기존의 클래스를 분리하는 이유에 부합하다고 생각했습니다.

하지만 3.4.2 장의 [코드를 이용하는 수동 DI] 파트에 가면 UserDao 내부에서 직접 DI를 적용하는 방법을 사용함으로써 DAO마다 하나의 JdbcContext 오브젝트를 갖고 있게 한다고 나와 있습니다.

제가 이해했을 때는 해당 상황대로라면 DAO마다 각각의 JdbcContext가 다른 객체로 만들어져, 기존에 클래스를 분리하기 전과 다를 바가 없어진 것 같아서... 기존 상황(UserDao와 jdbcContextWithStatementStrategy() 가 분리되기 전) 과 비교하여 수동 DI를 사용하는 부분이 정확히 어떤 이점들이 있는지 궁금합니다.

[hj-k66]

UserDao와 jdbcContextWithStatementStrategy() 가 분리되기 전과 비교하여 수동 DI를 사용하는 부분은 코드 재사용성 측면에서 이점이 있다고 생각합니다.

만약 UserDao와 jdbcContextWithStatementStrategy()가 분리되지 않은 상태에서, CommentDao라는 다른 DAO가 존재한다고 가정하겠습니다.

CommentDao에서는 댓글 조회, 삭제, 생성 기능 등이 있어 DB와 connection을 생성하고 sql문을 실행하는 등 일반적인 JDBC 작업 흐름을 사용합니다. 이를 위해 UserDao에 정의된 jdbcContextWithStatementStrategy()를 CommentDao클래스 내부에 동일하게 또 정의해서 사용해야하는 문제점이 있습니다.

반면, JdbcContext클래스로 분리하여 수동 DI를 하면 DAO마다 각각의 JdbcContext가 다른 객체로 만들어지지만 위 문단과 같이 동일한 코드를 또 정의하는 문제는 발생하지 않기 때문에 코드 재사용성 측면에서 효율적이다라고 생각합니다!

[gmelon]

저도 희정님 댓글과 동일하게 이해했습니다. 여러 DAO에서 사용되는 반복적인 코드가 한 클래스로 뭉쳐져서 반복 코드의 수정에 대응하기도 용이해졌다고 생각했습니다.

추가로 3.5절 템플릿-콜백 패턴 예제에서 콜백 오브젝트의 생성 (client) 로직을 JdbcContext로 옮기게 되면서 중복되는 콜백 익명 클래스 생성을 하나의 클래스에서 처리할 수 있게 되어 템플릿-콜백 패턴을 적용하기 더 적합한 구조로 변경되었다고 생각합니다.