[토비의 스프링 Vol.1 ] - 스프링의 이해와 원리

김주형·2022년 4월 5일

Web Basic

목록 보기

3/57

🙇

지식재산권을 고려하여 해당 시리즈 게시글이 비공개로 전환될 수 있습니다

[토비의 스프링 Vol.1 ] - 스프링의 이해와 원리

오브젝트와 의존관계

스프링은 자바를 기반으로 한 기술입니다.
스프링이 자바에서 가장 중요하게 가치를 두는 것은 바로 객체지향 프로그래밍이 가능한 언어라는 점이다.

자바 엔터프라이즈 기술의 혼란 속에서
잃어버렸던 객체지향 기술의 진정한 가치를 회복시키고,
그로부터 객체지향 프로그래밍이 제공하는 폭넓은 혜택을 누릴 수 있도록 기본으로 돌아가자는 것
이것이 바로 스프링의 핵심 철학입니다.

초난감 DAO

DAO(Data Access Object) : DB를 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 오브젝트를 말합니다.

User

public class User {
  String id;
  String name;
  String password;
  
  public String getId() {
    return id;
  }
  public void setId(String id) {
    this.id = id;
  }
  public String getName() {
    return name;
  }
  public void setName(String name) {
    this.name = name;
  }
  public String getPassword() {
    return password;
  }
  public void setPassword(String password) {
    this.password = password;
  }
}

USERS 테이블 필드 구성

필드명	타입	설정
Id	VARCHAR(10)	Primary Key
Name	VARCHAR(20)	Not Null
Password	VARCHAR(20)	Not Null

UserDao

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

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

DAO의 분리

관심사의 분리

개발자가 객체를 설계할 때 가장 염두에 둬야 할 사항은 바로 "미래의 변화를 어떻게 대비할 것인가"입니다.
객체 지향 기술은 흔히 실세계를 최대한 가깝게 모델링해낼 수 있기 때문에 의미가 있다고 여겨진다고 합니다. 하지만, 그보다 객체지향 기술이 만들어내는 가상의 추상세계 자체를 효과적으로 구성할 수 있고, 이를 자유롭고 편리하게 변경, 발전, 확장시킬 수 있다는 것!!
이것에 더 의미가 있습니다.

변화는 대체로 집중된 한 가지 관심에 대해 일어나지만 그에 따른 작업은 한 곳에 집중되지 않는 경우가 많다고 합니다.
변화가 한 번에 한 가지 관심에 집중돼서 일어난다면, 우리가 준비해야 할 일은 한 가지 관심이 한 군데에 집중되게 하는 것입니다. 즉 관심이 같은 것끼리는 모으고, 관심이 다른 것은 따로 떨어져 있도록 하는 것입니다.

결합도 DOWN, 응집도 UP

프로그래밍의 기초 개념 중에 관심사의 분리라는 게 있습니다.
관심이 같은 것끼리는 하나의 객체 안으로 또는 친한 객체로 모이게 하고,
관심이 다른 것은 되도록 따로 떨어져서 서로 영향을 주지 않도록 분리하는 것입니다.

커넥션 만들기의 추출

UserDao의 관심사항

첫째는 DB와 연결을 위한 커넥션을 어떻게 가져올까라는 관심입니다.
둘째는 사용자 등록을 위해 DB에 보낼 SQL 문장을 담을 Statement를 만들고 실행하는 것입니다.
셋째는 작업이 끝나면 사용한 리소스인 Statement와 Connection 오브젝트를 닫아줘서 소중한 공유 리소스를 시스템에 돌려주는 것입니다.

중복 코드의 메소드 추출

중복된 DB 연결 코드를 getConnection() 이라는 이름의 독립적인 메소드로 만들어둡니다.
각 DAO 메소드에서는 이렇게 분리한 getConnection() 메소드를 호출해서 DB 커넥션을 가져오도록 합니다.

여러 메소드에 중복돼서 등장하는 특정 관심사항이 담긴 코드를 별도의 메소드로 분리해냈습니다.

기능이 추가되거나 바뀐 것은 없지만 UserDao는 이전보다 훨씬 깔끔해졌고 미래의 변화에 좀 더 손쉽게 대응할 수 있는 코드가 되었습니다!
이런 작업을 리팩토링이라고 합니다. 또한 getConnection() 이라고 하는 공통의 기능을 담당하는 메소드로 중복된 코드를 뽑아내는 것을 리팩토링에서는
메소드 추출기법이라고 부릅니다.

DB 커넥션 만들기의 독립

다른 종류의 DB 사용, DB 커넥션을 가져오는데 있어 독자적으로 만든 방법을 적용하고 싶다면?

상속을 통한 확장

UserDao에서 메소드의 구현 코드를 제거하고 getConnection()을 추상 메소드로 만들어 놓습니다.
추상 메소드라서 메소드 코드는 없지만 메소드 자체는 존재합니다.
UserDao 클래스를 상속해서 각각 서브클래스를 만들고 추상메소드를 구현할 경우,
getConnection() 메소드를 원하는 방식으로 확장하여 UserDao의 기능과 함께
사용할 수 있습니다.

DAO의 핵심 기능인 "어떻게 데이터를 등록하고 가져올 것인가"라는 관심을 담당하는 UserDao와, "DB 연결 방법은 어떻게 할 것인가"라는 관심을 담고있는 서브클래스가
클래스 레벨로 구분이 되고 있습니다.
클래스 계층구조를 통해 두 개의 관심이 독립적으로 분리되면서 변경 작업은 한층 용이해졌습니다.

