• 스프링이 관심을 두는 대상인 오브젝트의 설계, 구현, 동작원리
• 애플리케이션에서 오브젝트가 생성되고 다른 오브젝트와 관계를 맺고, 사용되고, 소멸하기까지의 과정

Data Access Object

DB를 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 오브젝트

🌱 Branch chapter01/setting에 실습을 위한 기본 세팅

• 실습을 위한 DB 생성 MySQL 사용

CREATE database toby DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

• users 테이블 생성

create table users (
	id varchar(10) primary key,
	name varchar(20) not null,
	password varchar(10) not null
);

Full Version

CREATE database toby DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

mysql> use toby
Database changed
mysql> create table users (
-> id varchar(10) primary key,
-> name varchar(20) not null,
-> password varchar(10) not null
-> );
Query OK, 0 rows affected (0.04 sec)

mysql> show tables;
+----------------+
| Tables_in_toby |
+----------------+
| users          |
+----------------+
1 row in set (0.01 sec)

mysql>

기존에는 비주얼 툴에서 조작 가능한 컴포넌트를 뜻했지만, 이제는 두 가지 관례를 따라 만들어진 오브젝트를 지칭한다.

• 디폴트 생성자 : 파라미터가 없는 디폴트 생성자를 가지고 있어야한다. 툴이나 프레임워크에서는 리플렉션을 이용해 오브젝트를 생성하기 때문
• 프로퍼티 : 자바빈이 노출하는 이름을 가진 속성을 뜻함. getter/setter를 통해 수정 or 조회 가능

1. DB 연결을 위한 Connection 준비
2. SQL 담을 Statement 준비
3. Statement 실행
4. 조회의 경우 쿼리 실행 결과를 ResultSet으로 반환
5. 사용한 리소스들을 close
6. 예외 처리

🌱 Branch chapter01/1.2.1에 실습 적용

변경이 일어날 때 필요한 작업을 최소화하고, 그 변경이 다른 곳에 문제를 일으키지 않도록 해야한다.

분리와 확장을 고려한 설계가 필요

문제

• DB 접속 암호가 변경하기 위해 수 백개의 DAO 클래스를 수정해야한다면?
• 트랜젝션 기술이 달라져서 비즈니스 로직이 담긴 코드의 구조가 모두 변경되야 한다면?

• 관심이 같은 것끼리는 하나의 또는 비슷한 객체 안으로, 관심이 다른것은 서로가 영향을 주지 않도록 분리

1. 중복 코드 추출

   /**
   * 중복 코드의 메소드 추출
   * -> 리팩토링의 메소드 추출 기법(extract method)
   */
   public Connection getConnection() throws ClassNotFoundException, SQLException {
        // 1. DB와 연결을 위한 Connection을 가져옴
        Class.forName("com.mysql.cj.jdbc.Driver");
        Connection c = DriverManager.getConnection("jdbc:mysql://localhost/toby?characterEncoding=UTF-8&serverTimezone=UTC",
                                                   "root", "root");
   	return c;
   }

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

   • 리팩토링 : 기존의 코드를 외부의 동작방식에는 변화 없이 내부 구조를 변경해서 재구성하는 작업 또는 기술. 코드 이해도 증가 & 변화 효율적 대응

   • 메소드 추출 기법 : 공통의 기능을 담당하는 메소드로 중복된 코드를 뽑아내는것

3. 상속을 통한 확장

   • 조건 : 상황에 따라 다른 DB 종류를 사용해야한다

   • 기존의 UserDao 코드 추상 메소드로 만들어 분리

   • 템플릿 메소드 패턴 : 기능의 일부만 추상화하여 서브 클래스에서 필요에 맞게 구현해서 사용하는 방법. 각 메소드마다 구현하는 법은 제각각

     • 상속받아 구현하는 Sub Class 입장

   • 팩토리 메소드 패턴 : 인터페이스 타입에서 서브 클래스가 구현할 오브젝트를 미리 타입과 생성방법을 미리 정의해둔 메소드

     • Super 클래스의 코드에서 오브젝트 생성방법을 독립시키는 방법

1. 다중 상속을 받아야 할 경우
2. 슈퍼 클래스 내부의 변경이 있을 경우 서브 클래스에 미치는 영향력

