[토비의 스프링] 1.2 DAO의 분리

1.2 DAO의 분리

• 변수나 오브젝트 필드의 값은 그대로지만 오브젝트에 대한 설계와 이를 구현한 코드가 변함 = 소프트웨어는 끊임없이 변함
• 미래를 어떻게 대비할 것인가를 항상 염두! -> 분리와 확장을 고려한 설계
• 관심이 한 곳에 집중되도록 해야함 -> 관심사의 분리

UserDao의 관심사항

• add() 매소드와 get() 메소드의 중복 코드를 확인하여 하나의 메소드로 추출
• DB 종류와 접속 방법이 바뀌었을 경우 getConnection() 메소드만 수정하면 됨

변경사항에 대한 검증: 리팩토링과 테스트

• 중복된 코드를 추출하는 과정처럼 기능에는 영향이 없이 코드의 구조를 간결하게 변화하는 과정 = 리팩토링

DB 커넥션 만들기의 독립

• UserDao 소스코드를 제공하지 않고도 고객이 원하는 DB 커넥션 생성 방식을 적용할 수 있을까?
• 상속을 통한 확장
  • DB 커넥션 연결이라는 관심을 상속을 통해 서브클래스로 분리
  • UserDao: add(), get(), getConnection()
  • NUserDao: getConnection()
  • DUserDao: getConnection()
• 템플릿 메소드 패턴(Template Method Pattern): 슈퍼클래스의 기능을 확장할 때 사용하는 가장 대표적인 방법
  • 슈퍼클래스에 기본 로직흐름을 만들고, 서브클래스에서 각 메소드를 필요에 맞게 구현하는 방식
  • 전체적으로 동일하면서 부분적으로 다른 구문으로 구성된 메소드의 코드 중복을 최소화하기에 유용
• 팩토리 메소드 패턴(Factory Method Pattern)
  • 서브클래스에서 구체적인 오브젝트 생성 방법을 결정하게 하는 것

소스코드 참고

깃허브