슈퍼클래스에 기본적인 로직의 흐름을 만들고, 그 기능의 일부를 추상 메소드나 오버라이딩이 가능한 protected 메소드 등으로 만든 뒤 서브클래스에서 이런 메소드를
필요에 맞게 구현해서 사용하도록 하는 방법을 디자인 패턴에서 템플릿 메소드 패턴이라고 한다고 합니다.

UserDao의 서브클래스의 getConnection() 메소드는 어떤 Connection 클래스의 오브젝트를 어떻게 생성할 것인지를 결정하는 방법이라고도 볼 수 있습니다.
이렇게 서브클래스에서 구체적인 오브젝트 생성 방법을 결정하게 하는 것을 팩토리 메소드 패턴이라고 부릅니다.

UserDao는 Connection 오브젝트가 만들어지는 방법과 내부 동작 방식에는 상관없이 자신이 필요한 기능을 Connection 인터페이스를 통해 사용하기만 할 뿐입니다.
매우 깔끔한 방식으로 관심사항을 분리해 상하위 클래스에 나눠 담도록 만든 것입니다.

디자인 패턴

디자인 패턴이란?

소프트웨어 설계 시 특정 상황에서 자주 만나는 문제를 해결하기 위해 사용할 수 있는 재사용 가능한 솔루션을 말합니다.
디자인 패턴은 주로 객체지향 설계에 관한 것이고, 대부분 객체지향적 설계 원칙을 이용해 문제를 해결합니다.

템플릿 메소드 패턴

변하지 않는 기능은 슈퍼클래스에 만들어두고 자주 변경되며 확장할 기능은 서브클래스에서 만들도록 합니다.
슈퍼클래스에서는 미리 추상 메소드 또는 오버라이드 가능한 메소드를 정의해두고 이를 활용해 코드의 기본 알고리즘을 담고 있는 템플릿 메소드를 생성합니다.
슈퍼클래스에서 디폴트 기능을 정의해두거나 비워뒀다가 서브클래스에서 선택적으로 오버라이드할 수 있도록 만들어둔 메소드를 훅메소드라고 합니다.
서브클래스에서는 추상 메소드를 구현하거나, 훅 메소드를 오버라이드하는 방법을 이용해 기능의 일부를 확장합니다.

팩토리 메소드 패턴

슈퍼클래스 코드에서는 서브클래스에서 구현할 메소드를 호출해서 필요한 타입의 오브젝트를 가져와 사용합니다.
이 메소드는 주로 인터페이스 타입으로 오브젝트를 리턴하므로 서브클래스에서 정확히 어떤 클래스의 오브젝트를 만들어 리턴할지는 슈퍼클래스에서는 알지 못합니다.
서브클래스는 다양한 방법으로 오브젝트를 생성하는 메소드를 재정의할 수 있습니다.

이렇게 서브클래스에서 오브젝트 생성 방법과 클래스를 결정할 수 있도록 미리 정의해둔 메소드를 팩토리 메소드라고 하고,
이 방식을 통해 오브젝트 생성 방법과 나머리 로직, 즉 슈퍼클래스의 기본 코드에서 독립시키는 방법을 팩토리 메소드 패턴이라고 한다.

이 방법은 상속을 사용했다는 단점이 있다. 자바는 클래스의 다중상속을 허용하지 않기 때문이다.

또 다른 문제는 상속을 통한 상하위 클래스의 관계는 생각보다 밀접하다는 점이다. 서브 클래스는 슈퍼 클래스의 기능을 직접 사용할 수 있기 때문에
슈퍼클래스 내부의 변경이 있을 때 모든 서브클래스를 함께 수정하거나 다시 개발해야 할 수도 있다.

확장된 기능은 DB 커넥션을 생성하는 코드를 다른 DAO 클래스에 적용할 수 없다는 것도 큰 단점이다.

DAO의 확장

클래스의 분리

DB 커넥션과 관련된 부분을 서브클래스가 아니라, 아예 별도의 클래스에 담습니다.
그리고 이렇게 만든 클래스를 UserDao가 이용하게 하면 됩니다.

UserDao 클래스만 공급하고 상속을 통해 DB 커넥션 기능을 확장해서 사용하게 했던게 다시 불가능해졌습니다. UserDao의 코드가 특정 Connection클래스에 종속되어 있기 때문입니다.

UserDao가 바뀔 수 있는 정보, 즉 DB 커넥션을 가져오는 클래스에 대해 너무 많이 알고 있기 때문에
어떤 클래스가 쓰일지, 그 클래스에서 커넥션을 가져오는 메소드는 이름이 뭔지까지 일일이 알고 있어야 합니다.
따라서 UserDao는 DB 커넥션을 가져오는 구체적인 방법에 종속되어 버린 셈입니다.

인터페이스의 도입

두 개의 클래스가 서로 긴밀하게 연결되어 있지 않도록 중간에 추상적인 느슨한 연결고리를 만들어 줍니다.
추상화란 어떤 것들의 공통적인 성격을 뽑아내어 이를 따로 분리해내는 작업입니다.
자바가 추상화를 위해 제공하는 가장 유용한 도구는 바로 인터페이스입니다. 인터페이스는 자신을 구현한 클래스에 대한 구체적인 정보는 모두 감춰버립니다.