🌱 Branch chapter01/refactor1.3 에 실습 적용

• 데이터 로직 처리와 DB 커넥션 부분을 별도의 클래스로 관리

• 완전히 독립적인 클래스로 분리해 추상화를 없앰

  public void add(User user) throws ClassNotFoundException, SQLException {
  	Connection c = simpleConnectionMaker.makeNewConnection(); // -> FIXME : 다른 클래스의 정보를 메소드 내에서 사용 중 -> 																			SimpleConnectionMaker에 종속적  
  	. . . 
  }

• SimpleConnectionMaker로 분리하면서 N,D 사의 UserDao 사용이 불가능해짐 -> 상속 제거

• 문제 많음 ㅠ

• 클래스를 분리하면서도 중간에 Interface라는 추상적인 느슨한 연결고리를 만들어준다

• 인터페이스로 추상화해놓은 최소한의 통로를 통해 접근하는 쪽에서는 오브젝트를 만들 떄 사용할 클래스가 무엇인지 몰라도 된다

   public UserDao(){
       connectionMaker = new DConnectionMaker();           // FIXME : DB 클래스의 정보를 다시 DAO 클래스 메소드 내에서 사용 중 -> 종속적
   	// 이 코드를 분리하지 않으면 결코 UserDao는 독립적으로 확장 가능한 클래스가 될 수 없다
   }

• 사용할 고객사가 바뀔때마다 수 백개의 Dao 안의 코드를 바꿔야할까?

• A 오브젝트가 B 오브젝트의 기능을 사용한다면?

  • B는 A에게 서비스이다
  • A는 B의 클라이언트다

• UserDao와 ConnectionMaker의 기능을 분리하기 위해 클라이언트 오브젝트를 사용하자

• 런타임 중, 오브젝트들은 한 오브젝트가 다른 오브젝트의 레퍼런스를 가지고 있어야 관계가 만들어진다

  • 오브젝트 관계 생성
    1. c = new DConnectionMaker() 처럼 직접 생성자를 호출하는 방법
    2. 코드 내부가 아니라 메소드 파라미터를 전달하여 외부에서 가져오는 방법

