1. 인상깊게 배운 점
- 예제에서 DB가 변경될 수 있음을 인지한 것 처럼, 결국에는 좋은 코드를 만드는 일도 실세계에서 언제 어떤 형태로 변경이 일어나는지 잘 이해하는 것⭐이 중요하다는 생각을 하게 됩니다. DDD 이야기가 종종 나오는데 결국 Domain 을 잘 이해하야 좋은 코드를 설계할 수 있다는 개인적인 인사이트를 얻게 됩니다.
- 구현(코드) 또는 설계(모델) 시점의 의존관계와 런타임 의존 관계를 나누어 생각할 수 있어서 의존관계의 개념이 확실히 이해가 되었습니다.⭐⭐
- “그냥 상속은 사용하지 마라” 라는 다소 설득력 없는 말을 종종 접했던 것 같습니다. 상속은 서브클래스에서 슈퍼클래스의 기능을 사용할 수 있는 창구를 열고 있기 때문에 강한 결합을 쉽게 만들 수 있다는 설명을 보고 상속 보다 더 나은 대안이 있다면 상속을 피하자는 결론을 내리게 됩니다.
2. 궁금한 점
- 싱글톤 (디자인)패턴을 구현한 객체는 애플리케이션 전역적인 접근을 허용하는 문제가 있는데 스프링의 싱글톤 빈 역시 동일한 문제를 안고 있는 것이 아닌가요? 어떤 차이점이 있는지 궁금합니다.
- 변경이 일어날 가능성이 적은 의존 오브젝트는 인터페이스로 분리 없이 클라이언트 오브젝트의 코드에 직접 드러나는 경우가 있는 것 같습니다. 의존관계 주입의 세 가지 조건에 “클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지 않는다” 라는 내용이 있는데 모든 빈을 전략 패턴을 사용해 구현할 필요는 없을 것 같다는 생각도 드는데 현업에서 어떻게 사용하시는지 궁금하고, 어떤 의견들을 가지고 계신지 궁금합니다.
3. 예제 코딩(Pull Request)
- #1 초난감 DAO 구현의 시작
- #2 DB 연결 기능 메서드로 추출
- #3 상속 구조(템플릿 메서드 패턴, 팩토리 메서드 패턴)로 DB 연결에 대한 관심사 분리
- #4 DB 연결 기능 별도의 클래스로 분리
- #5 인터페이스 분리 (UserDao 내부에서 인터페이스 참조하도록 수정)
- #6 오브젝트의 관계를 맺는 클라이언트
- #7 UserDao 생성 책임 DaoFactory로 분리
- #8 DaoFactory 내의 ConnectionMaker 생성 중복 코드 분리
- #9 스프링 ApplicationContext에서 DaoFactory 설정 정보로 사용하기
- #10 IoC/DI 사용하여 부가기능(참조 카운팅) 분리하기
- #11 XML을 이용한 설정
- #12 스프링에서 제공하는 DataSource 인터페이스로 전환
4. 좋았던 점
- 초난감 DAO 라는 어색하고 변경에 민감한 코드에서 시작해서 여러 좋은 프로그래밍 원리들을 통해 코드를 리팩토링해 나가는 과정이 집중하기 좋았고, 왜 이렇게 고쳐야하는지 매우 설득력 있게 다가 왔습니다.
- 제가 초등학교 아이들에게 수학을 가르치면서 똑같은 개념을 조금씩 다른 표현으로 알아 들을 때 까지 설명해 줘서 결국 이해하는 걸 본적이 있었는데, 토비의 스프링 책이 마치 그런 느낌입니다. 좋은 개념을 조금씩 다른 표현으로, 다른 관점에서, 반복해서 표현해 주어서 여느 책들이 좋은 개념을 한 번 설명하고 그치는 것 보다 훨신 이해가 깊이 있게 잘 된다는 느낌을 받습니다.
4. 기타 정리
Satellite System/Software Engineer