[토비의 스프링] 1.3 DAO의 확장

1.3 DAO의 확장

• 지금까지 데이터 엑세스 로직을 어떻게 만들 것인지, DB 연결을 어떤 방법으로 할 것인지 두 개의 관심을 기준으로 분리
• 두 관심은 변화의 성격이 다름

다른 방식의 분리

• 본격적으로 독립시키며 손쉽게 확장할 수 있는 방식
• SimpleConnectionMaker 클래스를 만들고 UserDao가 이용할 수 있는 방식
  • UserDao 코드가 SimpleConnectionMaker 클래스에 종속되어 있으므로 UserDao 코드 수정 없이 DB 커넥션 변경할 방법이 없음
  • SimpleConnectionMaker의 makeNewConnection을 이름만 변경해도 UserDao를 변경해야함

인터페이스의 도임

• 추상화란?

  • 어떤 것들의 공통적인 성격을 뽑아내어 인터페이스로 분리하는 작업

• 인터페이스

  • 기능만 정의
  • 어떻게 할지는 자신을 구현한 클래스가 담당
  • 자신을 구현한 클래스에 대한 구체적인 정보는 모두 감춤
  • 인터페이스를 사용하는 코드쪽에서는 추상화한 통로만 이해하면 됨

• 여전히 UserDao코드 내에 N사인지 D사 코드가 남아있음

관계설정 책임의 분리

• 어떤 ConnectionMaker 구현 클래스를 사용할지 결정!
• 2개의 오브젝트 A, B 존재 A가 B 오브젝트의 기능 사용
  • B 오브젝트 = 서비스 오브젝트
  • A 오브젝트 = 클라이언트 오브젝트
• UserDao와 ConnectionMaker 구현 클래스 관계를 결정해주는 기능을 분리해서 두기에 가장 적절한 곳
  • UserDao의 클라이언트 오브젝트

원칙과 패턴

• 개방 폐쇄 원칙(OCP, Open-Closed Priciple)
  • 클래스나 모듈은 확장에는 열려있고 변경에는 닫혀있어야 함
  • UserDao는 DB 연결 방법 기능 확장에 열려있지만 자신의 코드는 그런 변화에 영향을 받지않고 유지 가능
• SOLID 5원칙
• 높은 응집도와 낮은 결합도
  • 높은 응집도: 한 모듈 내부 처리 요소들 간 기능적 연관도
  • 낮은 결합도: 모듈간의 상호 의존도 및 연관 관계
• 전략 패턴(Strategy Pattern)
  • 자신의 기능 맥락에서, 필요에 따라 변경한 알고리즘을 인터페이스를 통해 통째로 외부로 분리시키고, 이름 구현한 구체적인 알고리즘 클래스를 필요에 따라 바꿔서 사용할 수 있게 하는 디자인 패턴