• 런타임 오브젝트 관계 구조를 정의할 책임을 클라이언트 UserDaoTest 에게 떠넘기고, 메소드 파라미터로 전달해 오브젝트 생성

  public class UserDaoTest {
      public static void main(String[] args) throws SQLException, ClassNotFoundException {
          // 두 오브젝트의 의존관계 설정
          ConnectionMaker c = new DConnectionMaker();
          UserDao dao = new UserDao(c);		// 파라미터로 전달
  ...

  public class UserDao {
      private ConnectionMaker connectionMaker;
      public UserDao(ConnectionMaker connectionMaker){
          this.connectionMaker = connectionMaker;
      } ...
  }

객체지향 기술의 이론 소개

• 클래스나 모듈은 확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다
• 자신의 핵심 기능을 구현하고, 다른 변화에 영향을 받지 않고 유지할 수 있어야 한다

• 개방 폐쇄 원칙은 높은 응집도, 낮은 결합도 원리로도 설명이 가능하다

• 높은 응집도 : 하나의 책임 또는 관심사가 집중되어 있다

• 낮은 결합도 : 책임과 관심사가 다른 오브젝트 또는 모듈과는 느슨하게 연결된 형태를 유지

  • 결합도 : 하나의 오브젝트가 변경이 일어날 때에 관계를 맺고 있는 다른 오브젝트에게 변화를 요구하는 정도

• 자신의 **기능맥락(context)**에서 필요에 따라 변경이 필요한 로직 부분을 인터페이스를 통해 통째로 분리 시키고, 필요에 따라 바꿔 사용할 수 있는 디자인 패턴
• 컨텍스트를 사용하는 클라이언트는 컨텍스트가 사용할 **전략(인터페이스 구현 클래스)**을 컨텍스트의 생성자 등을 통해 제공 (예시 : UserDao constructor)

🌱 Branch chapter01/refactor1.4 에 실습 적용

팩토리 : 객체의 생성 방법을 결정하고 생성된 오브젝트를 반환해주는 역할의 클래스

• 오브젝트를 생성하는 쪽 | 생성된 오브젝트를 사용하는 쪽의 역할과 책임을 분리
• 팩토리 역할을 맡을 DaoFactory 클래스 생성
  • DaoFactory 분리로 얻을 수 있는 장점 : 애플리케이션의 컴포넌트 역할을 하는 오브젝트와 애플리케이션의 **구조를 결정(설계도)**하는 오브젝트를 분리

• 프로그램의 제어 흐름 구조가 뒤바뀌는 것
• 오브젝트가 자신이 사용할 오브젝트를 스스로 선택하지 않고, 생성하지 않는다.
• 모든 제어의 권한을 자신이 아닌 다른 대상에게 위임한다
• 제어의 역전에서는 프레임워크, 컨테이너와 같이 **애플리케이션 컴포넌트의 생성과 관계 설정, 사용, 생명주기 관리 등 관장하는 존재**가 필요하다

Library vs Framework

라이브러리

: 개발자가 흐름을 주도하며 애플리케이션 흐름 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 가져다 사용한다

프레임워크

프레임워크 위에 애플리케이션 코드를 작성하고 프레임워크가 흐름을 주도하며 개발자가 만든 코드를 사용한다.

🌱 Branch chapter01/refactor1.5 에 실습 적용

• 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트

• 애플리케이션 컴포넌트

• 스프링 컨테이너가 생성과 관계 설정, 사용등을 제어해주는 제어의 역전이 적용된 오브젝트

• 빈 팩토리(or 애플리케이션 컨텍스트) : 스프링에서 빈의 생성과 관계 설정같은 제어를 담당하는 IoC 오브젝트

@Configuration          // -> 오브젝트 설정을 담당하는 클래스 인식
public class DaoFactory {

    @Bean
    public ConnectionMaker connectionMaker(){
        return new DConnectionMaker();
    }
...

@Configuration : 애플리케이션 컨텍스트 또는 빈 팩토리가 사용할 설정 정보 표시

@Bean : 오브젝트 생성을 담당하는 IoC 메소드

AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(DaoFactory.class);
UserDao dao = context.getBean("userDao", UserDao.class);		// getBean()로 오브젝트를 가져옴

AnnotationConfigApplicationContext 생성자 : @Configuration 어노테이션이 붙은 클래스를 설정정보로 사용

getBean() 메소드 : ApplicationContext가 관리하는 오브젝트를 요청하는 메소드

애플리케이션 컨텍스트는 애플리케이션에서 IoC를 적용해서 관리할 모든 오브젝트에 대한 생성과 관계설정을 담당한다.

• 클라이언트는 구체적인 팩토리 클래스를 알 필요없이 일관적인 방식으로 원하는 오브젝트를 가져올 수 있다.
• 오브젝트 생성, 관계 설정 뿐만이 아니라 자동생성, 후처리, 인터셉팅 등 다양한 기능을 제공한다.
• getBean() 메소드로 빈의 이름을 이용해 검색이 가능하고, 타입이나 어노테이션 만으로도 검색이 가능하다.

1. 빈 (Bean) : 스프링이 IoC 방식으로 관리하는 오브젝트. 단, 애플리케이션에서 만들어지는 모든 오브젝트가 다 빈은 아니다. 스프링이 직접 생성과 제어를 담당하는 오브젝트만을 빈이라 부른다
2. 빈 팩토리 (Bean Factory) : 스프링의 IoC를 담당하는 핵심 컨테이너. 빈 등로그 생성, 조회, 반환 등 관리 기능 담당
3. 애플리케이션 컨텍스트 (application context) : 빈 팩토리를 확장한 IoC 컨테이너. ApplicationContext는 BeanFactory를 상속한다
4. 설정정보/설정 메타정보 (configuration metadata) : 애플리케이션 컨텍스트 또는 빈 팩토리가 IoC를 적용하기 위해 사용하는 메타 정보
5. 컨테이너 or IoC 컨테이너 (container) : IoC 방식으로 빈을 관리
6. 스프링 프레임워크 : 스프링이 제공하는 모든 기능을 통틀어 말할 때 사용

동일성 : 같은 정보 같은 레퍼런스 주소값

동등성 : 같은 정보 다른 레퍼런스 주소값

애플리케이션 컨텍스트로 생성한 오브젝트는 매번 동일하다

• 스프링은 기본적으로 별다른 설정이 없다면 내부에서 생성하는 빈 오브젝트를 싱글톤으로 생성한다.
• 서버 환경에서 매번 클라이언트에게서 요청이 올 때마다 각 로직을 담당하는 오브젝트를 새로 만들어서 사용한다면, 서버가 감당하기 힘들 것이다
• 자바의 기본적인 싱글톤 패턴의 구현방식에는 여러 단점이 있기 때문에, 스프링은 직접 싱글톤 형태의 오브젝트를 만들고 관리하는 기능을 제공
• 스태틱 메소드와 private 생성자를 사용해야하는 비정상적인 클래스가 아니라 평범한 자바 클래스를 싱글톤으로 활용하게 해준다?
  • 싱글톤 방식으로 사용될 애플리케이션 클래스라도 public 생성자를 가질 수 있다

• 싱글톤은 멀티스레드 환경이라면 여러 스레드가 동시에 접근해서 사용할 수 있으므로 상태 관리에 주의해야 한다
• 멀티스레드 환경에서 상태정보를 내부에 갖고 있지 않은 무상태 방식으로 만들어져야 한다
  • 파라미터와 로컬 변수, 리턴 값 등을 이용해야한다 -> 메소드 안에서 매번 새로운 값을 저장할 독립적 공간이 만들어지기 때문
• 여러 스레드가 동시에 싱글톤 오브젝트의 인스턴스 변수를 수정하는 것은 매우 위험하다
  • 서로 덮어쓰고 잘못 불러올 수 있기에 기본적으로 인스턴스 필드의 값을 변경하고 유지하는 상태유지 방식으로 만들지 않는다

읽기 전용 속성이 있다면 싱글톤에 인스턴스 변수로 선언해도 된다. 또는 static final, final로 선언한다

• 스프링이 관리하는 오브젝트, 즉 빈이 생성되고 존재하고 적용되는 범위
• 스프링 빈의 기본 스코프는 싱글톤
• 프로토 타입은 싱글톤과 달리 컨테이너에 빈을 요청할 때마다 매번 새로운 오브젝트를 만들어준다
• 요청 스코프는 웹을 통해 새로운 HTTP 요청이 생길 때마다 생성
• 웹의 세션과 비슷한 세션 스코프

🌱 Branch chapter01/refactor1.7 에 실습 적용

IoC라는 용어가 매우 느슨하게 정의되어 있기 때문에, 스프링의 IoC 방식의 의도를 좀더 명확히 드러나는 이름인 의존관계 주입(Dependency Injection) 용어를사용하기 시작했다.

• 의존한다 : 의존의 대상인 B가 바뀌면 A에 영향을 미친다는 뜻
• A가 B에 정의된 메소드를 사용하는 경우는 **'사용에 대한 의존관계'**이다
• 의존관계에는 **방향성**이 있다 ( A -> B )

의존의 대상이 인터페이스로 되어있다면 의존관계에 있는 두 오브젝트의 결합도를 낮출 수 있다.

인터페이스를 통해 설계 시점에 느슨한 의존관계를 가지고 있는 경우, 런타임시에 사용될 오브젝트가 어떤 클래스로 만들어지는지 알 수 없다.

의존 오브젝트 (dependent object) : 프로그램이 시작되고나서, 오브젝트가 만들어지고 나서 런타임시에 의존관계를 맺는 대상, 실제 사용대상

의존관계 주입 : 구체적인 의존 오브젝트와 그것을 사용할 주체, 클라이언트 오브젝트를 런타임 시에 연결해주는 작업

• 클래스 모델이나 코드에는 런타임 시 연결될 의존관계가 드러나지 않음
  • 인터페이스에 의존해야함
• 런타임 시점의 의존관계는 컨테이너나 팩토리 같은 제3의 존재가 결정
  • 의존관계에 있는 둘 중 누구라도 관계를 결정할 수 없다
• 의존 대상이 되는 오브젝트 '레퍼런스'를 외부에서 제공해줌으로써 만들어진다

@Configuration          
public class DaoFactory {

    @Bean
    public ConnectionMaker connectionMaker(){
        return new DConnectionMaker();		// DconnnectionMaker의 레퍼런스가 전달
    }

    @Bean               
    public UserDao userDao(){
        return new UserDao(connectionMaker());		// 파라미터 전달로 의존 관계 주입
    }
} 		

• 자신이 필요로 하는 의존 오브젝트를 능동적으로 검색
• 런타임 시 의존관계를 맺을 오브젝트 결정, 오브젝트 생성는 외부 컨테이너에게 맡기지만, 이를 가져올때 스스로 컨테이너에게 요청하는 방법을 사용한다

• 의존관계 검색 방식에서 검색하는 오브젝트는 자신이 스프링의 빈일 필요가 없다.
• 의존관계 주입에서는 반드시 컨테이너가 만드는 빈 오브젝트를 사용해야 한다.

DI vs DL 차이점 좀 더 알아보기

여태까지 의존관계 주입을 위해 생성자를 사용해왔지만, 반드시 생성자를 사용해 주입할 필요는 없다.

1. 수정자 메소드(setter)를 이용한 주입

   • 외부에서 오브젝트 내부의 애트리뷰트 값을 변경하려는 용도
   • 핵심기능 : 파라미터로 전달된 값을 내부의 인스턴스 변수에 저장
   • 외부로부터 제공받은 오브젝트 레퍼런스를 저장해뒀다가 내부의 메소드에서 사용하게 하는 DI 방식에 활용

2. 일반 메소드를 이용한 주입

   • 여러 개의 파라미터를 받을 수 있는 장점을 가짐
   • 생성자에 많은 개수의 파라미더를 한꺼번에 받으면 실수하기 쉽기 때문에 적절한 파라미터 개수를 나눠 초기화 메서드를 생성할 수 있다

   @Bean               // -> 수정자 메소드 DI를 사용하는 펙토리 메소드
   public UserDao userDao(){
       UserDao userDao = new UserDao();
       userDao.setConnectionMaker(connectionMaker());
       return userDao;
   }
   // 의존관계를 주입하는 시점과 방법이 달라졌을 뿐 결과는 동일하다

🌱 Branch chapter01/refactor1.8 에 실습 적용

• 단순한 텍스트 파일에 컴파일과 같은 별도의 빌드 작업이 없는 장점

• 환경이 달라져서 오브젝트의 관계가 바뀌는 경우에도 빠르게 변경사항 반영

빈의 이름, 클래스 두가지 정보를 태그의 id, class 속성으로 정의한다

@Bean
public ConnectionMaker connectionMaker(){
    return new DConnectionMaker();
}

@Bean               
public UserDao userDao(){
    UserDao userDao = new UserDao();
    userDao.setConnectionMaker(connectionMaker());
    return userDao;
}

<beans>
    <bean id="connectionMaker" class="com.training.spring.dao.DConnectionMaker" />
    <bean id="userDao" class="com.training.spring.dao.UserDao">
        <property name="connectionMaker" ref="connectionMaker" />
    </bean>
</beans>

property 태그

• name : 프로퍼티의 이름으로 수정자 메소드(setter)에 사용
• ref : 수정자 메소드를 이용해 주입해줄 빈 오브젝트 이름

1. DTD

   <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN"
           "http://www.springframework.org/dtd/spring-beans-2.0.dtd">

   태그 앞에 상단의 선언을 넣어준다

2. 스키마

   • DI의 기본 태그인 , 외에도 별도의 태그를 사용할 수 있다 -> 그러기 위해서는 네임스페이스가 지원되는 스키마 사용

   <beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="
           http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

* 스프링의 XML 설정파일은 두 가지 방식 모두 지원. 특별한 이유가 없다면 스키마를 사용하길 권유됨

GenericXmlApplicationContext를 사용 + XML 파일의 클래스패스 지정

ApplicationContext context = new GenericXmlApplicationContext("applicationContext.xml");

@Bean
public DataSource dataSource(){
    SimpleDriverDataSource dataSource = new SimpleDriverDataSource();
    // DB 연결정보를 수정자 메소드를 통해 넣어준다 [오브젝트 레벨에서 DB 연결 방식]
    dataSource.setDriverClass(com.mysql.cj.jdbc.Driver.class);
    dataSource.setUrl("jdbc:mysql://localhost/toby?characterEncoding=UTF-8&serverTimezone=UTC");
    dataSource.setUsername("root");
    dataSource.setPassword("root");

    return dataSource;
}