토비의 스프링 - 1. 오브젝트와 의존관계(1)

초난감 DAO

JDBC를 이용하는 작업의 일반적인 순서

• DB 연결을 위한 Connection을 가져온다.
• SQL을 담은 Statement를 만든다
• 만들어진 Statement를 실행한다.
• 조회의 경우 SQL 쿼리의 실행 결과를 ResultSet으로 받아서 정보를 저장할 오브젝트에 옮겨준다.
• 작업 중에 생성된 Connection, Statement, ResultSet 같은 리소스는 작업을 마친 후 반드시 닫아준다.
• JDBC API가 만들어내는 예외를 잡아서 직접 처리하거나, 메소드에 throws를 선언해서 예외가 발생하면 메소드 밖으로 던지게 한다.

UserDao

DAO의 분리

관심사의 분리

개발자가 객체를 설계할 때 가장 염두에 둬야 할 사항은 미래의 변화를 어떻게 대비할 것인가이다. 가장 좋은 대책은 변화의 폭을 최소한으로 줄여주는 것이다. 변화의 폭을 최소화 하기 위한 방법으로는? 분리와 확장을 고려해 설계한다!

• 관심사의 분리(Separation of Cencerns)
  모든 변경과 발전은 한 번에 한 가지 관심사항에 집중해서 일어난다. 변화가 한 가지 관심에 집중돼 일어난다면, 개발자는 한 가지 관심이 한 군데에 집중되게 준비하면 된다. 관심이 같은 것끼리는 모으고, 관심이 다른 것은 따로 떨어져 있게 하는 것이다.
  -> 관심이 같은 것끼리는 하나의 객체 안으로 또는 친한 객체로 모이게, 관심이 다른 것은 가능한 따로 떨어져서 서로 영향을 주지 않도록 분리하자.
• 템플릿 메소드 패턴
  슈퍼클래스에 기본적인 로직의 흐름을 만들고, 그 기능의 일부를 추상 메소드나 오버라이딩이 가능한 protected 메소드 등으로 만들어, 서브 클래스에서 이런 메소드를 필요에 맞게 구현해서 사용하도록 하는 방법.

DAO의 확장

• 클래스의 분리
  • 장점: 관심사와 변화의 성격이 다른 코드를 확실하게 분리할 수 있다.
  • 문제: 어떤 클래스가 사용되고, 사용되는 메소드의 이름이 뭔지 알고 있어야 한다. -> 특정 클래스에 종속되게 된다. -> 자유로운 확장 불가능
• 인터페이스 도입
  • 장점: 클래스를 몰라도 된다. 인터페이스를 통해 원하는 기능만을 사용한다.
  • 문제: 초기에 한 번 어떤 클래스의 오브젝트를 사용할지 결정하는 코드가 남아 있다.
• 관계설정 책임의 분리
  • 장점: 오브젝트간의 관계 설정의 책임을 클라이언트에게 넘긴다. 관심사, 책임의 분리

원칙과 패턴

• 개방 폐쇄 원칙(OCP, Open-Closed Principle)
  클래스나 모듈은 확장에는 열려 있고, 변경에는 닫혀있어야 한다. (ex. UserDao는 DB 연결 방법이라는 기능의 확장에는 열려있다. UserDao 자신의 핵심 기능을 구현한 코드는 외부의 변화에 영향을 받지 않고 유지할 수 있으므로 변경에는 닫혀있다고 할 수 있다.)

높은 응집도와 낮은 결합도

• 높은 응집도
  변화가 일어날 때 해당 모듈에서 변하는 부분이 크다. 모듈의 일부분에만 변경이 일어나도 되는 경우 모듈 전체에서 어떤 부분이 바뀌어야 하는지 파악해야 하고, 그 변경으로 인해 바뀌지 않는 부분이 다른 부분에 영향을 미치지는 않는지 파악해야 하는 수고가 생긴다.
• 낮은 결합도
  책임과 관심사는 다른 오브젝트 또는 모듈과 낮은 결합도, 즉 느슨하게 연결된 형태를 유지하는 것이 바람직하다. 느슨한 연결은 관계를 유지하는 데 꼭 필요한 최소한의 방법만 간접적인 형태로 제공하고, 나머지는 서로 독립적이고 알 필요 없이 만들어주는 것이다.
  결합도가 낮아지면 변화에 대응하는 속도가 높아지고, 구성이 깔끔해지며 확장에 매우 편리하다.
• 전략 패턴
  자신의 기능 맥락에서 필요에 따라 변경이 필요한 알고리즘을 인터페이스를 통해 통째로 외부로 분리시키고, 이를 구현한 구체적인 알고리즘 클래스를 필요에 따라 바꿔서 사용할 수 있게 하는 디자인 패턴.

제어의 역전(IoC)

오브젝트 팩토리

• 팩토리
  객체의 생성 방법을 결정하고, 그렇게 만들어진 오브젝트를 돌려주는 일을 하는 오브젝트를 흔히 팩토리라고 부른다.
  Dao팩토리를 분리했을 때 얻을 수 있는 가장 큰 장점은 애플리케이션의 컴포넌트 역할을 하는 오브젝트와 애플리케이션의 구조를 결정하는 오브젝트를 분리했다는 것이다.

오브젝트 팩토리의 활용

인터페이스의 구현 클래스를 결정하고 오브젝트를 만드는 코드를 별도의 메소드로 뽑아내면, 구현 클래스를 바꿀 필요가 있을 경우에도 딱 한 군데만 수정하면 모든 DAO 팩토리 메소드에 적용된다.

제어권의 이전을 통한 제어관계 역전

제어의 역전이란? 프로그램의 제어 흐름 구조가 뒤바뀌는 것.
일반적으로 프로그램의 흐름은 main() 메소드와 같이 프로그램이 시작되는 지점에서 다음에 사용할 오브젝트를 결정, 생성, 메소드 호출, 다음 사용 메소드 결정 등의 순서가 반복된다. 이런 구조에서 오브젝트는 프로그램 흐름을 결정하거나 사용할 오브젝트를 구성하는 작업에 능동적으로 참여한다.

제어의 역전은 이런 제어 흐름의 개념을 거꾸로 뒤집는 것이다. 오브젝트가 자신이 사용할 오브젝트를 스스로 선택하지 않는다. 생성도 안하고, 어떻게 만들어지고 어디서 사용되는지를 알 수 없다. 모든 제어 권한을 다른 대상에게 위임하기 때문이다. 모든 객체는 위임받은 제어 권한을 갖는 특별한 객체에 의해 결정되고 만들어진다.

제어의 역전은 프레임워크만의 기술이 아니며 범용적으로 사용되는 프로그래밍 모델이다.