📄 토비 스프링 3장 정리

🟢 예외 상황에 대한 처리

JDBC 수정 기능의 예외처리 코드

public void deleteAll() throws SQLException {
  Connection c = dataSource.getConnection();
  
  PreparedStatement ps = c.preparedStatement("delete from users");
  
  ps.close();
  c.close();
}

위 메소드는 Connection과 PreparedStatement라는 두 개의 공유 리소스를 가져와서 사용하고 있다. 정상적으로 처리하면 close()가 호출되면서 리소스를 반환한다. 만약에 PreparedStatement를 처리하는 도중에 예외가 발생하면 어떻게 될까? 이때는 메소드 실행이 제대로 끝마치지 못한채 메소드를 빠져나가게된다. 따라서 close() 메소드가 실행되지 않아서 제대로 리소스가 반환되지 않는다.

일반적으로 서버는 제한된 개수의 DB 커넥션을 만들어서 재사용 가능한 풀로 관리한다. DB 풀은 매번 getConnection()으로 가져간 커넥션을 명시적으로 close()해서 돌려줘야지지만 다시 풀에 넣었다가 다음 커넥션 요청이 있을 때 재사용할 수 있다.

앞서 이야기한 Connection과 PreparedStatement가 제대로 반환되지 못하는 상황을 생각해보자. 이런 상황이 계속 쌀이게 되면 어느 순간에 커넥션 풀에 여유가 없어지고 리소스가 모자란다는 심각한 오류가 일어나고 서버가 중지될 것이다. 따라서 위 코드는 클라이언트를 위한 지속적인 서버 운영에 치명적인 약점을 내포하고 있다.

---

리소스 반환과 close()에 대해

connection이나 PreparedStatement에는 close() 메소드가 있다. 이때 close는 리소스를 반환한다는 의미로 이해하는 것이 좋다. Connection 과 PreparedStatement는 보통 풀(pool)방식으로 운영된다. pool 방식이란 자주쓰는 객체를 미리 만들어놓고 필요할 때마다 빌리고 사용한 다음 반납하는 방식이다. 따라서 풀 안에 제한된 수의 리소스(Connection, Statement)를 만들어 두고 필요할 때 할당하고 반환하여 다시 풀에 넣는 방식으로 운영된다. 즉 요청이 매우 많은 서버환경에서는 매번 새로운 리소스를 생성하는 대신 풀에 미리 만들어둔 리소스를 돌려가며 사용하는 편이 훨씬 유리하다. 그리고 사용한 리소스는 빠르게 반환해야한다. 이 때 그렇지 못하면 풀에 있는 리소스가 고갈되고 문제가 발생한다. 위에서 말한 close()는 사용한 리소스를 돌려주는 역할을 한다.

---

그래서 JDBC코드에서는 이런 예외 상황에서도 가져온 리소스를 반환할 수 있도록 try/catch/finally 사용을 권장한다. 아래는 deleteAll()메소드를 변환한 것이다.

public void deleteAll() throws SQLExceptions {
  Connection c = null;
  PrepareStatement ps = null;
  
  try {
    c = dataSource.getConnection();
    ps = c.preparedStatement("delete from users");
    ps.executeUpdate();
  } catch(SQLException e) {
    throw e;
  } finally {
    if (ps != null) {
      try {
        ps.close();
      } catch(SQLException e) {
      }
    }
    if (c != null) {
      try {
        c.close();
      } catch (SQLException e) {
      }
    }
  }
}

이제 예외 상황에서도 안전안 코드가 되었다. finally는 try 블록을 수행한 후에 예외가 발생하든 정상적으로 처리되었든 상관없이 반드시 실행되는 코드를 넣었을 때 사용한다. 일단 try 블록으로 들어섰다면 반드시 connection이나 PreparedStatement의 close() 호출을 통해 가져온 리소스를 반환해야 한다. 이제 따로 고려해야할 상황은 Connection과 PreparedStatement중 어떤 것의 close() 메소드를 호출해야 할지가 달라진다는 것이다.

만약에 getConnection()에서 DB 커넥션을 가져오다가 일시적인 DB 서버 문제나, 네트워크 문제 또는 그 밖의 예외상황 때문에 예외가 발생했다면 ps는 물론이고 변수 c도 아직 null 상태이다. null 상태의 변수에 close() 메소드를 호출하면 안 된다.

PreparedStatement를 생성하다가 예외가 발생했다면 그떄는 c 변수가 커넥션 객체를 갖고 있는 상태이니 c는 close()호출이 가능한 반면 ps는 아니다. 만약 ps를 실행하다가 예외가 발생한 경우라면, ps와 c 모두 close()메소드를 호출해줘야 한다. 어느 시점에서 예외가 발생했는지에 따라서 close()를 사용할 수 있는 변수가 달라질 수 있기 때문에 finally에서는 반드시 c와 ps가 null이 아닌지 먼저 확인한 후에 close() 메소스를 호출해야 한다.