connectionMaker = new DConnectionMaker();

하지만 위의 코드처럼 초기에 한 번 어떤 클래스의 오브젝트를 사용할지를 결정하는 생성자의 코드는 제거되지 않고 남아 있습니다. (다시 원점)

관계설정 책임의 분리

new DConnectionMaker();

위 코드는 UserDao가 어떤 ConnectionMaker 구현 클래스의 오브젝트를 이용하게 할지를 결정하는 것입니다.
UserDao와 UserDao가 사용할 ConnectionMaker의
특정 구현 클래스 사이의 관계를 설정해주는 것에 관한 관심입니다.
이 관심사를 담은 코드를 UserDao에서 분리하지 않으면 UserDao는 결코 독립적으로 확장 가능한 클래스가 될 수 없습니다.

오브젝트 사이의 관계를 설정해주면 됩니다.

UserDao 오브젝트가 다른 오브젝트와 관계를 맺으려면 관계를 맺을 오브젝트가 있어야 할 텐데, 이 오브젝트를 꼭 UserDao의 코드 내에서 만들 필요는 없습니다.
오브젝트는 얼마든지 메소드 파라미터 등을 이용해 전달할 수 있으니 외부에서 만든걸 가져올 수도 있습니다.
외부에서 만든 오브젝트를 전달 받으려면 메소드 파라미터나 생성자 파라미터를 이용하면 됩니다. 이 때 파라미터의 타입을 전달받을 오브젝트의 인터페이스로 선언해뒀다고 한다면?
이런 경우 파라미터로 전달되는 오브젝트의 클래스는 해당 인터페이스를 구현하기만 했다면 어떤 것이든지 상관없습니다. 단지 해당 인터페이스 타입의 오브젝트라면 파라미터로 전달 가능하고, 파라미터로 제공받은 오브젝트는 인터페이스에 정의된 메소드만 이용한다면 그 오브젝트가 어떤 클래스로부터 만들어졌는지 신경 쓰지 않아도 됩니다.

클라이언트와 같은 제 3의 오브젝트인 UserDaoTest라는 이름의 클래스를 하나 만들고 UserDao 오브젝트가 사용할 ConnectionMaker 오브젝트를 전달해봅니다.
UserDaoTest는 UserDao와 ConnectionMaker 구현 클래스와의 런타임 오브젝트 의존 관계를 설정하는 책임을 담당해야 합니다.

클라이언트인 UserDaoTest가 이렇게 수고해준 덕분에 이제는 UserDao의 변경 없이도 자유롭게 각각의 자신들을 위한 DB 접속 클래스를 만들어서 UserDao가 사용하게 할 수 있습니다.

원칙과 패턴

개방 폐쇄 원칙

'클래스나 모듈은 확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.'
UserDao는 DB 연결 방법이라는 기능을 확장하는 데는 열려 있다. UserDao에 전혀 영향을 주지 않고도 얼마든지 기능을 확장할 수 있게 되어 있다. 동시에 UserDao 자신의 핵심 기능을 구현한 코드는 그런 변화에 영향을 받지 않고 유지할 수 있으므로 변경에는 닫혀 있다.

높은 응집도와 낮은 결합도

개방 폐쇄 원칙은 높은 응집도와 낮은 결합도라는 소프트웨어 개발의 고전적인 원리로도 설명이 가능하다. 응집도가 높다는 건 하나의 모듈, 클래스가 하나의 책임 또는 괌심사에만 집중되어 있다는 뜻이다. 불필요하거나 직접 관련이 없는 외부의 관심과 책임이 얽혀 있지 않으며, 하나의 공통 관심사는 한 클래스에 모여 있다.

높은 응집도는 클래스 레벨뿐 아니라, 패키지, 컴포넌트, 모듈에 이르기까지 그 대상의 크기가 달라도 동일한 원리로 적용될 수 있다.
낮은 결합도는 책임과 관심사가 다른 오브젝트 또는 모듈과는 낮은 결합도, 즉 느슨하게 연결된 형태를 유지하는 것이 바람직하다. 느슨한 연결은 관계를 유지하는 데 꼭 필요한 최소한의 방법만 간접적인 형태로 제공하고, 나머지는 서로 독립적이고 알 필요도 없게 만들어주는 것이다. 결합도가 낮아지면 변화에 대응하는 속도가 높아지고, 구성이 깔끔해진다. 또한 확장하기에도 매우 편리하다.

전략 패턴

전략 패턴은 자신의 기능 맥락에서, 필요에 따라 변경이 필요한 알고리즘을 인터페이스를 통해 통째로 외부로 분리시키고, 이를 구현한 구체적인 알고리즘 클래스를 필요에 따라 바꿔서 사용할 수 있게 하는 디자인 패턴이다. UserDao는 전략 패턴의 컨텍스트에 해당한다. 컨텍스트는 자신의 기능을 수행하는데 필요한 기능 중에서 변경 가능한, DB 연결 방식이라는 알고리즘을 ConnectionMaker라는 인터페이스로 정의하고, 이를 구현한 클래스, 즉 전략을 바꿔가면서 사용할 수 있게 분리했다.

