책임의 분리 토비의 스프링을 공부하다보면 계속 나오는 단어가 보이는데 그것이 바로 관심, 책임이다. 관심이란 무엇이고, 책임은 무엇이기에 계속해서 나눠야하는 것이며 분리시켜주어야하는 것일까? 비전공자, 개발 초보의 입장에서는 계속해서 물음표가 이어졌다. 토비의 스프링 책을 보면서 처음부터 다시 정리해보자. 1. 우리는 맨 처음 UserDao에 직접 getConnection이라는 메서드를 만들어 DB와 연결을 시도했다. public class UserDao { /*중복된 코드를 독립적인 메소드로 만들어 중복 제거*/ private Connection getConnection() throws ClassNotFoundException, SQLException { Class.forName("com.mysql.c..

스프링의 IoC 애플리케이션 컨텍스트의 동작 방식 오브젝트 팩토리에서 사용했던 IoC 원리를 그대로 적용하는 데 애플리케이션 컨텍스트를 사용하는 이유는 범용적이고 유연한 방법으로 IoC기능을 확장하기 위해서이다. 오브젝트 팩토리로 직접 사용했을 때와 비교해서 애플리케이션 컨텍스트를 사용했을 때 얻을 수 있는 장점 클라이언트를 구체적인 팩토리 클래스를 알 필요가 없다. 오브젝트 팩토리가 아무리 많아져도 이를 알아야 하거나 직접 사용할 필요가 없다. 일관된 방식으로 원하는 오브젝트를 가져올 수 있다. 애플리케이션 컨텍스트는 종합 IoC 서비스를 제공해준다. 오브젝트가 만들어지는 방식, 시점과 전략을 다르게 가져갈수도 있다. 자동생성, 오브젝트에 대한 후처리, 정보의 조합, 설정방식의 다변화, 인터셉팅 등 오..

스프링의 IoC 오브젝트 팩토리를 이용한 스프링 IoC 애플리케이션 컨텍스트와 설정정보 빈 스프링이 제어권을 가지고 직접 만들고 관계를 주여하는 오브젝트 오브젝트 단위의 애플리케이션 컴포넌트 스프링 컨테이너가 생성과 관계설정, 사용 등을 제어해주는 제어의 역전이 적용된 오브젝트 빈의 생성과 관계설정 같은 제어를 담당하는 IoC 오브젝트를 빈 팩토리라고 부른다. 보통 빈 팩토리보다는 이를 좀 더 확장한 애플리케이션 컨텍스트를 주로 사용 DaoFactory를 사용하는 애플리케이션 컨텍스트 @Configuration 어노테이션 추가 스프링이 빈 팩토리를 위한 오브젝트 설정을 담당하는 클래스라고 인식. 오브젝트를 만들어주는 메소드에 @Bean 어노테이션 추가. UserDao()메소드는 UserDao 타입 오브젝..

제어의 역전 오브젝트 팩토리 활용 어떤 ConnectionMaker 구현 클래스를 사용할지 결정하는 기능이 중복돼서 나타나고 있다. public class DaoFactory { public UserDao userDao(){ return new UserDao(new likelionConnectionMaker()); // ConnectionMaker 구현 클래스를 서언하고 생성하는 코드의 중복 } public AccountDao account(){ return new AccountDao(new likelionConnecionMaker()); // ConnectionMaker 구현 클래스를 서언하고 생성하는 코드의 중복 } } 중복 문제 해결을 위해 분리하는 것이 가장 좋은 방법이다. ```java publ..

IoC 제어의 역전(Inversion of Control) 오브젝트 팩토리 UserDaoTest는 UserDao의 기능이 잘 동작하는지를 테스트하려고 만든 것인데, 다른 책임까지 떠맡고 있으므로 문제가 있다. 이걸 분리하는 작업을 진행한다. 팩토리 객체의 생성 방법을 결정하고, 만들어진 오브젝트를 돌려준다. 이런 일을 하는 오브젝트를 팩토리(factory)라고 부른다. 단지 오브젝트를 생성하는 쪽과 생성된 오브젝트를 사용하는 쪽의 역할과 책임을 깔끔하게 분리하는 목적으로 사용. public class DaoFactory { public UserDao userDao(){ // 팩토리의 메소드는 UserDao 타입의 오브젝트를 어떻게 만들고, 어떻게 준비시킬지 결정. ConnectionMaker connec..

3-2. 인터페이스의 도입 인터페이스는 자신을 구현한 클래스에 대한 구체적인 정보는 모두 감춰버린다. 인터페이스로 추상화해놓은 최소한의 통로를 통해 접근하는 쪽에서는 오브젝트를 만들 때 사용할 클래스가 무엇인지 몰라도 된다. 인터페이스는 어떤 일을 하겠다는 기능만 정의해놓은 것이다. 따라서 인터페이스에서는 어떻게 하겠다는 구현 방법은 나타나 있지 않다. public interface ConnectionMaker { public Connection makeConnection() throws ClassNotFoundException, SQLException; } makeConneciont() 메소드를 호출하면 Connection 타입의 오브젝트를 만들어서 돌려줄 것을 기대할 수 있다. public class..

3.DAO의 확장 데이터 엑세스 로직을 어떻게 만들 것인가, DB 연결을 어떤 방법으로 할 것인가 라는 두 개의 관심을 상하위 클래스로 분리했다. 변화의 성격이 다른 것을 분리, 서로 영향을 주지 않은 채로 각각 필요한 시점에 독립적으로 변경할 수 있게 하기 위해 추상 클래스를 만들고 이를 상속한 서브클래스에서 변화가 필요한 부분을 바꿔 쓸 수 있게 햇다. 하지만 단점이 많은, 상속이라는 방법을 사용했다는 사실이 불편하게 느껴진다. 3-1. 클래스의 분리 상속 관계도 아닌 완전히 독립적인 클래스로 만들어 보자. DB 커넥션과 관련된 부분을 서브 클래스가 아니라, 아예 별도의 클래스를 담아보자. SimpleConnectionMaker라는 새로운 클래스를 만들고 그 안에 DB 생성 기능을 넣는다. 각 메소드..

2.DAO의 분리 2-1. 관심사의 분리 개발자가 객체를 설계할 때 가장 염두에 둬야 할 사항은 바로 미래의 변화를 어떻게 대비할 것인가이다. 객체지향 기술이 만들어내는 가상의 추상세계 자체를 효과적으로 구성할 수 있고, 이를 자유롭고 편리하게 변경, 발전, 확장시킬 수 있다는데 의미가 있다. 분리와 확장을 고려한 설계 변경이 일어날 때 필요한 작업을 최소화하고, 변경으로 인한 문제를 일으키지 않을 수 있다. 모든 변경과 발전은 한 번에 한 가지 관심사항에 집중해서 일어난다. 프로그래밍의 기초 개념중 관심사의 분리를 객체 지향에 적용해보면, 관심이 같은 것끼리는 하나의 객체 안으로 또는 친한 객체로 모이게 하고, 관심이 다른 것은 가능한 한 따로 떠렁져서 서로 영향을 주지 않도록 분리하는 것. 2-2. ..