1.7) 의존관계 주입(DI) 제어의 역전과 의존관계 주입 초기에는 주로 IoC 컨테이너라고 불리던 스프링이 지금은 의존관계 주입 컨테이너? 객체를 생성하고 관계를 맺어주는 등의 작업을 담당하는 기능을 일반화하는 것이 스프링의 IoC 컨테이너다. 하지만 IoC는 매우 느슨하게 정의돼서 폭넓게 사용되는 용어이므로 스프링을 IoC 컨테이너라고만 해서는 스프링이 제공하는 지능의 특징을 명확하게 설명하지 못한다. 그러므로 스프링이 제공하는 IoC 방식을 좀 더 의도가 명확히 드러나는 의존관계 주입이라는 이름을 사용하기 시작했다. 런타임 의존관계 설정 의존관계란? 두 개의 클래스 또는 모듈이 의존관계에 있을 때는 항상 방향성을 부여하여 누가 누구에게 의존하는 관계여야 한다. 의존한다는 것을 A가 B에 의존하고 있..
1.6) 싱글톤 레지스트리와 오브젝트 스코프 싱글톤 레지스트리로서의 애플리케이션 컨텍스트 DaoFactory의 userDao()를 여러 번 호출했을 때 동일한 오브젝트가 돌아오는가 아닌가? 매번 userDao 메소드를 호출할 때마다 new 연산자에 의해 새로운 오브젝트가 만들어지게 되어 있으므로 당연히 매번 다른 오브젝트가 만들어져서 돌아올 것이라고 예상할 수 있다. 직접 구현한 DaoFactory의 경우 오브젝트가 두 개가 생겼다는 사실을 알 수 있으며 매번 userDao를 호출하면 계속해서 새로운 오브젝트가 만들어질 것이다. 하지만 스프링의 애플리케이션 컨텍스트에 DaoFactory를 설정정보를 등록하고 getBean() 메소드를 이용해 userDao라는 이름으로 등록된 오브젝트를 가져올 경우 가져온..
1.5) 스프링의 IoC 오브젝트 팩토리를 이용한 스프링 IoC DaoFactory를 스프링에서 사용이 가능하도록 변신시켜보자. 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트를 빈이라고 부른다. 동시에 스프링 빈은 스프링 컨테이너가 생성과 관계설정, 사용 등을 제어해주는 제어의 역전이 적용된 오브젝트이다. 그러므로 스프링에서는 빈의 생성과 관계설정 같은 제어를 담당하는 IoC 오브젝트를 빈 팩토리라고 부르며 IoC 방식을 따라 만들어진 일종의 빈 팩토리를 좀 더 확장한 애플리케이션 컨텍스트를 주로 사용한다. 애플리케이션 컨텍스트는 직접 설정정보를 담고 있는 DaoFactory와 달리, 별도로 설정정보를 담고 있는 무엇인가를 가져와 이를 활용하는 범용적인 IoC 엔진 같은 것이라고 볼 수 ..
1.4) 제어의 역전(IoC) 오브젝트 팩토리 하지만 이 때 클라이언트인 UserDaoTest는 UserDao의 기능이 잘 동작하는지를 테스트하려고 만든 것이 아닌가? UserDaoTest는 기존에 UserDao가 담당하던 어떤 ConnectionMaker 구현 클래스를 사용할지를 결정하는 기능을 맡아 UserDao가 ConnectionMaker 인터페이스를 구현한 특정 클래스로부터 완벽하게 독립할 수 있도록 담당하게 되었다. 하지만 UserDaoTest는 테스트를 위한 것이므로 또 다른 책임까지 떠맡고 있으니 문제가 있으므로 분리가 필요하다. 분리시킬 기능을 담당할 클래스인 팩토리를 만들자. 분리될 기능은 UserDao와 ConnectionMaker 구현 클래스의 오브젝트를 만드는 것과 그렇게 만들어진..
1.3) DAO의 확장 클래스의 분리 관심의 변화의 성격(변화의 이유, 시기, 주기)이 다르므로 분리해서, 서로 영향을 주지 않은 채로 각각 필요한 시점에 독립적으로 변경할 수 있게 한다. 그러나 여러가지 단점이 많은, 상속이라는 방법을 사용했다는 사실이 불편하게 느껴진다. 그러므로 서브 클래스가 아니라, 아예 별도의 독립적인 클래스인 SimpleConnectionMaker에 담는다. 그리고 이렇게 만든 클래스를 new 키워드를 사용해 클래스의 오브젝트를 만들어 UserDao가 이용하게 하면 된다. 기존 코드에 많은 수정을 했지만 기능에 변화를 준 것은 없으므로 main() 메소드를 실행하면 결과가 동일하다. /** * 독립시킨 DB 연결 기능인 SimpleConnectionMaker 클래스 */ pub..
1.2) DAO의 분리 관심사의 분리 객체지향의 세계에서는 모든 것이 변한다. 그래서 개발자가 객체를 설계할 때 가장 염두에 둬야 할 사항은 바로 미래의 변화를 어떻게 대비할 것인가이다. 가장 좋은 대책은 변화의 폭을 최소한으로 줄여주는 것이다. 어떻게 변경이 일어날 때 필요한 작업을 최소화하고, 그 변경이 다른 곳에 문제를 일으키지 않게 할 수 있었을까? 그것은 분리와 확장을 고려한 설계가 있었기 때문이다. 변화가 한 번에 한 가지 관심에 집중돼서 일어난다면, 한 가지 관심이 한 군데에 집중되게 하는 것이다. 즉 관심이 같은 것끼리는 모으고, 관심이 다른 것은 따로 떨어져 있게 하는 관심사의 분리를 하는 것이다. 커넥션 만들기의 추출 UserDao의 구현된 메소드를 다시 살펴보자. UserDao의 ad..
1.1) 초난감 DAO User & UserDao 사용자 정보를 JDBC API를 통해 DB에 저장하고 조회할 수 있는 간단한 DAO를 만들어보자. DAO(Data Access Obejct)는 DB를 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 오브젝트이다. 사용자 정보를 저장할 User 클래스를 만든다. 사용자 정보를 저장할 때는 자바빈 규약을 따르는 오브젝트를 이용하면 편리하다. User 오브젝트에 담긴 정보가 실제 보관된 DB의 테이블을 하나 만든다. 사용자 정보를 DB에 넣고 관리할 수 있는 DAO 클래스를 만든다. 그런데 이 클래스가 제대로 동작하는지 어떻게 확인할 수 있을까? /** * 사용자 정보 저장용 자바빈 User 클래스 */ public class User { /* Us..
1.0) 오브젝트와 의존관계 스프링은 자바를 기반으로 한 기술이다. 스프링이 자바에서 가장 중요하게 가치를 두는 것은 객체지향 프로그래밍이 가능한 언어라는 점이다. 스프링은 객체지향 프로그래밍이 제공하는 폭넓은 혜택을 누릴 수 있도록 기본으로 돌아가는 것을 핵심 철학으로 여긴다. 스프링을 이해하려면 먼저 오브젝트에 깊은 관심을 가져야한다. 애플리케이션에서 오브젝트가 생성되고 다른 오브젝트와 관계를 맺고, 사용되고, 소멸하기까지의 전 과정이 있다. 결국 오브젝트에 대한 관심은 오브젝트의 기술적인 특징과 사용 방법을 넘어 오브젝트의 설계로 발전하게 된다. 그러다 보면 자연스럽게 스프링이 무엇인지도 이해될 것이다. 그러므로 무엇을 제공하는지보다는 스프링이 관심을 갖는 대상인 오브젝트에 집중해보자.