전략 패턴은 UserDaoTest와 같은 클라이언트의 필요성에 대해서도 잘 설명하고 있다. 전략 패턴의 적용 방법을 보면 클라이언트의 역할이 잘 설명되어 있다. 컨텍스트를 사용하는 클라이언트는 컨텍스트가 사용할 전략을 컨텍스트의 생성자 등을 통해 제공해주는 게 일반적이다.

제어의 역전(IoC)

오브젝트 팩토리

UserDaoTest는 UserDao의 기능이 잘 동작하는지를 테스트하려고 만든 것인데, 지금은 또 다른 책임까지 떠맡고 있으니 이것도 분리하자. 분리될 기능은 UserDao와 ConnectionMaker 구현 클래스의 오브젝트를 만드는 것과, 그렇게 만들어진 두 개의 오브젝트가 연결돼서 사용될 수 있도록 관계를 맺어주는 것이다.

팩토리

분리시킬 기능을 담당할 클래스를 하나 만들면, 이 클래스의 역할은 객체의 생성 방법을 결정하고 그렇게 만들어진 오브젝트를 돌려주는 것인데, 이런 일을 하는 오브젝트를 흔히 팩토리라고 부른다. 단지 오브젝트를 생성하는 쪽과 생성된 오브젝트를 사용하는 쪽의 역할과 책임을 깔끔하게 분리하려는 목적으로 사용하는 것이다. 어떻게 만들지와 어떻게 사용할지는 분명 다른 관심이다.

오브젝트 팩토리의 활용

UserDao가 아닌 다른 DAO의 생성 기능이 추가 되면 팩토리에 new DConnectionMaker()의 코드가 중복 발생한다.

public class DaoFactory {
  public UserDao userDao() {
    return new UserDao(new DConnectionMaker());
  }
  public AccountDao accounDao() {
    return new AccountDao(new DConnectionMaker());
  }
  public MessageDao messageDao() {
    return new MessageDao(new DConnectionMaker());
  }
}

중복된 코드는 분리해 내자.

ConnectionMaker의 구현 클래스를 결정하고 오브젝트를 만드는 코드를 별도의 메소드로 뽑아내자.

public class DaoFactory {
  public UserDao userDao() {
    return new UserDao(connectionMaker());
  }
  public AccountDao accounDao() {
    return new AccountDao(connectionMaker());
  }
  public MessageDao messageDao() {
    return new MessageDao(connectionMaker());
  }
  
  public ConnectonMaker connectionMaker() {
    return new DConnctionMaker();
  }
}

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

각 오브젝트는 프로그램 흐름을 결정하거나 사용할 오브젝트를 구성하는 작업에 능동적으로 참여한다. 모든 오브젝트가 능동적으로 자신이 사용할 클래스를 결정하고, 언제 어떻게 그 오브젝트를 만들지를 스스로 관장한다. 모든 종류의 작업을 사용하는 쪽에서 제어하는 구조다.

제어의 역전이란 이런 제어 흐름의 개념을 거꾸로 뒤집는 것이다. 제어의 역전에서는 오브젝트가 자신이 사용할 오브젝트를 스스로 선택하지 않는다. 당연히 생성하지도 않는다. 또 자신도 어떻게 만들어지고 어디서 사용되는지를 알 수 없다. 모든 제어 권한을 자신이 아닌 다른 대상에게 위임하기 때문이다.

원래 ConnectionMaker의 구현 클래스를 결정하고 오브젝트를 만드는 제어권은 UserDao에게 있었다. 그런데 지금은 DaoFacroty에게 있다. 자신이 어떤 ConnectionMaker 구현 클래스를 만들고 사용할지를 결정할 권한을 DaoFactory에 넘겼으니 UserDao는 이제 능동적이 아니라 수동적인 존재가 됐다. UserDao 자신도 팩토리에 의해 수동적으로 만들어지고 자신이 사용할 오브젝트도 DaoFactory가 만들고 초기화해서 자신에게 사용하도록 공급해주는 ConnectionMaker를 사용할 수 밖에 없다. 더욱이 UserDao와 ConnectionMaker의 구현체를 생성하는 책임도 DaoFactory가 맡고 있다. 바로 이것이 제어의 역전이 일어난 상황이다.

스프링의 IoC

오브젝트 팩토리를 이용한 스프링 IoC

애플리케이션 컨텍스트와 설정정보

스프링에서는 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트를 빈(bean)이라고 부른다. 오브젝트 단위의 애플리케이션 컴포넌트이다. 동시에 스프링 빈은 스프링 컨테이너가 생성과 관계설정, 사용 등을 제어해주는 제어의 역전이 적용된 오브젝트를 가리키는 말이다.

스프링에서는 빈의 생성과 관계설정 같은 제어를 담당하는 IoC 오브젝트를 빈 팩토리라고 부른다. 보통 빈 팩토리보다는 이를 좀 더 확장한 애플리케이션 컨텍스트를 주로 사용한다. 애플리케이션 컨텍스트는 IoC 방식을 따라 만들어진 일종의 빈 팩토리라고 생각하면 된다. 빈 팩토리와 애플리케이션 컨텍스트라는 용어를 동일하다고 생각하면 된다. 빈 팩토리라고 말할 때는 빈을 생성하고 관계를 설정하는 IoC의 기본 기능에 초점을 맞춘 것이고, 애플리케이션 컨텍스트라고 말할 때는 애플리케이션 전반에 걸쳐 모든 구성요소의 제어 작업을 담당하는 IoC 엔진이라는 의미가 좀 더 부각된다고 보면 된다.