다른 문제로는 지금 close()도 SQLException이 발생할 수 있는 메소드라는 점이다. 따라서 try/catch 문으로 처리한다. 물론 close()가 실패했을 때는 특별히 할 조치는 없기 때문에 비워둔다. 이때 이미 deleteAll()에 SQLException이 던져진다고 선언되어 있으니 close()를 사용하지 않아도 되지 않을까 라는 생각을 할 수 있다. [ SQLException에 던져진다.는 의미가 무엇일까..? ]

---

SQLException에 던져진다.를 알아보았다.

여기서 던진다는 것의 약간 메소드 사이에 존재하는 책임 전가라는 의미를 지니고 있는거 같다.(물론 내 생각이다.)

throws: 예외를 전가시키는 것

throw: 강제로 예외를 발생시키는 것

즉 throws는 전가, throw는 프로그래머의 판단에 따른 처리이다.

조금 더 자세히 알아보면 throws를 사용하면, 해당 메소드를 호출하는 곳에서 예외를 처리해줘야 한다.

throw는 예외를 강제로 발생시키는 것이다. 프로그래머의 판단에 따라 해당 부분에 예외를 발생시켜야 하는 부분에 throw를 사용한다.

---

🟢 변하는 것과 변하지 않는 것

앞서 try/catch/finally로 고친 코드의 문제점은 계속해서 같은 코드를 반복하고 있다는 점이다. 반복된 코드를 계속 사용하다보면, 실수, 유지보수 등 매우 많은 것이 빠질 위험이 있기 때문에 조심해야 하는데, 위에서 작성한 try/catch/finally도 같은 이치를 갖고 있다. 따라서 이를 방지하기 위한 방법이 있다고 한다.

UserDao의 메소드를 개선하는 작업을 시작해보자. 가장 먼저 할 일은 변하는 성격이 다른 것을 찾아내는 것 deleteAll()메소드의 코드를 다시 살펴보자.

Connection c = null;
PreparedStatement ps = null;
// ---- 변한지 않는 부분 ----
try {
  c = dataSource.getConnection();
// ---------------------- 
  ps = c.preparedStatement("delete from users"); // → 변하는 부분
// ---- 변한지 않는 부분 ----
  ps.executeUpdate();
} catch (SQLException e) {
  throw e;
} finally {
  if (ps != null) { try {ps.close();} catch (SQLException e) {} }
  if (c != null) { try {c.close();} catch (SQLException e) {} }
 // ---------------------- 
}

1. 메소드 추출

먼저 생각해 볼 수 있는 것은 변하는 부분을 메소드로 빼는 것이다. 변하는 부분을 메소드로 추출하고 변하지 않는 부분에서 호출하도록 만들면, 어렵다고 생각한 작업을 해결할 수 있다.

public void deleteAll() throws SQLExceptions {
  //...
  try {
    c = dataSource.getConnection();
    
    ps = makeStatement(c);
    
    ps.executeUpdate(c);
  } catch (SQLException e) {
    //...
  }
 //... 
}

private PreparedStatement makeStatement(Connection c) throws SQLException {
  PreparedStatement ps;
  ps = c.prepareStatement("delete from users");
  return ps;
}

자주 바뀌는 부분을 메소드로 독립시켰는데 당장 봐서는 별 이득이 없어 보인다. 왜냐하면 보통 메소드 추출 리펙토링을 적용하는 경우에는 분리시킨 메소드를 다른 곳에서 재사용할 수 있어야 하는데, 이건 반대로 분리시키고 남은 메소드가 재사용이 필요한 부분이고 분리된 메소드는 DAO 로직마다 새롭게 만들어서 확장돼야 하는 부분이기 때문이다. 뭔가 반대로 됐다.

2. 템플릿 메소드 패턴의 적용

템플릿 메소드 패턴을 이용해서 분리할 수 있다. 템플릿 메소드 패턴은 상속을 통해 기능을 확장해서 사용하는 부분이다. 변하지 않는 부분은 슈퍼클래스에 두고 변하는 부분은 추상 메소드로 정의해둬서 서브클래스에서 오버라이드하여 새롭게 정의해 쓰도록 하는 것이다.

추출해서 별도의 메소드로 독립시킨 makeStatement()메소드를 다음과 같이 추상 메소드 선언으로 변경한다. 물론 UserDao 클래스도 추상 클래스가 돼야 할 것이다.

abstract protected PreparedStatement makeStatement(Connection c) throws SQLException;

그리고 이를 상속하는 서브클래스를 만들어서 거기서 이 메소드를 구현한다. 고정된 JDBC try/catch/finally 블록을 가진 슈퍼클래스 메소드와 필요에 따라서 상속을 통해 구체적인 PreparedStatement를 바꿔서 사용할 수 있게 만드는 서브클래스로 깔끔하게 분리할 수 있다. 다음은 UserDao를 상속해서 만든 클래스이다.