DaoFactory를 사용하는 애플리케이션 컨텍스트

스프링이 빈 팩토리를 위한 오브젝트 설정을 담당하는 클래스라고 인식할 수 있도록 @Configuration이라는 애노테이션을 추가한다. 그리고 오브젝트를 만들어주는 메소드에는 @Bean이라는 애노테이션을 붙여준다. 또한 ConnectionMaker 타입의 오브젝트를 생성해주는 connectionMaker() 메소드에도 @Bean을 붙여준다.

이 두 가지 애노테이션만으로 스프링 프레임워크의 빈 팩토리 또는 애플리케이션 컨텍스트가 IoC 방식의 기능을 제공할 때 사용할 완벽한 설정정보가 된 것이다.

애플리케이션 컨텍스트는 ApplicationContext 타입의 오브젝트다. ApplicationContext를 구현한 클래스는 여러 가지가 있는데 DaoFatory처럼 @Configuration이 붙은 자바 코드를 설정정보로 사용하려면 AnnotationConfigApplicationContext를 이용하면 된다. 애플리케이션 컨텍스트를 만들 때 생성자 파라미터로 DaoFactory 클래스를 넣어준다. 이제 이렇게 준비된 ApplicationContext의 getBean()이라는 메소드를 이용해 UserDao의 오브젝트를 가져올 수 있다.

public class UserDaoTest {
  public static void main(String[] args) throws ClassNotFoundException, SQLException {
    ApplicationContext context = new AnnotationConfigApplicationContext(DaoFactory.class);
    UserDao dao = context.getBean("userDao", UserDao.class);
    ...
  }
}

getBean() 메소드는 ApplicationContext가 관리하는 오브젝트를 요청하는 메소드다. getBean()의 파라미터인 "userDao"는 ApplicationContext에 등록된 빈의 이름이다. DaoFactory에서 @Bean이라는 애노테이션을 userDao라는 이름의 메소드에 붙였는데, 이 메소드 이름이 바로 빈의 이름이 된다.

애플리케이션 컨텍스트의 동작방식

오브젝트 팩토리에 대응되는 것이 스프링의 애플리케이션 컨텍스트다. 스프링에서는 이 애플리케이션 컨텍스트를 IoC 컨테이너라 하기도 하고, 간단히 스프링 컨테이너라고 부르기도 한다. 또는 빈 팩토리라고 부를 수도 있다.

애플리케이션 컨텍스트는 DaoFactory 클래스를 설정정보로 등록해두고 @Bean이 붙은 메소드의 이름을 가져와 빈 목록을 만들어둔다. 클라이언트가 애플리케이션 컨텍스트의 getBean() 메소드를 호출하면 자신의 빈 목록에서 요청한 이름이 있는지 찾고, 있다면 빈을 생성하는 메소드를 호출해서 오브젝트를 생성시킨 후 클라이언트에 돌려준다. DaoFactory를 오브젝트 팩토리로 직접 사용했을 때와 비교해서 애플리케이션 컨텍스트를 사용했을 때 얻을 수 있는 장점

클라이언트는 구체적인 팩토리 클래스를 알 필요가 없다
애플리케이션 컨텍스트는 종합 IoC 서비스를 제공해준다
애플리케이션 컨텍스트는 빈을 검색하는 다양한 방법을 제곤한다

스프링 IoC 용어 정리

빈
- 빈 또는 빈 오브젝트는 스프링이 IoC 방식으로 관리하는 오브젝트라는 뜻이다. 스프링을 사용하는 애플리케이션에서 만들어지는 모든 오브젝트가다 빈은 아니고 그중에서 스프링이 직접 그 생성과 제어를 담당하는 오브젝트만을 빈이라고 부른다.
빈 팩토리
- 스프링의 IoC를 담당하는 핵심 컨테이너다. 빈을 등록하고, 생성하고, 조회하고 돌려주고, 그 외에 부가적인 빈을 관리하는 기능을 담당한다. 보통은 이 빈을 바로 사용하지 않고 이를 확장한 애플리케이션 컨텍스트를 이용한다.
애플리케이션 컨텍스트
- 빈 팩토리를 확장한 IoC 컨테이너다. 빈을 등록하고 관리하는 기본적인 기능은 빈 팩토리와 동일하다. 여기에 스프링이 제공하는 각종 부가 서비스를 추가로 제공한다.
설정정보/설정 메타정보
- 스프링의 설정정보란 애플리케이션 컨텍스트 또는 빈 팩토리가 IoC를 적용하기 위해 사용하는 메타정보를 말한다.
컨테이너 또는 IoC 컨테이너
- IoC 방식으로 빈을 관리한다는 의미에서 애플리케이션 컨텍스트나 빈 팩토리를 컨테이너 또는 IoC 컨테이너라고도 한다.
스프링 프레임워크
- 스프링 프레임워크는 IoC 컨테이너, 애플리케이션 컨텍스트를 포함해서 스프링이 제공하는 모든 기능을 통틀어 말할 때 주로 사용한다.

싱글톤 레지스트리와 오브젝트 스코프

스프링은 여러 번에 걸쳐 빈을 요청하더라도 매번 동일한 오브젝트를 돌려준다.

싱글톤 레지스트리로서의 애플리케이션 컨텍스트

애플리케이션 컨텍스트는 우리가 만들었던 오브젝트 팩토리와 비슷한 방식으로 동작하는 IoC 컨테이너다. 그러면서 동시에 이 애플리케이션 컨텍스트는 싱글톤을 저장하고 관리하는 싱글톤 레지스트리이기도 하다.

서버 애플리케이션과 싱글톤

매번 클라이언트에서 요청이 올 때 마다 각 로직을 담당하는 오브젝트를 새로 만들어서 사용하면 부하가 심하여 서버가 감당하기 힘들다. 따라서 스프링은 싱글톤으로 빈을 만든다.

싱글톤 패턴의 한계

자바에서 싱글톤을 구현하는 방법

클래스 밖에서는 오브젝트를 생성하지 못하도록 생성자를 private으로 만든다.
생성된 싱글톤 오브젝트를 저장할 수 있는 자신과 같은 타입의 스태틱 필드를 정의한다.
스태틱 팩토리 메소드인 getInstance()를 만들고 이 메소드가 최초로 호출되는 시점에서 한 번만 오브젝트가 만들어지게 한다. 생성된 오브젝트는 스태틱 필드에 저장된다. 또는 스태틱 필드의 초기값으로 오브젝트를 미리 만들어둘 수도 있다.
한번 오브젝트가 만들어지고 난 후에는 getInstance() 메소드를 통해 이미 만들어져 스태틱 필드에 저장해둔 오브젝트를 넘겨준다.

일반적으로 싱글토 패턴 구현 방식에는 다음과 같은 문제가 있다.

private 생성자를 갖고 있기 때문에 상속할 수 없다.
싱글톤은 테스트하기가 힘들다.
서버환경에서는 싱글톤이 하나만 만들어지는 것을 보장하지 못한다.
- 여러 개의 JVM에 분산돼서 설치가 되는 경우에 각각 독립적으로 오브젝트가 생기기 때문
싱글톤의 사용은 전역 상태를 만들 수 있기 때문에 바람직하지 못하다.

싱글톤 레지스트리

스프링은 직접 싱글톤 형태의 오브젝트를 만들고 관리하는 기능을 제공한다. 그것이 바로 싱글톤 레지스트리다. 스태틱 메소드와 private 생성자를 사용해야 하는 비정상적인 클래스가 아니라 평범한 자바 클래스를 싱글톤으로 활용하게 해준다. IoC 방식의 컨테이너를 사용해서 생성과 관계설정, 사용 등에 대한 제어권을 컨테이너에게 넘기면 손쉽게 싱글톤 방식으로 만들어져 관리되게 할 수 있다. 오브젝트 생성에 관한 모든 권한은 IoC 기능을 제공하는 애플리케이션 컨텍스트에게 있기 때문이다.

싱글톤과 오브젝트의 상태

싱글톤은 멀티스레드 환경이라면 여러 스레드가 동시에 접근해서 사용할 수 있다. 따라서 상태 관리에 주의를 기울여야 한다. 기본적으로 싱글톤이 멀티스레드 환경에서 서비스 형태의 오브젝트로 사용되는 경우에는 상태 정보를 내부에 갖고 있지 않은 무상태방식으로 만들어져야 한다. 그리고 각 요청에 대한 정보나, DB나 서버의 리소스로부터 생성한 정보는 파라미터와 로컬 변수, 리턴 값 등을 이용하면 된다. 메소드 파라미터나, 메소드 안에서 생성되는 로컬 변수는 매번 새로운 값을 저장할 독립적인 공간이 만들어지기 때문에 싱글톤이라고 해도 여러 스레드가 변수의 값을 덮어쓸 일은 없다.

스프링 빈의 스코프

스프링이 관리하는 오브젝트, 즉 빈이 생성되고, 존재하고, 적용되는 범위를 빈의 스코프라고 한다. 스프링 빈의 기본 스코프틑 싱글톤이지만, 경우에 따라서는 컨테이너에 빈을 요청할 때마다 매번 새로운 오브젝트를 만들어주는 프로토타입, 웹을 통해 새로운 HTTP 요청이 생길 때마다 생성되는 요청(request) 스코프, 웹의 세션과 스코프가 유사한 세션(session)스코프가 있다.

의존관계 주입(DI)

런타임 의존관계 설정

의존관계

B가 변하면 그것이 A에 영향을 미친다. B의 기능이 추가되거나 변경되거나, 형식이 바뀌거나 하면 그 영향이 A로 전달된다.

UserDao의 의존관계

UserDao가 ConnectionMaker 인터페이스를 사용한다. UserDao가 ConnectionMaker 인터페이스에만 의존하고 있다. 따라서 ConnectionMaker 인터페이스가 변한다면 그 영향을 UserDao가 직접적으로 받게 된다. 하지만 ConnectionMaker 인터페이스를 구현한 클래스가 다른 것으로 바뀌거나 그 내부에서 사용하는 메소드에 변화가 생겨도 UserDao에 영향을 주지 않는다. 이렇게 인터페이스에 대해서만 의존관계를 만들어두면 인터페이스 구현 클래스와의 관계는 느슨해지면서 변화에 영향을 덜 받는 상태가 된다. 결합도가 낮다고 설명할 수 있다.