public class UserDaoDeleteAll extends UserDao {
  protected PreparedStatement makeStatement(Connection c) throws SQLException {
    PreparedStatement ps = c.prepareStatement("delete from users");
    return ps;
  }
}

이렇게 UserDao 클래스에서 UserDaoDeleteAll을 확장하므로써 UserDao 클래스의 기능을 확장하고 싶을 때마다 상속을 통해 자유롭게 확장할 수 잇고, 확장 때문에 기존의 상위 DAO 클래스에 불필요한 변화는 생기지 않도록 할 수 있으니 객체지향 설계의 핵심 원리인 개발 폐쇄 원칙(OCP)을 지키는 구조를 만들어 낼 수는 있는 것 같다. 하지만 탬플릿 메소드 패턴으로의 접근은 제한이 많다. 가장 큰 문제는 DAO 로직마다 상속을 통해 새로운 클래스를 만들어야 한다는 저이다. 만약 이 방식을 사용한다면 UserDao의 JDBC 메소드가 4개일 경우 4개의 서브 클래스를 만들어서 사용해야 한다. (뭐지…? 이럴거면 굳이 이렇게 만들 필요가 있나?)

즉 이러한 과정을 통해 확장을 꾀하는 템플릿 메소드 패턴의 단점이 고스란히 드러난다.

3. 전략 패턴의 적용

개방 패쇄 원칙을 잘 지키는 구조이면서도 템플릿 메소드 패턴보다 유연하고 확장성이 뛰어난 것이 오브젝트를 아예 둘로 분리하고 클래스 레벨에서는 인터페이스를 통해서만 의존하도록 만드는 전략 패턴이다.

전략 패턴은 OCP 관점에 보면 확장에 해당하는 변하는 부분을 병도의 클래스로 만들어 추상화된 인터페이스를 통해 위임하는 방식이다. 이렇듯 deleteAll()은 JDBC를 이용해 DB를 업데이트 하는 작업이라는 변하지 않는 맥락을 갖는다. deleteAll()의 컨텍스트를 정리하면 다음과 같다.

• DB 커넥션 가져오기
• PreparedStatement를 만들어줄 외부 기능 호출하기
• 전달받은 PreparedStatement 실행하기
• 예외가 발생하면 이를 다시 메소드 밖으로 던지기
• 모든 경우에 만들어진 PreparedStatement와 connection을 적절히 닫아주기

여기서 2번째 작업에서 사용하는 PreparedStatement를 만들어주는 외부 기능이 바로 전략 패턴에서 말하는 전략이라고 볼 수 있다. 전략 패턴 구조를 따라 이 기능을 인터페이스로 만들어두고 인터페이스의 메소드를 통해 PreparedStatement를 생성하는 전략을 호출할 때는 이 컨텍스트 내에서 만들어둔 DB 커넥션을 전달해야 한다는 점이다. 즉 커넥션이 없으면 PreparedStatement도 만들 수 없다.

PreparedStatement를 만드는 전략의 인터페이스는 컨텍스트가 만들어둔 Connection을 전달받아서 PreparedStatement를 만들고 만들어진 PreparedStatement 오브젝트를 돌려준다. 이 내용을 인터페이스로 정의하면 다음과 같다.

package springbook.user.dao;

public interface StatementStrategy {
  PreparedStatement makePreparedStatement(Connection c) throws SQLException;
}

위 인터페이스를 상속해서 실제 전략, 즉 바뀌는 부분인 PreparedStatement를 생성하는 클래스를 만들어보자. deleteAll() 메소드의 기능을 위해 만든 전략 클래스는 다음과 같다.

package springbook.user.dao;

public class DeleteAllStatement implements StatementStrategy {
  public PreparedStatement makePreparedStatement(Connection c) throws SQLException {
    PreparedStatement ps = c.prepareStatement("delete from users");
    return ps;
  }
}

전략 패턴에 따라 DeleteAllStatement가 deleteAll() 메소드에 적용해보자.

public void deleteAll() throws SQLException {
  
  try {
    c = dataSource.getConnection();
    
    statementStrategy strategy = new DeleteAllStatement();
    ps = strategy.makePreparedStatement(c);
    
    ps.executeUpdate();
  } catch (SQLException e) {
    
  }
}

위 코드처럼 컨텍스트 안에서 이미 구체적인 전략 클래스인 DeleteAllStatement를 사용하도록 고정되어 있다면 뭔가 이상하다. 컨텍스트가 StatementStrategy 인터페이스뿐 아니라 특정 구현 클래스인 DeleteAllStatement를 직접 알고 있다는 건, 전략 패턴에도 OCP에도 잘 맞지 않는다.

4. DI 적용을 위한 클라이언트/컨텍스트 분리