프로그램이 시작되고 UserDao 오브젝트가 만들어지고 나서 런타임 시에 의존관계를 맺는 대상, 즉 실제 사용대상인 오브젝트를 의존 오브젝트라고 말한다. 의존관계 주입은 이렇게 구체적인 의존 오브젝트와 그것을 사용할 주체, 보통 클라이언트라고 부르는 오브젝트를 런타임 시에 연결해주는 작업을 말한다.

의존관계 주입이란 다음과 같은 세 가지 조건을 충족하는 작업을 말한다.

클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지 않는다. 그러기 위해서는 인터페이스에만 의존하고 있어야 한다.
런타임 시점의 의존관계는 컨테이너나 팩토리 같은 제3의 존재가 결정한다.
의존관계는 사용할 오브젝트에 대한 레퍼런스를 외부에서 제공(주입)해줌으로써 만들어진다.

의존관계 주입의 핵심은 설계 시점에는 알지 못했던 두 오브젝트의 관계를 맺도록 도와주는 제3의 존재가 있다는 것이다.

의존관계 검색과 주입

의존관계 검색은 자신이 필요로 하는 의존 오브젝트를 능동적으로 찾는다. 물론 자신이 어떤 클래스의 오브젝트를 이용할지 결정하지는 않는다. 의존관계 검색은 런타임 시 의존관계를 맺을 오브젝트를 결정하는 것과 오브젝트의 생성작업은 외부 컨테이너에게 IoC로 맡기지만, 이를 가져올 때는 메소드나 생성자를 통한 주입 대신 스스로 컨테이너에게 요청하는 방법을 사용한다. 미리 정해놓은 이름을 전달해서 그 이름에 해당하는 오브젝트를 찾게 된다. 따라서 이를 일종의 검색이라고 볼 수 있으며, 그 대상이 런타임 의존관계를 가질 오브젝트이므로 의존관계 검색이라고 부르는 것이다.

스프링의 IoC 컨테이너인 애플리케이션 컨텍스트는 getBean()이라는 메소드를 제공한다. 바로 이 메소드가 의존관계 검색에 사용되는 것이다.

의존관계 검색과 의존관계 주입 방법 중 주입 쪽이 훨씬 단순하고 깔끔하다.

메소드를 이용한 의존관계 주입

수정자 메소드를 이용한 주입
- 수정자 메소드는 외부로부터 제공받은 오브젝트 레퍼런스를 저장해뒀다가 내부의 메소드에서 사용하게 하는 DI 방식에서 활용하기에 적당하다.
일반 메소드를 이용한 주입
- 임의의 초기화 메소드를 이용하는 DI는 적절한 개수의 파라미터를 가진 여러 개의 초기화 메소드를 만들 수도 있기 때문에 한 번에 모든 필요한 파라미터를 다 받아야 하는 생성자보다 낫다.

스프링은 전통적으로 메소드를 이용한 DI 방법 중에서 수정자 메소드를 가장 많이 사용해왔다.

XML을 이용한 설정

스프링은 DaoFactory와 같은 자바 클래스를 이용하는 것 외에도, 다양한 방법을 통해 DI 의존관계 설정정보를 만들 수 있다. 가장 대표적인 것이 바로 XML이다.

XML은 단순한 텍스트 파일이기 때문에 다루기 쉽다. 또, 쉽게 이해할 수 있으며 컴파일과 같은 별도의 빌드 작업이 없다는 것도 장점이다.

@Configuration = beans
@Bean = bean

하나의 @Bean 메소드를 통해 얻을 수 있는 빈의 DI 정보는 다음 세 가지다.

빈의 이름: @Bean 메소드 이름이 빈의 이름이다. 이 이름은 getBean()에서 사용된다.
빈의 클래스: 빈 오브젝트를 어떤 클래스를 이용해서 만들지를 정의한다.
빈의 의존 오브젝트: 빈의 생성자나 수정자 메소드를 통해 의존 오브젝트를 넣어준다. 의존 오브젝트도 하나의 빈이므로 이름이 있을 것이고, 그 이름에 해당하는 메소드를 호출해서 의존 오브젝트를 가져온다. 의존 오브젝트는 하나 이상일 수도 있다.

DataSource 인터페이스로 변환

DataSource 인터페이스 적용

자바에서는 DB 커넥션을 가져오는 오브젝트의 기능을 추상화해서 비슷한 용도로 사용할 수 있게 만들어진 DataSouce라는 인터페이스가 존재한다.

프로퍼티 값의 주입

값 주입

ref 대신에 value를 사용하여 주입: 일종의 DI

value 값의 자동 변환

스프링이 프로퍼티의 값을, 수정자 메소드의 파라미터 타입을 참고로 해서 적절한 형태로 변환해준다. setDriverClass() 메소드의 파라미터 타입이 Class임을 확인하고 "com.mysql.jdbc.Driver"라는 텍스트 값을 com.mysql.Driver.class 오브젝트로 자동 변경해주는 것이다.

<?xml version=1.0 encoding="UTF-8"?>
<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-3.0.xsd">
    
  <bean id="dataSource"
    class="org.springframework.jdbc.datasource.SimpleDriverDataSource">
    <property name="driverClass" value="com.mysql.jdbc.Driver" />
    <property name="url" value="jdbc:mysql://localhost/springbook" />
    <property name="username" value="spring" />
    <property name="password" value="book" />
  </bean>
  
  <bean id="userDao" class="springbook.user.dao.UserDao">
    <property name="dataSource" ref="dataSource" />
  </bean>
</beans>

정리

먼저 책임이 다른 코드를 분리해서 두 개의 클래스로 만들었다(관심사의 분리, 리팩토링).
그중에서 바뀔 수 있는 쪽의 클래스는 인터페이스를 구현하도록 하고, 다른 클래스에서 인터페이스를 통해서만 접근하도록 만들었다. 이렇게 해서 인터페이스를 정의한 쪽의 구현 방법이 달라져 클래스가 바뀌더라도, 그 기능을 사용하는 클래스의 코드는 같이 수정할 필요가 없도록 만들었다(전략 패턴).
이를 통해 자신의 책임 자체가 변경되는 경우 외에는 불필요한 변화가 발생하지 않도록 막아주고, 자신이 사용하는 외부 오브젝트의 기능은 자유롭게 확장하거나 변경할 수 있게 만들었다(개방 폐쇄 원칙).
결국 한쪽의 기능 변화가 다른 쪽의 변경을 요구하지 않아도 되게 했고(낮은 결합도), 자신의 책임과 관심사에만 순수하게 집중하는(높은 응집도) 깔끔한 코드를 만들 수 있었다.
오브젝트가 생성되고 여타 오브젝트와 관계를 맺는 작업의 제어권을 별도의 오브젝트 팩토리를 만들어 넘겼다. 또는 오브젝트 팩토리의 기능을 일반화한 IoC 컨테이너로 넘겨서 오브젝트가 자신이 사용할 대상의 생성이나 선택에 관한 책임으로부터 자유롭게 만들어줬다.(제어의 역전/IoC).
전통적인 싱글톤 패턴 구현 방식의 단점을 살펴보고, 서버에서 사용되는 서비스 오브젝트로서의 장점을 살릴 수 있는 싱글톤을 사용하면서도 싱글톤 패턴의 단점을 극복할 수 있도록 설계된 컨테이너를 활용하는 방법에 대해 알아봤따(싱글톤 레지스트리).
설계 시점과 코드에는 클래스와 인터페이스 사이의 느슨한 의존관계만 만들어놓고, 런타임시에 실제 사용할 구체적인 의존 오브젝트를 제3자(DI 컨테이너)의 도움으로 주입받아서 다이내믹한 의존관계를 갖게 해주는 IoC의 특별한 케이스를 알아봤다(의존관계 주입/DI).
의존 오브젝트를 주입할 때 생성자를 이용하는 방법과 수정자 메소드를 이용하는 방법을 알아봤다(생성자 주입과 수정자 주입).
마지막으로, XML을 이용해 DI 설정정보를 만드는 방법과 의존 오브젝트가 아닌 일반 값을 외부에서 설정해서 런타임 시에 주입하는 방법을 알아봤다(XML 설정).

스프링이란 '어떻게 오브젝트가 설계되고, 만들어지고, 어떻게 관계를 맺고 사용되는지에 관심을 갖는 프레임워크'

스프링의 관심은 오브젝트와 그 관계다. 하지만 오브젝트를 어떻게 설계하고, 분리하고, 개선하고, 어떤 의존관계를 가질지 결정하는 일은 스프링이 아니라 개발자의 역할이며 책임이다. 스프링은 단지 원칙을 잘 따르는 설계를 적용하려고 할 때 필연적으로 등장하는 번거로운 작업을 편하게 할 수 있도록 도와주는 도구일 뿐이다.

김주형

도광양회

이전 포스트

[토비의 스프링 Vol.1 ] - 스프링의 이해와 원리

Web Basic

오브젝트와 의존관계

초난감 DAO

User

UserDao

DAO의 분리

관심사의 분리

커넥션 만들기의 추출

UserDao의 관심사항

중복 코드의 메소드 추출

DB 커넥션 만들기의 독립

상속을 통한 확장

디자인 패턴

템플릿 메소드 패턴

팩토리 메소드 패턴

DAO의 확장

클래스의 분리

인터페이스의 도입

관계설정 책임의 분리

원칙과 패턴

개방 폐쇄 원칙

높은 응집도와 낮은 결합도

전략 패턴

제어의 역전(IoC)

오브젝트 팩토리

팩토리

오브젝트 팩토리의 활용

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

스프링의 IoC

오브젝트 팩토리를 이용한 스프링 IoC

애플리케이션 컨텍스트와 설정정보

DaoFactory를 사용하는 애플리케이션 컨텍스트

애플리케이션 컨텍스트의 동작방식

스프링 IoC 용어 정리

싱글톤 레지스트리와 오브젝트 스코프

싱글톤 레지스트리로서의 애플리케이션 컨텍스트

서버 애플리케이션과 싱글톤

싱글톤 패턴의 한계

싱글톤 레지스트리

싱글톤과 오브젝트의 상태

스프링 빈의 스코프

의존관계 주입(DI)

런타임 의존관계 설정

의존관계

UserDao의 의존관계

의존관계 검색과 주입

메소드를 이용한 의존관계 주입

XML을 이용한 설정

DataSource 인터페이스로 변환

DataSource 인터페이스 적용

프로퍼티 값의 주입

값 주입

value 값의 자동 변환

정리

Why Spring Boot?

0개의 댓글