ChoiSing Blog

도서 - 스프링부트 실전 활용 마스터 1,2장

Tue, 27 Jul 2021 00:00:00 +0000

스프링부트 실전 활용 마스터 (~ 2장)

1장. 스프링 부트 웹 애플리케이션 만들기

스프링 부트란 무엇인가

스프링 포트폴리오를 신속하게 미리 정의된 방식으로, 이식성 있게, 실제 서비스 환경에 사용할 수 있도록 조립해놓은 것
- 신속성 : 의존관계를 포함한 여러 요소에 의사결정을 신속히
- 미리 정의된 방식 : 기본적인 설정값이 자동 지정.
- 이식성
스프링 프레임워크 5.0에 포함된 새로운 패러다임 리액트 프로그래밍
- 대규모 사용자가 지속적으로 증가하는 시스템을 만들다 보면,
  - 비동기
  - 논블로킹
  - 방식의 처리가 필요할 때가 있다.

리액티브 프로그래밍 소개

리액티브 스트림
- 기존 자원을 더 효율적이고 일관성 있게 사용하는 해법
- 발행자와 구독자 사이의 간단한 계약
  - 트래픽을 가능한한 빨리 발행하는 대신에
  - 구독자가 “난 10개만 더 받을 수 있어” 발행자에게 알림
  - 발행자는 10개만 더보낸다.
  - 수요조절 (demand control), 배압(backpressure)
프로젝트 리액터
- VM 웨어에서 만든 리액티브 스트림 구현체.
- 논블로킹, 비동기 프로그래밍 모델
- 함수형 프로그래밍
- 스레드를 신경 쓸 필요 없는 동시성

리액터 타입

리액티브 스트림은 수요조절에 기반하고 있다.
프로젝트 리액터는 핵심 타입인 Flux<T> 를 사용하여 수요 조절을 구현한다.

class KitchenService {
    Flux<Dish> getDishes() {
        return Flux.just(
            new Dish("Sesame chicken"),
            new Dish("Lo mein noodles, plain"),
            new Dish("Sweet & sour beef"))
    }
}

Flux<T> 는 실제 물건을 전달해주는 역할을 하는 플레이스홀더
- 비유, 레스토링 서빙 점원과 비슷하다.
- 주방에서 요리가 완성되면, 주방에서 요리를 받아 손님에게 가져다 주고, 다시 제자리로 돌아와 다음 요리를 기다린다.
- 서빙 점원은 요리가 언제 주방에서 완성될 지 알 수 없다.
- 언제가 됐든 요리가 완성되고, 서빙 점원이 그 요리를 받아서 전달할 수 있는 상태라면, 서빙점원은 다음 요리를 손님에게 가져다준다.
서빙점원은 손님에게 가져다줄 Dish 객체를 달라고 KitchenService 에 요청할 수 있다. 코드에 나온 세 가지 요리가 모두 완성된 후에 받을수도 있지만, Flux<Dish> 객체로 바로 받을 수도 있다.
- Flux<Dish> 안에 포함된 요리는 아직은 완성되지 않았지만, 머지않아 완성될 것이고, 언제 완성될 지는 알 수 없다.
요리가 완성되면 서빙 점원은 행동(act)에 나설 수 있다. 즉 요리 완성에 대한 react
- 리액터는 non-blocking 방식으로 동작하기 때문에, 주방에서 요리가 완성될 때까지 서빙 점원(서버 스레드)이 다른 일을 못 한 채 계속 기다리게 하지 않는다.
결과가 아직 정해지지 않았고 미래 어느 시점이 되어야 알 수 있다는 점에서 Flux 는 Future와 비슷하다.
- Futrue 는 이미 시작되었음을, Flux는 시작할 수 있음을 나타낸다.
Flux 의 특징
- 하나 이상의 Dish 포함 가능
- 각 Dish가 제공될 때 어떤 일이 발생하는지 지정 가능
- 성공과 실패의 두 가지 경로 모두에 대한 처리 방향 정의 가능
- 결과 폴링 불필요
- 함수형 프로그래밍 지원

2장. 스프링 부트를 활용한 데이터 액세스

리액티브 데이터 스토어 요건

리액티브 프로그래밍은 여러 가지 오버헤드를 수반하므로 성능저하가 발생한다.
- 사용자 수가 작고 데이터도 많지 않다면 불필요한 오버헤드를 감수하면서 리액티브를 사용하는 것은 낭비다.
- 하지만 대규모 트래픽, 대용량 데이터 처리 환경에서는 장점이 빛을 발하게 된다.
  - 스레드는 어떤 작업이 끝날 때까지 블로킹 되어 기다리지 않고 다른 작업을 수행할 수 있다.
리액티브가 제대로 동작하려면 DB도 리액티브 하게 동작해야 한다.
- 지원하는 DB
  - 몽고DB
  - Redis (Lettuce)
  - ES
  - 등등
관계형 데이터베이스는 ㄴㄴ

테스트 데이터 로딩

애플리케이션 시작 시점에 subcribe() 를 하면 이벤트 루프를 deadlock 상태에 빠뜨릴 수 있는 위험이 존재한다.
- 이유를 모르겠음

강의 - Kotlin으로 개발하는 Spring boot (작성중)

Tue, 29 Jun 2021 00:00:00 +0000

Kotlin으로 개발하는 Spring boot

URI 설계원칙 (RFC-3986)

URI 마지막 문자로 (/) 는 포함하지 않는다.
하이픈(-)은 URI 가독성을 높이는데 사용한다.
밑줄(_)은 사용하지 않는다.
URI 경로에는 소문자가 적합하다.
파일 확장자를 포함하지 않는다.
세션 ID를 포함하지 않는다.
프로그래밍 언어의 Method 명을 이용하지 않는다.
명사에 단수형 보다는 복수형을 사용한다.
CRUD 기능을 나타내는 것은 URI 에 사용하지 않는다.

HTTP

HTTP status code
- 1xx
  - 의미 : 처리중
  - 처리가 계속되고 있는 상태, 클라이언트는 요청을 계속하거나 서버의 지시에 따라 재요청

도서 - 토비의 스프링 3.1 Vol 1, 5장~8장

Thu, 01 Apr 2021 00:00:00 +0000

토비의 스프링 3.1 Vol 1 (317p ~ 751p)

5장 서비스 추상화

5.1 사용자 레벨 관리 기능 추가

요구사항
- 사용자 레벨은 BASIC, SILVER, GOLD 세 가지 중 하나다.
- 사용자가 처음 가입하면 BASIC, 이후 활동에 따라 한 단계씩 업그레이드 가능
- 가입 후 50회 이상 로그인을 하면 BASIC -> SILVER
- SILVER 레벨이면서 30번 이상 추천을 받으면 GOLD
- 사용자 레벨 변경 작업은 일정한 주기를 가지고 일괄 진행.
  - 변경 작업 전에는 조건을 충족하더라도 레벨 변경이 일어나지 않는다.

Level Enum 추가

public enum Level {
  BASIC(1), SILVER(2), GOLD(3);

  private final int value;

  Level(int value) {
      this.value = value;
  }

  public int intValue() {
      return this.value;
  }

  public static Level valueOf(int value) {
      switch (value) {
          case 1 : return BASIC;
          case 2 : return SILVER;
          case 3 : return GOLD;
          default: throw new AssertionError("Unknown value: " + value);
      }
  }
}

User Class field 추가

public class User {
...
  @Column(name = "level", nullable = false)
  private Level level;

  @Column(name = "login", nullable = false)
  private int login;

  @Column(name = "recommend", nullable = false)
  private int recommend;
...
}

UserJdbcDao 수정

public class UserJdbcDao implements UserDao {
  ...

  private RowMapper<User> userMapper = new RowMapper<User>() {
      @Override
      public User mapRow(ResultSet rs, int rowNum) throws SQLException {
          User user = new User();
          user.setId(rs.getString("id"));
          user.setName(rs.getString("name"));
          user.setPassword(rs.getString("password"));
          user.setLevel(Level.valueOf(rs.getInt("level")));
          user.setLogin(rs.getInt("login"));
          user.setRecommend(rs.getInt("recommend"));
          return user;
      }
  };

  ...
  @Override
  public void add(final User user) {
      this.jdbcTemplate.update("insert into user (id, name, password, level, login, recommend) values (?,?,?,?,?,?)",
              user.getId(), user.getName(), user.getPassword(), user.getLevel().intValue(), user.getLogin(), user.getRecommend());
  }

  @Override
  public User get(String id) {
      return this.jdbcTemplate.queryForObject("select * from user where id = ?", new Object[]{id}, this.userMapper);
  }
  ...
}

5.1.2 사용자 수정 기능 추가

Test Code 먼저 추가

public class UserDaoTest {
  ...

  @Test
  public void update() {
      dao.deleteAll();

      dao.add(user1);

      user1.setName("name");
      user1.setPassword("5678");
      user1.setLevel(Level.GOLD);
      user1.setLogin(1000);
      user1.setRecommend(999);

      dao.update(user1);

      User updateUser1 = dao.get(user1.getId());
      checkSameUser(user1, updateUser1);
  }
}

UserJdbcDao update method 추가 (interface 에도 추가)

public class UserJdbcDao implements UserDao {
...

  @Override
  public void update(User user) {
      this.jdbcTemplate.update(
              "update user " +
                      "set name = ?, password = ?, level = ?, login = ?, recommend = ?" +
                      "where id = ?",
              user.getName(), user.getPassword(), user.getLevel().intValue(), user.getLogin(), user.getRecommend(), user.getId());
  }
}

5.1.3 UserService.upgradeLevels()

드디어 service layer 등장
- dao 는 데이터 액세스가 목적이므로, 비지니스 로직은 해당 클래스에 어울리지 않는다.
- 비지니스 로직을 담을 service 클래스를 추가한다.

UserService class

public class UserService {

  private UserDao userDao;

  public UserService(UserDao userDao) {
      this.userDao = userDao;
  }

  public void upgradeLevels() {
      List<User> users = userDao.getAll();

      for (User user : users) {
          boolean changed = false;

          if (user.getLevel() == Level.BASIC && user.getLogin() >= 50) {
              user.setLevel(Level.SILVER);
              changed = true;
          } else if (user.getLevel() == Level.SILVER && user.getRecommend() >= 30) {
              user.setLevel(Level.GOLD);
              changed = true;
          }

          if (changed) {
              userDao.update(user);
          }
      }
  }
}

Test

class UserServiceTest {

  @Autowired
  private UserService userService;

  @Autowired
  private UserDao userDao;

  private List<User> users;

  @BeforeEach
  public void setUp() {
      users = Arrays.asList(
              new User("id1", "name1", "p1", Level.BASIC, 49, 0),
              new User("id2", "name2", "p2", Level.BASIC, 50, 10),
              new User("id3", "name3", "p3", Level.SILVER, 60 ,29),
              new User("id4", "name4", "p4", Level.SILVER, 60 ,30),
              new User("id5", "name5", "p5", Level.GOLD, 100 ,100)
      );
  }

  @Test
  public void upgradeLevels() {
      userDao.deleteAll();

      for (User user : users) {
          userDao.add(user);
      }

      userService.upgradeLevels();

      checkLevel(users.get(0), Level.BASIC);
      checkLevel(users.get(1), Level.SILVER);
      checkLevel(users.get(2), Level.SILVER);
      checkLevel(users.get(3), Level.GOLD);
      checkLevel(users.get(4), Level.GOLD);
  }

  private void checkLevel(User user, Level expectedLevel) {
      User userUpdate = userDao.get(user.getId());
      Assertions.assertEquals(userUpdate.getLevel(), expectedLevel);
  }
}

5.1.4 UserService.add()

처음 가입하는 사용자의 레벨을 BASIC 으로 설정하고 싶다.
- DAO 에 담기에는 비지니스 로직이 개입되는 행위라 적절하지 않다.
- 엔티티인 User 클래스에서 필드를 BASIC 으로 초기화 하는 것은 어떨까?
  - 난 좋은 것 같은데 필자는 처음 외에 무의미한 정보인데 굳이? 라는 입장
- 비지니스 로직을 담고있는 service 에서 해보자
  - level 이 없는 경우 basic, 있는 경우 유지.

테스트 클래스

class UserServiceTest {
  ...
  @Test
  public void add() {
      userDao.deleteAll();

      User userWithLevel = users.get(4); // gold
      User userWithoutLevel = users.get(0);
      userWithoutLevel.setLevel(null);

      userService.add(userWithLevel);
      userService.add(userWithoutLevel);

      User userWithLevelRead = userDao.get(userWithLevel.getId());
      User userWithoutLevelRead = userDao.get(userWithoutLevel.getId());

      assertEquals(userWithLevelRead.getLevel(), userWithLevel.getLevel());
      assertEquals(userWithoutLevelRead.getLevel(), Level.BASIC);
  }
  ...
}

UserService 클래스

public class UserService {

  ...

  public void add(User user) {
      if (user.getLevel() == null) {
          user.setLevel(Level.BASIC);
      }

      userDao.add(user);
  }

  ...
}

5.1.5 코드 개선

작성된 코드를 살펴볼 때 아래와 같은 질문
- 중복은 없는가
- 코드의 행위가 이해하기 편한가
- 코드가 자신이 있어야할 자리에 있는가
- 변경에 유연한 구조인가
upgradeLevels() 리팩토링
1 : 현재 레벨 파악
2 : 업그레이드 조건 판단
3 : 레벨 업그레이드
4 : DB 저장
성격이 다른 로직이 한데 섞여 있다.
추상적으로, upgradeLevels() 에는 loop 을 돌며 업그레이드가 가능하면 업그레이드 한다. 라는 작업 흐름만 명시

List<User> users = userDao.getAll();

for (User user : users) {
    if (canUpgradeLevel(user)) {
        upgradeLevel(user);
    }
}

canUpgradeLevel() 메소드

private boolean canUpgradeLevel(User user) {
    Level currentLevel = user.getLevel();
    switch (currentLevel) {
        case BASIC: return (user.getLogin() >= 50);
        case SILVER: return (user.getRecommend() >= 30);
        case GOLD: return false;
        default: throw new IllegalArgumentException("Unknow Level: " + currentLevel);
    }
}

upgradeLevel() 메소드도 추상적인 작업흐름(업데이트, DB저장)만 명시

private void upgradeLevel(User user) {
    user.upgradeLevel();
    userDao.update(user);
}

User Class

public class User {
    ...
    public void upgradeLevel() {
        Level nextLevel = this.level.nextLevel();
        if (nextLevel == null) {
            throw new IllegalStateException(this.level + " is cannot upgrade.");
        }

        this.level = nextLevel;
    }
    ...
}

Level Enum

public enum Level {
    GOLD(3, null), SILVER(2, GOLD), BASIC(1, SILVER);

    private final int value;

    private final Level next;
    
    ...
}

오브젝트와 메소드가 각각 자기 몫의 책임을 맡아 일을 하는 구조로 설계하는 것이 바람직하다.
- 책임 분리, 변경/확장 유연성 확보
- 데이터를 가져와서 작업하지 않고, 다른 오브젝트에 작업을 요청
추가적으로, 업그레이드 정책을 유연하게 변경할 수 있도록 개선할 수 있다.
- 연말이벤트, 홍보기간 레벨 업그레이드 정책을 다르게 적용할 수도 있기 때문
업그레이드 정책 인터페이스화

public interface UserLevelUpgradePolicy {

    boolean canUpgradeLevel(User user);

    void upgradeLevel(User user);
}

구현체 class

public class UserLevelUpgradePolicyDefault implements UserLevelUpgradePolicy {

    public static final int MIN_LOGIN_COUNT_FOR_SILVER = 50;
    public static final int MIN_RECOMMEND_FOR_GOLD = 30;

    private UserDao userDao;

    public UserLevelUpgradePolicyDefault(UserDao userDao) {
        this.userDao = userDao;
    }

    @Override
    public boolean canUpgradeLevel(User user) {
        Level currentLevel = user.getLevel();
        switch (currentLevel) {
            case BASIC: return (user.getLogin() >= MIN_LOGIN_COUNT_FOR_SILVER);
            case SILVER: return (user.getRecommend() >= MIN_RECOMMEND_FOR_GOLD);
            case GOLD: return false;
            default: throw new IllegalArgumentException("Unknow Level: " + currentLevel);
        }
    }

    @Override
    public void upgradeLevel(User user) {
        user.upgradeLevel();
        userDao.update(user);
    }
}

서비스 class 에 DI 하여 적용

public class UserService {
    
    ...

    private UserLevelUpgradePolicy userLevelUpgradePolicy;

    ...
        public void upgradeLevels() {
        List<User> users = userDao.getAll();

        for (User user : users) {
            if (userLevelUpgradePolicy.canUpgradeLevel(user)) {
                userLevelUpgradePolicy.upgradeLevel(user);
            }
        }
    }
}

5.2 트랜잭션 서비스 추상화

사용자 레벨 조정 작업 중간에 문제가 발생하면, 현재 코드는 롤백이 될까 커밋이 될까.
장애상황을 연출하려 할 때, 애플리케이션 코드를 수정하는 것은 가장 쉽지만 바람직하지 않다.

테스트용 클래스를 만들고, DI 하여 테스트

class UserServiceTest {
  ...

  @Test
  public void upgradeAllOrNothing() {
      userService.setUserLevelUpgradePolicy(new UserLevelUpgradePolicyTest(userDao, users.get(3).getId()));
      userDao.deleteAll();

      for (User user : users) {
          userDao.add(user);
      }
      Assertions.assertThrows(TestUserServiceException.class, () -> {
          userService.upgradeLevels();
      });

      checkLevel(users.get(1), false);    // 앞에 업그레이드 한 것이 롤백이 되면 테스트가 성공.
  }

  static class UserLevelUpgradePolicyTest extends UserLevelUpgradePolicyDefault {

      private String id;

      public UserLevelUpgradePolicyTest(UserDao userDao, String id) {
          super(userDao);
          this.id = id;
      }

      @Override
      public void upgradeLevel(User user) {
          if (user.getId().equals(this.id)) {
              throw new TestUserServiceException();
          }

          super.upgradeLevel(user);
      }
  }

  static class TestUserServiceException extends RuntimeException {

  }
}

테스트는 실패한다. 중간에 실패하더라도, 이미 업그레이드가 되었다.

테스트 실패의 원인은 upgradLevels() 메소드가 하나의 트랜잭션 안에서 동작하기 않았기 때문

5.2.2 트랜잭션 경계 설정

DB는 완벽한 트랜잭션을 제공한다.
- SQL을 이용해 다중 로우 수정, 삭제 시 부분성공/실패 하는 경우는 없다.
- 즉, 하나의 SQL 명령을 처리하는 경우 DB가 트랜잭션을 보장한다.
하지만, 여러 SQL 을 하나의 트랜잭션으로 처리해야 하는 경우
- 첫번째 SQL 이 성공하고 두번째 SQL 이 실패하면 Rollback 이 필요.
- 모든 SQL이 성공하였을 때 Commit.
JDBC 를 이용해 트랜잭션을 적용하는 간단한 예제

...
Connection c = datasource.getConnection();

c.setAutoCommit(false); // Transaction Start

try {
    PreparedStatement st1 = c.prepareStatement("update users ...");
    st1.executeUpdate();
    
    PreparedStatement st2 = c.prepareStatement("update users ...");
    st2.executeUpdate();

    c.commit(); // Transaction commit
} catch(Exception e) {
    c.rollback(); // Transaction rollback
}

c.close();

애플리케이션에서 트랜잭션이 시작되고 종료되는 위치를 트랜잭션의 경계 라 한다.
- setAutoCommit(false) 로 트랜잭션 시작을 선언하고 commit() 또는 rollback() 으로 트랜잭션을 종료하는 작업을 트랜잭션의 경계설정(transaction demarcation) 이라 한다.
- 트랜잭션의 경계는 하나의 Connection이 만들어지고 닫히는 범위 안에 존재한다.
  - 이렇게 하나의 DB 커넥션 안에서 만들어지는 트랜잭션을 로컬 트랜잭션 이라고도 한다.
현재는 DAO 메소드를 호출할 때마다 하나의 새로운 트랜잭션이 만들어지는 구조
- DAO 메소드 안으로 upgradeLevels() 메소드 내용을 옮긴다면 비지니스 로직과 데이터 로직이 한데 묶여 섞이는 결과를 초래한다.
- 위와 같은 방식이 아닌, 트랜잭션의 경계설정 작업을 UserService 쪽으로 가져와야 한다.
- Connection 을 Service 에서 생성하여 파라미터로 전달한다면 문제는 해결할 수 있다.
  - 하지만 DB 커넥션을 포함한 리소스 처리를 Service 레이어에서 해야하고,
  - Connection 파라미터가 세상 끝까지 추가되어야 하고,
  - Service 레이어가 Data Access 기술에 종속적이 된다.
  - 스프링은 이 딜레마를 해결할 수 있는 멋진 방법을 제공한다.
트랜잭션 동기화 방식
1. UserService 는 Connection 생성
2. 이를 트랜잭션 동기화 저장소에 저장해두고 Connection의 setAutoCommit(false)를 호출해 트랜잭션을 시작시키고 DAO 의 기능을 이용하기 시작.
3. DAO 의 첫번째 update() 메소드가 호출되고, update() 메소드 내부에서 이용하는 JdbcTemplate 메소드에서는 가장먼저
4. 트랜잭션 동기화 저장소에 현재 시작된 트랜잭션을 가진 Connection 오브젝트가 존재하는지 확인한다. (2)에서 저장해둔 Connection 을 발견하고 이를 가져온다.
5. 가져온 Connection 을 이용하여 PreparedStatement를 만들어 수정 SQL 을 실행, 트랜잭션 동기화 저장소에서 DB 커넥션을 가져왔을 때는 JdbcTemplate은 Connection 을 닫지 않은 채로 작업을 마친다. (첫 번째 DB 작업 완료, Connection 은 열려있고, 트랜잭션은 진행 중, 트랜잭션 동기화 저장소에 저장)
6. N번째 update()가 호출되면 이 때도 마찬가지로 작업을 한다.
7. 트랜잭션 내 모든 작업이 정상적으로 끝났다면 UserService 는 Connection commit() 을 호출하여 트랜잭션을 완료시킨다.
8. 마지막으로 트랜잭션 저장소가 더 이상 Connection 오브젝트를 저장해두지 않도록 이를 제거한다.
  - 어느 작업 중에라도 예외 발생 시 UserService는 즉시 Connection rollback()을 호출하고 트랜잭션을 종료할 수 있다. (이 때도 트랜잭션 저장소의 Connection 오브젝트 제거)
트랜잭션 동기화 저장소는 작업 스레드마다 독립적으로 Connection 오브젝트를 저장/관리한다.
- 멀티스레드 가능
트랜잭션 동기화 방식을 적용한 upgradeLevels()

...
    public void upgradeLevels() throws Exception {
        TransactionSynchronizationManager.initSynchronization();    // 트랜잭션 동기화 관리자를 이용해 동기화 작업 초기화
        Connection c = DataSourceUtils.getConnection(dataSource);   // 커넥션 생성, 동기화
        c.setAutoCommit(false); // 트랜잭션 시작
        try {
            ...
            c.commit(); // 정상적으로 작업을 마치면 커밋
        } catch (Exception e) {
            c.rollback(); // 예외 시 롤백
            throw e;
        } finally {
            DataSourceUtils.releaseConnection(c, dataSource);   // DB 커넥션 세이프 종료
            TransactionSynchronizationManager.unbindResource(dataSource);   // 동기화 작업 종료
            TransactionSynchronizationManager.clearSynchronization();   // 정리
        }
    }

한 개 이상의 DB로 작업을 하나의 트랜잭션으로 만들기 위해서는 로컬 트랜잭션 으로는 불가능하다.
- 별도의 트랜잭션 관리자를 통해 트랜잭션을 관리하는 글로벌 트랜잭션 방식을 사용해야 한다.
- 자바는 글로벌 트랜잭션을 지원하는 트랜잭션 매니저를 지원하기 위한 API 인 JTA(Java Transaction API) 를 제공한다.
- 11장에서 자세히
JTA를 이용한 트랜잭션 코드 구조

InitialContext ctx = new InitialContext();
UserTransaction tx = (UserTransaction)ctx.lookup(USER_TX_JNDI_NAME);
tx.begin();
Connection c = dataSource.getConnection();
try {
    ...
    tx.commit();
} catch (Exception e) {
    tx.rollback();
    throw e;
} finally {
    c.close();
}

또 문제는 하이버네이트를 이용한 트랜잭션 관리는 JDBC나 JTA의 코드와는 또 다르다.
- Connection 을 직접 사용하지 않고 Session 을 사용하며 독자적인 트랜잭션 관리 API를 사용한다.

트랜잭션 API의 의존관계 문제와 해결책

트랜잭션의 경계설정 필요가 생기면서 특정 데이터 액세스 기술에 종속되는 구조가 된다.
트랜잭션의 경계설정을 담당하는 코드는 일정한 패턴을 갖는 유사한 구조다.
- 이렇게 여러 기술의 사용방법에 공통점이 있다면 추상화 를 생각해볼 수 있다.
- 추상화 란 하위 시스템의 공통점을 뽑아내서 분리시키는 것을 말한다.
  - DB에서 제공하는 DB 클라이언트, 라이브러리, API는 서로 전혀 호환이 되지 않는 독자적인 방식으로 만들어져9 있다. 하지만 모두 SQL 을 이용하는 방식이라는 공통점이 있다.
  - 이 공통점을 추출하여 추상화 한 것이 JDBC
  - JDBC 라는 추상화 기술이 있기 때문에 자바는 DB의 종류와 상관없이 일관된 방법으로 데이터 액세스 코드를 작성할 수 있다.
스프링의 트랜잭션 추상화 API 를 적용

public void upgradeLevels() {
    PlatformTransactionManager transactionManager = new DataSourceTransactionManager(dataSource);
    TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());

    try {
        List<User> users = userDao.getAll();

        for (User user : users) {
            if (userLevelUpgradePolicy.canUpgradeLevel(user)) {
                userLevelUpgradePolicy.upgradeLevel(user);
            }
        }
        transactionManager.commit(status);
    } catch (RuntimeException e) {
        transactionManager.rollback(status);
        throw e;
    }
}

트랜잭션 경계설정을 위한 추상 인터페이스 PlatformTransactionManager
- JDBC의 로컬 트랜잭션을 이용한다면 구현체 DataSourceTransactionManager 사용
- 필요에 따라 트랜잭션 매니저가 커넥션을 가져오는 작업도 함께 수행한다.
- 트랜잭션을 가져올 때 transactionManager.getTransaction(new DefaultTransactionDefinition()); 일단은 트랜잭션을 시작한다는 의미라고 이해하면 된다고 한다.
- 이렇게 시작된 트랜잭션은 TransactionStatus status 변수에 저장된다.
JTA를 이용한 글로벌 트랜잭션으로 변경하려면 구현체를 JTATransactionManager 로 변경하기만 하면 된다.
- 하이버네이트를 사용했다면 HibernateTransactionManager, JPA를 사용했다면 JPATransactionManager
- 구현체가 여러가지이고, 그걸 service 에서 직접 구현하는 걸 보니 DI 하고싶다!
  - 스프링의 빈으로 등록할 때 먼저 검토해야 할 것은 싱글톤으로 멀티스레드에 사용해도 괜찮은가 이다.
  - 스프링에서 제공하는 모든 PlatformTransactionManager 의 구현체는 싱글톤으로 사용이 가능하다.

5.3 서비스 추상화와 단일 책임 원칙

기술과 서비스에 추상화 기법을 이용하면 특정 기술환경에 종속되지 않는 포터블한 코드를 만들 수 있다.
UserDao와 UserService는 각각 담당하는 코드의 기능적인 관심에 따라 분리되고, 서로 불필요한 영향을 주지 않으면서 독자적으로 확장이 가능하도록 만든 것이다.
- 같은 애플리케이션 로직을 담은 코드지만, 내용에 따라 분리했다.
- 같은 계층에서 수평적인 분리라고 볼 수 있다.
트랜잭션의 추상화는 이와 조금 다르다.
- 애플리케이션의 비지니스 로직과 그 하위에서 동작하는 로우레벨의 트랜잭션 기술이라는 아예 다른 계층의 특성을 갖는 코드를 분리한 것이다.
애플리케이션 로직의 종류에 따른 수평적인 구분이든, 로직과 기술이라는 수직적인 구분이든 모두 결합도가 낮으며, 서로 영향을 주지 않고 자유롭게 확장할 수 있는 구조를 만들 수 있는데는 스프링의 DI가 중요한 역할을 하고 있다.
- DI의 가치는 이렇게 관심, 책임, 성격이 다른 코드를 깔끔하게 분리하는 데 있다.

단일 책임 원칙

이러한 적절한 분리가 가져오는 특징은 객체지향 설계의 원칙 중의 하나인 단일 책임 원칙(SRP) 으로 설명할 수 있다.
- 모듈은 한 가지 책임을 가져야 한다.
- 모듈이 변경되는 이유는 한 가지다.
UserService 에 JDBC Connection의 메소드를 직접 사용하는 트랜잭션 코드가 들어있었을 때
- 사용자 레벨을 어떻게 관리할 것인가
- 트랜잭션을 어떻게 관리할 것인가
- 이렇게 두 가지 책임을 가지고 있었다.
  - 사용자 레벨 관리 방식의 변경이 없어도, 트랜잭션 기술을 변경해야 한다면 해당 클래스가 변경되어야 한다. 즉, 변경의 이유가 두 가지
단일 책임 원칙의 장점
- 어떤 변경이 필요할 때 수정 대상이 명확해진다.
- 기술이 바뀌면, 기술계층과의 연동을 담당하는 기술 추상화 계층의 설정만 바꿔주면 된다.
객체지향 설계와 프로그래밍의 원칙은 서로 긴밀하게 연결되어 있다.
- 단일 책임 원칙을 잘 지키는 코드를 만들려면 interface를 도입하고 이를 DI로 연결해야 하며, 그 결과로 단일 책임 원칙 뿐 아니라 개방폐쇄 원칙도 잘 지키고, 모듈 간 결합도가 낮아 서로의 변경이 영향을 주지 않고, 같은 이유로 변경이 단일 책임에 집중되는 응집도 높은 코드가 나온다.

5.4. 메일 서비스 추상화

Spring 이 직접 제공하는 MailSender 를 구현한 추상화 클래스는 JavaMailServiceImple 하나뿐이다.
- 그럼에도 불구하고 이 추상화된 메일 전송 기능을 사용해 애플리케이션을 작성함으로써 얻을 수 있는 장점은 크다.
  - 테스트 시 실제 메일이 발송되지 않게
  - JavaMail 이 아닌 다른 메시징 서버의 API 를 이용
  - 메일을 바로 전송하지 않고 큐에 담아뒀다가 정해진 시간에 발송
  - 다양한 추가/변경 작업 시 MailSender로 추상화된 메일 전송 추상화 계층이 도움이된다.
기술이나 환경이 바뀔 가능성이 있음에도, JavaMail 처럼 확장이 불가능하게 설계해놓은 API를 사용해야 하는 경우라면 추상화 계층의 도입을 적극 고려해볼 필요가 있다.
- 외부 리소스와 연동하는 대부분 작업은 추상화 대상이 될 수 있다.
테스트용으로 사용되는 특별한 오브젝트들이 있다.
- 대부분 테스트 대상인 오브젝트의 의존 오브젝트가 되는 것들
- 테스트환경을 만들어주기 위해, 테스트 대상이 되는 오브젝트의 기능에만 충실하게 수행하면서 빠르게, 자주 테스트를 실행할 수 있도록 사용하는 이런 오브젝트들을 통틀어서 테스트 대역(test double) 이라고 부른다.
- 대표적인 테스트 대역은 테스트 스텁(test stub) 이다.
  - 테스트 스텁은 테스트 대상 오브젝트의 의존객체로서 존재하면서 테스트 동안에 코드가 정상적으로 수행할 수 있도록 돕는 것을 말한다.
  - 간접적인 입력값을 제공
- Mock Object
  - 테스트 대상 오브젝트와 의존 오브젝트 사이에서 일어나는 일을 검증할 수 있도록 특별히 설계
  - 테스트 오브젝트와 자신의 사이에서 일어나는 커뮤니케이션을 저장해뒀다가 테스트 결과를 검증하는 데 활용할 수 있게 해준다.
  - 간접적인 출력 값까지 확인이 가능

6장 AOP

6.1 트랜잭션 코드의 분리

6.1.1 메소드 분리

UserService 의 트랜잭션 경계설정 코드와 비즈니스 로직 코드가 복잡하게 얽혀 있는 듯 보이지만, 뚜렷하게 두 가지 종류의 코드가 구분되어 있다.
비즈니스 로직 코드를 사이에 두고 트랜잭션의 시작과 종료를 담당
트랜잭션 경계설정 코드와 비즈니스 로직 코드 간에 서로 주고받는 정보가 없이 독립적이다.
비즈니스 로직만 추출한 예

public void upgradeLevels() {
    TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());

    try {
        upgradeLevelsInternal();    // here!!
        transactionManager.commit(status);
    } catch (RuntimeException e) {
        transactionManager.rollback(status);
        throw e;
    }
}

private void upgradeLevelsInternal() {
    List<User> users = userDao.getAll();

    for (User user : users) {
        if (userLevelUpgradePolicy.canUpgradeLevel(user)) {
            userLevelUpgradePolicy.upgradeLevel(user);
        }
    }
}

6.1.2 DI를 이용한 클래스 분리

여전히 트랜잭션을 담당하는 기술적 코드가 UserService 클래스에 있다.
여태 DI를 적용했던 이유는 일반적으로 구현 클래스를 바꿔가면서 사용하기 위해서
- 테스트에 따라 테스트 구현클래스 등
- 하지만 꼭 이것 때문에 DI를 쓰는건 아님
UserService 의 책임을 나눈 구현 클래스를 두 개 만든다.
UserService interface

public interface UserService {
    void add(User user);
    void upgradeLevels();
}

비즈니스 로직만 들고 있는 UserServiceImpl

public class UserServiceImpl implements UserService {

    ...

    @Override
    public void upgradeLevels() {
        List<User> users = userDao.getAll();

        for (User user : users) {
            if (userLevelUpgradePolicy.canUpgradeLevel(user)) {
                userLevelUpgradePolicy.upgradeLevel(user);
            }
        }
    }

    @Override
    public void add(User user) {
        if (user.getLevel() == null) {
            user.setLevel(Level.BASIC);
        }

        userDao.add(user);
    }

    ...
}

트랜잭션 경계설정 + 작업 위임하는 UserServiceTx

public class UserServiceTx implements UserService {

    private UserService userService;

    ...

    @Override
    public void upgradeLevels() {
        TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());
        try {
            userService.upgradeLevels();
            transactionManager.commit(status);
        } catch (RuntimeException e) {
            transactionManager.rollback(status);
            throw e;
        }
    }

    ...
}

장점
- 비즈니스 로직을 담당하고 있는 UserServiceImpl 의 코드를 작성할 때는 트랜잭션과 같은 기술적인 내용에는 전혀 신경쓰지 않아도 된다.
- 비즈니스 로직에 대한 테스트를 손쉽게 만들어낼 수 있다.

6.2. 고립된 단위 테스트

가장 편하고 좋은 테스트 방법은 가능한 한 작은 단위로 쪼개서 테스트 하는 것.
- 좋은 이유는, 테스트가 실패했을 때 그 원인을 찾기 쉽기 때문
- 의도나 내용이 분명, 만들기도 쉬워짐
asis upgradeLevels() 테스트
- 1. 테스트용 정보를 DB에 넣는다.
  2. 메일 발송 여부를 확인하기 위해 MailSender Mock Object 를 DI
  3. 실제 테스트 대상인 userService 메소드 실행
  4. DB에서 데이터를 가져와 결과 확인
  5. Mock 오브젝트에서 데이터를 가져와 UserService 에 의한 메일 발송이 있었는지 확인
mock userDao

static class MockUserDao implements UserDao {
    private List<User> users;

    private List<User> updated = new ArrayList<>();

    private MockUserDao(List<User> users) {
        this.users = users;
    }

    public List<User> getUpdated() {
        return this.updated;
    }

    public List<User> getAll() {
        return this.users;
    }

    public void update(User user) {
        updated.add(user);
    }

    public void add(User user) { throw new UnsupportedOperationException(); };
    public void deleteAll() { throw new UnsupportedOperationException(); };
    public User get(String id) { throw new UnsupportedOperationException(); };
    public int getCount() { throw new UnsupportedOperationException(); };
}

upgradeLevels test use mock userDao

public void upgradeLevels() {
    UserServiceImpl userServiceImpl = new UserServiceImpl(new MockUserDao(this.users));

    ...

    userServiceImpl.upgradeLevels();

    List<User> updated = mockUserDao.getUpdated();
    assertEquals(updated.size(), 2);
    assertEquals(updated.get(0).getLevel(), Level.SILVER);
    assertEquals(updated.get(1).getLevel(), Level.GOLD);

    ...
}

테스트 대역 오브젝트를 이용해 완전히 고립된 테스트를 만듬
- 스프링 컨테이너에서 빈을 가져올 필요가 없다.
- 테스트 수행 성능이 향상된다.
  - 테스트가 빨리 돌아가면 부담 없이 자주 테스트를 돌려볼 수 있다.
- 의존 대상 영향을 고려하지 않아도 된다.
고립된 테스트를 만들려면 목 오브젝트 작성과 같은 약간의 수고가 더 필요할지 모르나, 그 보상은 충분히 기대할 만하다.

Mockito 프레임워크

mock 생성

UserDao mockUserDao = mock(UserDao.class);

메소드 리턴값 정의

when(mockUserDao.getAll()).thenReturn(this.users);

메소드 호출 횟수 확인

verify(mockUserDao, times(2)).update(any(User.class));

메소드 파라미터 캡쳐

ArgumentCaptor<SimpleMailMessage> mailMessageArg = ArgumentCaptor.forClass(SimpleMailMessage.class);
verify(mockMailSender, times(2)).send(mailMessageArg.capture())
List<SimpleMailMessage> mailMessages = mailMessageArg.getAllValues();

// assert

6.3 다이내믹 프록시와 팩토리 빈

트랜잭션이라는 부가기능을 UserServiceTx, 핵심기능을 UserServiceImpl 로 분리했다.
중요한 특징이 있다.
- 부가기능 외에 나머지 모든 기능은 원래 핵심 기능을 가진 클래스로 위임.
- 즉, 부가기능이 핵심기능을 사용하는 구조가 된다.
- 클라이언트가 핵심기능을 가진 클래스를 직접 사용해버리면 부가기능 적용 기회가 없다.
- 그래서 부가기능은 마치 자신이 핵심기능을 가진 클래스인 것처럼 꾸며서, 클라이언트가 자신을 사용하도록 만들어야 한다.
이렇게 마치 자신이 클라이언트가 사용하려고 하는 실제 대상인 것 처럼 위장해서 클라이언트의 요청을 받아주는 것을 프록시(proxy) 라 부른다.
- 그리고 프록시를 통해 최종적으로 요청을 위임받아 처리하는 실제 오브젝트를 타깃(target), 실체(real object) 라 부른다.
프록시의 특징은 타깃과 같은 인터페이스를 구현했다는 것과, 프록시가 타깃을 제어할 수 있는 위치에 있다는 것.
프록시의 사용 목적
- 클라이언트가 타깃에 접근하는 방법을 제어
- 타깃에 부가적인 기능을 부여하기 위해

데코레이터 패턴

타깃에 부가적인 기능을 런타임 시 다이내믹하게 부여해주기 위해 프록시를 사용하는 패턴
- 다이내믹하게 <- 의 의미는 컴파일 시점(코드 상) 에는 어떤 방법과 순서로 프록시와 타깃이 연결되어 사용되는지 정해져 있지 않다는 뜻
실제 내용물은 동일하지만 부가적인 효과를 부여
프록시가 꼭 한개로 제한되지는 않는다.
예를들어 소스코드를 출력하는 기능을 가진 핵심 기능
- 데코레이터 개념을 부여, 타깃과 같은 인터페이스를 구현, 런타임 시 이를 적절한 순서로 조합해서 사용
  - 소스코드에 라인넘버를 붙여주는 데코레이터 -> 신텍스 하이리팅 하는 데코레이터 -> 페이징 데코레이터 -> 핵심 기능 (타깃)
데코레이터의 다음 위임 대상은 인터페이스로 주입 받아야 한다.
- 다음 대상이 최종 타깃인지, 다음단계 데코레이터 프록시인지 알지 못하기 때문
데코레이터 패턴은 타깃의 코드를 손대지 않고, 클라이언트가 호출하는 방법도 변경하지 않은 채로 새로운 기능을 추가할 때 유용한 방법이다.

프록시 패턴

프록시라는 용어와 디자인 패턴의 프록시 패턴은 다르다.
프록시 패턴은 타깃에 대한 접근방법을 제어하려는 목적을 가진 경우를 가리킨다.
- 타깃의 기능을 확장하거나 추가하지 않는다.
- 대신 클라이언트가 타깃에 접근하는 방식을 변경해준다.
타깃 오브젝트를 생성하기가 복잡하거나 당장 필요하지 않으나 오브젝트의 레퍼런스가 미리 필요한 경우, 실제 타깃 오브젝트 대신 프록시를 넘겨주는 것.
- 프록시의 메소드를 통해 타깃을 사용하려고 시도하면, 그때 프록시가 타깃 오브젝트를 생성하고 요청을 위임해주는 식
레퍼런스를 갖고 있지만 끝까지 사용하지 않거나, 많은 작업이 진행된 후에 사용되는 경우라면 생성을 최대한 늦춤으로써 얻는 장점이 많다.
원격 오브젝트를 이용하는 경우에도 프록시를 사용하면 편리하다.
- 다른 서버에 존재하는 원격 오브젝트에 대한 프록시를 만들어두고, 클라이언트는 마치 로컬에 존재하는 오브젝트를 쓰는 것처럼
타깃에 대한 접근권한을 제어하기 위해 프록시 패턴 사용
- 특정 레이어에서 읽기전용으로 동작하는 경우
이렇게 프록시 패턴은 타깃의 기능 자체에는 관여하지 않으면서 접근하는 방법을 제어해주는 프록시를 이용하는 것이다.
타깃과 동일한 인터페이스를 구현하고 클라이언트와 타깃 사이에 존재하면서 부가 기능 또는 접근 제어를 담당하는 오브젝트는 모두 프록시

6.3.2 다이내믹 프록시

프록시는 다음 두 가지 기능으로 구성된다.
- 타깃과 같은 메소드를 구현하고 있다가 메소드가 호출되면 타깃 오브젝트로 위임.
- 지정된 요청에 대해서는 부가기능 수행.
프록시가 만들기 번거로운 이유
1. 타깃의 인터페이스를 구현하고 위임하는 코드 작성이 번거롭다.
  - 부가기능이 필요없는 메소드도 구현, 위임 필요
2. 부가기능 코드의 중복 가능성
목 오브젝트와 비슷하게 프록시를 손쉽게 만드는 것을 도와주는 API 가 존재한다
- JDK 의 다이내믹 프록시

다이내믹 프록시는 리플렉션 기능을 이용해서 프록시를 만들어준다.

리플렉션은 자바의 코드 자체를 추상화해서 접근하도록 만든 것.
학습 테스트

  @Test
  public void invokeMethod() throws Exception {
      String name = "Spring";

      assertEquals(name.length(), 6);

      Method lengthMethod = String.class.getMethod("length");
      assertEquals((Integer)lengthMethod.invoke(name), 6);

      assertEquals(name.charAt(0), 'S');

      Method charAtMethod = String.class.getMethod("charAt", int.class);
      assertEquals((Character)charAtMethod.invoke(name, 0), 'S');
  }

invoke() 메소드는 메소드를 실행시킬 대상 오브젝트와 파라미터 목록을 받아 메소드를 호출한 뒤 그 결과를 Object 타입으로 돌려준다.

다이내믹 프록시 학습테스트 예제

Hello Interface

  public interface Hello {

      String sayHello(String name);

      String sayHi(String name);

      String sayThankYou(String name);
  }

타깃 클래스

  public class HelloTarget implements Hello {
      @Override
      public String sayHello(String name) {
          return "Hello " + name;
      }

      @Override
      public String sayHi(String name) {
          return "Hi " + name;
      }

      @Override
      public String sayThankYou(String name) {
          return "Thank You " + name;
      }
  }

프록시

  public class UppercaseHandler implements InvocationHandler {

      Object target;

      public UppercaseHandler(Object target) {
          this.target = target;
      }

      @Override
      public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
          Object ret = method.invoke(target, args);
          if (ret instanceof  String && method.getName().startsWith("say")) {
              return ((String)ret).toUpperCase();
          } else {
              return ret;
          }
      }
  }

클라이언트 (학습테스트)

  @Test
  public void simpleProxy() {
      Hello hello = new HelloTarget();
      assertEquals(hello.sayHello("Toby"), "Hello Toby");
      assertEquals(hello.sayHi("Toby"), "Hi Toby");
      assertEquals(hello.sayThankYou("Toby"), "Thank You Toby");

      Hello proxiedHello = (Hello) Proxy.newProxyInstance(getClass().getClassLoader(), new Class[] {
              Hello.class
      }, new UppercaseHandler(new HelloTarget()));

      assertEquals(proxiedHello.sayHello("Toby"), "HELLO TOBY");
      assertEquals(proxiedHello.sayHi("Toby"), "HI TOBY");
      assertEquals(proxiedHello.sayThankYou("Toby"), "THANK YOU TOBY");
  }

6.3.3 다이내믹 프록시를 이용한 트랜잭션 부가기능

UserServiceTx 를 다이내믹 프록시 방식으로 변경해보자.

@Test
@DirtiesContext
public void upgradeAllOrNothing() {
    UserService target = new UserServiceImpl(userDao, new UserLevelUpgradePolicyTest(userDao, users.get(3).getId()));
    TransactionHandler txHandler = new TransactionHandler(target, new DataSourceTransactionManager(dataSource), "upgradeLevels");
    UserService txUserService = (UserService) Proxy.newProxyInstance(getClass().getClassLoader()
            , new Class[] {UserService.class}, txHandler);

    userDao.deleteAll();

    for (User user : users) {
        userDao.add(user);
    }
    Assertions.assertThrows(TestUserServiceException.class, txUserService::upgradeLevels);

    checkLevelUpgraded(users.get(1), false);
}

6.3.4 다이내믹 프록시를 위한 팩토리 빈

사전에 프록시 오브젝트의 클래스 정보를 미리 알아내서 스프링 빈에 정의할 방법이 없다.
다이내믹 프록시는 Proxy 클래스의 newProxyInstance() 라는 스태틱 팩토리 메소드를 통해서만 만들 수 있다.

팩토리 빈

스프링을 대신해서 오브젝트의 생성로직을 담당하도록 만들어진 특별한 빈
팩토리 빈을 만드는 여러 방법 중 스프링의 FactoryBean 인터페이스를 구현할 수도 있다.

FactoryBaen 인터페이스

  public interface FactoryBean<T> {

      String OBJECT_TYPE_ATTRIBUTE = "factoryBeanObjectType";

      @Nullable
      T getObject() throws Exception; // 빈 오브젝트 생성, return

      @Nullable
      Class<?> getObjectType();   //  생성되는 오브젝트 타입

      default boolean isSingleton() {  // getObject()가 항상 같은 오브젝트를 리턴하는가
          return true;
      }
  }

학습 테스트

private 생성자 클래스

  public class Message {

      private String text;

      private Message(String text) {
          this.text = text;
      }

      public String getText() {
          return text;
      }

      public static Message newMessage(String text) {
          return new Message(text);
      }
  }

사실 스프링은 private 생성자를 가진 클래스도 빈으로 등록하면 리플렉션을 사용해 오브젝트를 만들 수 있다.
하지만 private 로 선언되었다는 것은 스테틱 메소드를 통해 오브젝트가 만들어져야 하는 중요한 이유가 있을 수 있으므로 이를 무시하고 강제로 오브젝트 생성하는 것은 위험하다.
Message 클래스의 오브젝트를 생성해주는 팩토리 빈 클래스

  public class MessageFactoryBean implements FactoryBean<Message> {

      private String text;

      public MessageFactoryBean(String text) {
          this.text = text;
      }

      @Override
      public Message getObject() throws Exception {
          return Message.newMessage(this.text);
      }

      @Override
      public Class<?> getObjectType() {
          return Message.class;
      }

      @Override
      public boolean isSingleton() {
          return false;
      }
  }

다이내믹 프록시를 만들어주는 팩토리 빈

public class TxProxyFactoryBean implements FactoryBean<Object> {

    private Object target;
    private PlatformTransactionManager transactionManager;
    private String pattern;
    Class<?> serviceInterface;

    @Override
    public boolean isSingleton() {
        return false;
    }

    public TxProxyFactoryBean(Object target, PlatformTransactionManager transactionManager, String pattern, Class<?> serviceInterface) {
        this.target = target;
        this.transactionManager = transactionManager;
        this.pattern = pattern;
        this.serviceInterface = serviceInterface;
    }

    @Override
    public Object getObject() throws Exception {
        TransactionHandler txHandler = new TransactionHandler(this.target, this.transactionManager, this.pattern);
        return Proxy.newProxyInstance(
                getClass().getClassLoader(), new Class[] { serviceInterface }, txHandler
        );
    }

    @Override
    public Class<?> getObjectType() {
        return serviceInterface;
    }
}

예외 발생 시 트랜잭션 롤백됨을 확인하려면 테스트 코드에서 FactoryBean 을 DI 받아 TestUserService 오브젝트를 타깃 오브젝트로 Object를 생성하면 된다.

6.3.5 프록시 팩토리 빈 방식의 장점과 한계

장점
- 한 번 부가기능을 가진 프록시를 생성하는 팩토리 빈을 만들어두면 타깃의 타입에 상관없이 재사용할 수 있다.
  - TransactionHandler 를 이용하는 다이내믹 프록시를 생성해주는 TxProxytFactoryBean 은 코드의 수정 없이도 다양한 클래스에 적용할 수 있다. 타깃 오브젝트만 맞도록 변경하여 빈으로 등록해주면 된다.
- 다이내믹 프록시를 사용하면 타깃 인터페이스를 구현하는 클래스를 일일이 만드는 번거로움을 제거할 수 있다.
- 하나의 핸들러 메소드를 구현하는 것만으로도 수많은 메소드에 부가기능을 부여해줄 수 있으니 부가기능 코드 중복 문제도 해결된다.
- DI 덕분이다. DI 짱.
한계
- 한 번에 여러 개의 클래스에 공통적인 부가기능을 제공할 수 없다.
  - 타깃 오브젝트는 하나.
- 하나의 타깃에 여러 개의 부가기능을 적용하려고 할 때 문제다.
  - 프록시 팩토리 빈 설정(xml, 코드 등)이 부가기능의 개수만큼 늘어난다.
  - 설정파일이 복잡해진다.
  - TransactionHandler 가 프록시 팩토리 빈 개수만큼 만들어진다.

6.4 스프링의 프록시 팩토리 빈

스프링은 프록시 오브젝트를 생성해주는 기술을 추상화한 팩토리 빈을 제공한다.
스프링의 ProxyFactoryBean 은 프록시를 생성해서 빈 오브젝트로 등록하게 해주는 팩토리 빈이다. 기존에 만들었던 TxProxyFactoryBean과 달리, ProxyFactoryBean은 순수하게 프록시를 생성하는 작업만 담당하고, 프록시를 통해 제공해줄 부가기능은 별도의 빈에 둘 수 있다.
- 부가기능은 MethodInterceptor 인터페이스를 구현
  - InvocationHandler 와 비슷하지만, MethodInterceptor 의 invoke() 메소드는 ProxyFactoryBean 으로부터 타깃 오브젝트에 대한 정보까지 함께 제공받는다.
    - 덕분에 타깃 오브젝트에 상관없이 독립적으로 만들어질 수 있다.

@Test
public void proxyFactoryBean() {
    ProxyFactoryBean pfBean = new ProxyFactoryBean();
    pfBean.setTarget(new HelloTarget());
    pfBean.addAdvice(new UppercaseAdvice());

    Hello proxiedHello = (Hello) pfBean.getObject();
    assertEquals(proxiedHello.sayHello("Toby"), "HELLO TOBY");
    assertEquals(proxiedHello.sayHi("Toby"), "HI TOBY");
    assertEquals(proxiedHello.sayThankYou("Toby"), "THANK YOU TOBY");
}

static class UppercaseAdvice implements MethodInterceptor {

    @Override
    public Object invoke(MethodInvocation invocation) throws Throwable {
        String ret = (String)invocation.proceed();
        return ret.toUpperCase();
    }
}

어드바이스: 타깃이 필요없는 순수한 부가기능
- MethodInvocation 은 타깃오브젝트가 등장하지 않는다. 타깃오브젝트의 메소드를 실행할 수 있는 기능이 있기 때문에 부가기능 제공하는 데만 집중할 수 있다.
  - MethodInvocation 의 구현체는 일종의 공유 가능한 템플릿 처럼 동작한다. (템플릿/콜백 패턴)
- 어드바이스는 타깃 오브젝트에 적용되지만 종속되지 않는 순수한 부가기능을 담은 오브젝트
포인트컷: 부가기능 적용 대상 메소드 선정 방법
- TxProxyFactoryBean 에서는 pattern 이라는 String 으로 메소드를 선정했었다.
- MethodInterceptor 는 재사용 가능한 순수한 부가기능 제공 코드만 남기기 위해, 다이내믹프록시가 MethodInterceptor 를 호출하기 전 메소드 선정 알고리즘을 담은 오브젝트를 호출하는 구조를 제공한다. 이를 포인트컷이라고 한다.
- 프록시는 클라이언트로부터 요청을 받으면 먼저 포인트컷에게 부가기능을 부여할 메소드인지 확인 요청을 한다. 적용 대상 메소드라면 MethodInterceptor 타입의 어드바이스를 호출한다.
```
  @Test
  public void proxyFactoryBean() {
      ProxyFactoryBean pfBean = new ProxyFactoryBean();
      pfBean.setTarget(new HelloTarget());

      NameMatchMethodPointcut pointcut = new NameMatchMethodPointcut();
      pointcut.setMappedName("sayH*");

      pfBean.addAdvisor(new DefaultPointcutAdvisor(pointcut, new UppercaseAdvice()));

      Hello proxiedHello = (Hello) pfBean.getObject();
      assertEquals(proxiedHello.sayHello("Toby"), "HELLO TOBY");
      assertEquals(proxiedHello.sayHi("Toby"), "HI TOBY");
      assertEquals(proxiedHello.sayThankYou("Toby"), "Thank You Toby");
  }
```
- addAdvice() 메소드를 호출하지않고 Advisor 타입으로 addAdvisor() 메소드를 호출했다.
- 여러 개의 어드바이스와 포인트 컷이 추가 될 때, 어떤 어드바이스에 어떤 포인트컷을 적용할지 명확하게 하기 위해 이런 방식을 사용.
- 이렇게 어드바이스와 포인트컷을 묶은 오브젝트를 어드바이저 라 한다.
- 어드바이저 = 포인트컷(메소드 선정 알고리즘) + 어드바이스(부가기능)
TransactionAdvice

public class TransactionAdvice implements MethodInterceptor {

    private PlatformTransactionManager transactionManager;

    public TransactionAdvice(PlatformTransactionManager transactionManager) {
        this.transactionManager = transactionManager;
    }

    @Override
    public Object invoke(MethodInvocation invocation) throws Throwable {
        TransactionStatus status = this.transactionManager.getTransaction(new DefaultTransactionDefinition());

        try {
            Object ret = invocation.proceed();
            this.transactionManager.commit(status);
            return ret;
        } catch (RuntimeException e) {
            this.transactionManager.rollback(status);
            throw e;
        }
    }
}

Config

@Configuration
public class WebConfiguration {
    ...

    @Bean
    public ProxyFactoryBean proxyFactoryBean() {
        ProxyFactoryBean pfBean = new ProxyFactoryBean();
        pfBean.setTarget(this.userServiceImpl());

        NameMatchMethodPointcut pointcut = new NameMatchMethodPointcut();
        pointcut.setMappedName("upgrade*");

        pfBean.addAdvisor(new DefaultPointcutAdvisor(pointcut, new TransactionAdvice(new DataSourceTransactionManager(this.dataSource()))));
        return pfBean;
    }

    @Bean
    public UserService userService() {
        return (UserService) this.proxyFactoryBean().getObject();
    }

    ...
}

UserService 외에도 이미 만들어둔 TransactionAdvice 를 재사용할 수 있다.

6.5 스프링 AOP

중복도 제거하고 적절하게 잘 만들어 왔지만, 일정한 타깃 목록이 있을 때 ProxyFactoryBean 타입 빈 설정을 매번 추가해서 프록시를 만들어야 하는게 마음에 안든다.
빈 후처리기를 사용하면 이를 해결가능하다.
- DefaultAdvisorAutoProxyCreator 빈 후처리기를 등록하면, 스프링은 빈 오브젝트를 만들 때마다 후처리기에게 빈을 보낸다.
- DefaultAdvisorAutoProxyCreator 는 빈으로 등록된 모든 어드바이저 내의 포인트컷을 이용해 전달받은 빈이 프록시 적용대상인지 확인한다.
  - 포인트컷은 두 가지 기능이 있다.
    - MethodMatcher : 어드바이스를 적용할 메소드인지 확인
    - ClassFilter : 프록시를 적용할 클래스인지 확인
포인트컷 테스트

public class DynamicProxyTest {

    @Test
    public void classNamePointcutAdvisor() {
        NameMatchMethodPointcut classMethodPointcut = new NameMatchMethodPointcut() {
            public ClassFilter getClassFilter() {
                return new ClassFilter() {
                    @Override
                    public boolean matches(Class<?> clazz) {
                        return clazz.getSimpleName().startsWith("HelloT");
                    }
                };
            }
        };

        classMethodPointcut.setMappedName("sayH*");
        checkAdviced(new HelloTarget(), classMethodPointcut, true);

        class HelloWorld extends HelloTarget {};
        checkAdviced(new HelloWorld(), classMethodPointcut, false);

        class HelloToby extends HelloTarget {};
        checkAdviced(new HelloToby(), classMethodPointcut, true);
    }

    private void checkAdviced(Object target, Pointcut pointcut, boolean adviced) {
        ProxyFactoryBean pfBean = new ProxyFactoryBean();
        pfBean.setTarget(target);
        pfBean.addAdvisor(new DefaultPointcutAdvisor(pointcut, new UppercaseAdvice()));
        Hello proxiedHello = (Hello) pfBean.getObject();

        if (adviced) {
            assertEquals(proxiedHello.sayHello("Toby"), "HELLO TOBY");
            assertEquals(proxiedHello.sayHi("Toby"), "HI TOBY");
            assertEquals(proxiedHello.sayThankYou("Toby"), "Thank You Toby");
        } else {
            assertEquals(proxiedHello.sayHello("Toby"), "Hello Toby");
            assertEquals(proxiedHello.sayHi("Toby"), "Hi Toby");
            assertEquals(proxiedHello.sayThankYou("Toby"), "Thank You Toby");
        }
    }
}

DefaultAdvisorAutoProxyCreator 적용

public class NameMatchClassMethodPointcut extends NameMatchMethodPointcut {

    public void setMappedClassName(String mappedClassName) {
        this.setClassFilter(new SimpleClassFilter(mappedClassName));
    }

    static class SimpleClassFilter implements ClassFilter {
        private String mappedName;

        public SimpleClassFilter(String mappedName) {
            this.mappedName = mappedName;
        }

        @Override
        public boolean matches(Class<?> clazz) {
            return PatternMatchUtils.simpleMatch(mappedName, clazz.getSimpleName());
        }
    }
}

@Configuration
public class WebConfiguration {
    ...

    @Bean
    public DefaultAdvisorAutoProxyCreator defaultAdvisorAutoProxyCreator() {
        return new DefaultAdvisorAutoProxyCreator();
    }

    @Bean
    public Pointcut nameMatchClassMethodPointcut() {
        NameMatchClassMethodPointcut pointcut = new NameMatchClassMethodPointcut();
        pointcut.setMappedName("upgrade*");
        pointcut.setMappedClassName("*ServiceImpl");
        return pointcut;
    }

    @Bean
    public DefaultPointcutAdvisor testTransactionAdvisor() {
        return new DefaultPointcutAdvisor(this.nameMatchClassMethodPointcut(), new TransactionAdvice(new DataSourceTransactionManager(this.dataSource())));
    }

    ...
}

이렇게 하면 DefaultAdvisorAutoProxyCreator 친구가 Advisor 인터페이스를 구현한 것을 모두 찾아 생성되는 빈에 어드바이저의 포인트컷을 적용해보면서 프록시 적용 대상을 선정한다.
하지만 특정 상황에 exception 을 발생하는 테스트를 만들기가 어려워져서, TestUserService 를 구현했다.

public class TestUserLevelUpgradePolicy extends UserLevelUpgradePolicyDefault {

    private String id;

    public TestUserLevelUpgradePolicy(UserDao userDao) {
        super(userDao);
        this.id = "id4";
    }

    @Override
    public void upgradeLevel(User user) {
        if (user.getId().equals(this.id)) {
            throw new TestUserServiceException();
        }

        super.upgradeLevel(user);
    }
}

@Configuration
public class WebConfiguration {
    @Bean
    public UserService testUserService() {
        return new UserServiceImpl(this.userDao(), new TestUserLevelUpgradePolicy(this.userDao()));
    }
}

@SpringBootTest(classes = Application.class)
class UserServiceTest {

    ...

    @Autowired
    private UserService testUserService;
    
    ...

    @Test
    public void upgradeAllOrNothing() {
        for (User user : users) {
            userDao.add(user);
        }

        Assertions.assertThrows(TestUserServiceException.class, testUserService::upgradeLevels);
        checkLevelUpgraded(users.get(1), false);
    }
}

6.5.3 포인트컷 표현식을 이용한 포인트컷

포인트컷 지시자 중 가장 대표적으로 사용되는 것은 execution()

excution([접근제한자 패턴] 리턴값타입패턴 [클래스타입패턴.]메소드이름패턴 (파라미터타입패턴 | "..", ...)) [throws 예외 패턴])

  public class PointcutTest {

      @Test
      public void methodSignaturePointcut() throws SecurityException, NoSuchMethodException {
          AspectJExpressionPointcut pointcut = new AspectJExpressionPointcut();
          System.out.println(Target.class.getMethod("minus", int.class, int.class));
          pointcut.setExpression("execution(public int "
                  + "learningtest.pointcut.Target.minus(int,int) "
                  + "throws java.lang.RuntimeException)");

          assertTrue(pointcut.getClassFilter().matches(Target.class)
                  && pointcut.getMethodMatcher().matches(Target.class.getMethod("minus", int.class, int.class), null));

          assertFalse(pointcut.getMethodMatcher().matches(Target.class.getMethod("plus", int.class, int.class), null));

          assertFalse(pointcut.getClassFilter().matches(TestBean.class));

      }
  }

적용된 포인트컷 표현식은
- execution(public int learningtest.pointcut.Target.minus(int,int) throws java.lang.RuntimeException)
필수가 아닌 항목인 접근제어자, 클래스타입, 예외 패턴을 생략하면
- execution(int minus(int, int))
- 대신 생략한 부분은 모든 경우를 허용하도록 되어있기에 느슨한 포인트컷이 된다.
- 더 생략하면
  - execution(* minus(int, int))
    - minus 메소드 이름에 파라미터가 int int 인 애들
  - execution(* minus(..))
    - minus 메소드 이름인 애들
  - execution(* *(..))
    - 모든 메소드
    - 가장 느슨

execution() 외에도 몇 가지 표현식 스타일이 있다
- 대표적으로
  - bean()
  - @annotaion()
적용해보기

@Configuration
public class WebConfiguration {
    ...

    @Bean
    public Pointcut pointcut() {
        AspectJExpressionPointcut pointcut = new AspectJExpressionPointcut();
        pointcut.setExpression("execution(* *..*ServiceImpl.upgrade*(..))");
        return pointcut;
    }

    ...
}

포인트컷 표현식을 사용하면 코드와 설정이 모두 단순화되지만, 문자열로 표현되기에 런타임 시점까지 문법의 검증이나 기능 확인이 어렵다.
- 다양한 테스트를 활용하여 검증이 필요하다.
- Vol 2 에서 스프링 지원툴로 포인트컷이 선정한 빈을 확인할 수 있는 도구를 알려줄듯
포인트컷 클래스 타입 패턴은 상속 클래스/구현 인터페이스 모두 바라보고 선정한다.

6.5.4 AOP란 무엇인가?

애스펙트 지향 프로그래밍
- 관점 지향 프로그래밍
- aspect(애스펙트) 란 부가기능 모듈
  - 그 자체로 애플리케이션의 핵심기능을 담고 있지는 않지만, 중요한 한 가지 요소이며 핵심기능에 부가되어 의미를 갖는 특별한 모듈
- 부가기능을 정의한 어드바이스와 어드바이스를 어디에 적용할 지 결정하는 포인트컷을 함께 갖고 있다.
  - 어드바이저는 단순한 형태의 애스펙트

6.5.5. AOP 적용기술

프록시를 이용한 AOP
- 스프링 AOP 는 프록시 AOP 방식을 사용한다고 볼 수 있다.
바이트코드 생성과 조작을 통한 AOP
- 타겟 오브젝트를 뜯어고쳐서 부가기능을 직접 넣어준다.
- 컴파일된 타깃의 클래스 파일 자체를 수정하거나 JVM 로딩 시점을 가로채서 바이트코드를 조작한다.

6.5.6 AOP 용어

타깃
- 부가기능을 부여할 대상
어드바이스
- 부가기능을 담은 모듈
조인 포인트
- 어드바이스가 적용될 수 있는 위치
- 스프링 프록시 AOP 에서는 메소드 실행단계
포인트컷
- 어드바이스를 적용할 조인 포인트를 선별하는 작업 또는 그 기능을 정의한 모듈
프록시
- 클라이언트와 타깃 사이에 투명하게 존재하면서 부가기능을 제공하는 오브젝트
어드바이저
- 포인트컷과 어드바이스를 갖고 있는 오브젝트
- 스프링 AOP 에서만 사용되는 용어
애스펙트
- AOP의 기본 모듈
- 한 개 또는 그 이상의 포인트컷과 어드바이스의 조합

6.6 트랜잭션 속성

propagation, isolation level, timeout, readonly ..

트랜잭션 전파 (transaction propagation)

이미 진행 중인 트랜잭션이 있을 때 또는 없을 때 동작 결정 방식
PROPAGATION_REQUIRED
- 진행 중인 트랜잭션이 없으면 새로 시작하고, 이미 시작된 트랜잭션이 있으면 이에 참여한다.
- default
PROPAGATION_REQUIRES_NEW
- 항상 새로운 트랜잭션을 시작한다.
PROPAGATION_NOT_SUPPORTED
- 트랜잭션 없이 동작, 진행 중인 트랜잭션이 있어도 무시

격리 수준 (isolation level)

기본적으로 DB에 설정되어 있지만, JDBC 드라이버나 DataSource 등에서 재설정 할 수 있다.
- 필요하다면 트랜잭션 단위로도 가능
- Default 는 ISOLATION_DEFAULT
  - 이는 DataSource에 설정되어있는 디폴트 격리수준을 따른다.

6.6.3 포인트컷과 트랜잭션 속성의 적용 전략

트랜잭션 포인트컷 표현식은 타입 패턴이나 빈 이름을 이용한다.
공통된 메소드 이름 규칙을 통해 최소한의 트랜잭션 어드바이스와 속성을 정의한다.
프록시 방식 AOP 는 같은 타깃 오브젝트 내의 메소드 호출할 때는 적용되지 않는다.

6.7 애노테이션 트랜잭션 속성과 포인트컷

스프링은 @Transactional을 적용할 때 4단계의 대체(fallback) 정책을 이용한다.
- 메소드 속성을 확인할 때 타깃 메소드, 타깃 클래스, 선언 메소드, 선언 타입의 순서에 따라서 @Transactional이 적용됐는지 차례로 확인하고, 가장 먼저 발견되는 속성정보를 사용하게 하는 방법.
- 예를들어 가장 먼저 타깃의 메소드에 @Transactional이 있는지 확인하고, 있으면 이를 사용하고 없으면 다음 대체 후보인 타깃 클래스에 부여된 @Transaction 애노테이션을 찾는다.
  - 끝까지 발견되지 않으면 트랜잭션 적용대상이 아닌 것.

6.8 트랜잭션 지원 테스트

AOP를 이용해 코드 외부에서 트랜잭션의 기능을 부여해주고 속성을 지정할 수 있게 하는 방법을 선언적 트랜잭션 declarative transaction 이라고 한다.
반대로, TransactionTemplate 나 개별 데이터 기술의 트랜잭션 API를 사용해 직접 코드안에서 사용하는 방법은 프로그램에 의한 트랜잭션 programmatic transaction 이라고 한다.
특별한 경우가 아니라면 선언적 트랜잭션

6.8.2 트랜잭션 동기화와 테스트

@Test
public void transactionSync() {
    userService.deleteAll();

    userService.add(users.get(0));
    userService.add(users.get(1));
}

위와 같다면 3개의 트랜잭션이 만들어 졌을 것이다.
- 전파속성이 REQUIRED 이므로

@Test
public void transactionSync() {

    DefaultTransactionDefinition defaultTransactionDefinition = new DefaultTransactionDefinition();
    TransactionStatus txStatus = transactionManager.getTransaction(defaultTransactionDefinition);

    userService.deleteAll();
    userService.add(users.get(0));
    userService.add(users.get(1));

    transactionManager.commit(txStatus);
}

세 개의 메소드 속성이 REQUIRED 므로 미리 시작된 트랜잭션이 있다면 하나의 트랜잭션에서 수행될 것이다.
트랜잭션 동기화/롤백 검증 테스트

@Test
public void transactionSync() {
    userDao.deleteAll();
    assertEquals(userDao.getCount(), 0);

    DefaultTransactionDefinition defaultTransactionDefinition = new DefaultTransactionDefinition();
    TransactionStatus txStatus = transactionManager.getTransaction(defaultTransactionDefinition);

    userService.deleteAll();
    userService.add(users.get(0));
    userService.add(users.get(1));

    assertEquals(userDao.getCount(), 2);

    transactionManager.rollback(txStatus);

    assertEquals(userDao.getCount(), 0);
}

롤백테스트는 DB 작업이 포함된 테스트가 수행돼도 DB에 영향을 주지 않기 때문에 장점이 많다.
테스트코드의 @Transactional 은 디폴트 속성이 동일하나, 테스트가 끝나면 자동으로 롤백된다.
- 강제롤백을 원하지 않을 경우 @Rollback 이라는 어노테이션을 사용해야 한다.
  - 롤백 여부를 지정 가능. @Rollback(false)
@TransactionalConfiguration 을 사용하면 롤백에 대한 공통 속성을 지정할 수 있다.
- 클래스레벨에서 디폴트 롤백 속성을 false 로 해두고, 테스트 메소드 중 일부 롤백을 적용하고 싶을 때 @Rollback 을 부여해줘도 된다.
@NotTransactional 을 테스트 메소드에 부여하면 클래스 레벨의 @Transactional 설정이 있어도 트랜잭션을 시작하지 않는다.
- deprecated 되어서 이제는 전파속성을 사용한다.
- @Transaction(propagation=Propagation.NEVER)
테스트 내에서 트랜잭션을 제어할 수 있는 애노테이션을 잘 활용하면 DB가 사용되는 통합테스트를 만들 때 매우 편리하다.

7장 스프링 핵심 기술의 응용

현재는 SQL 변경이 필요할 경우 DAO 코드가 수정되어야 한다.
SQL을 적절히 분리해 DAO 코드와 다른 파일이나 위치에 두고 관리할 수 있다면 더 좋을 것 같다.
스프링 설정파일을 이용한 분리도 가능하나, SQL과 DI가 섞이게 된다.
SQL 서비스를 만들어보자.
SqlService 의 책임은 2가지
- SQL 정보를 외부의 리소스로부터 읽어오는 것
- 읽어온 SQL 을 보관하고 있다가 필요할 때 제공해 주는 것
부가적인 기능으로 SQL을 필요에 따라 수정할 수 있는 기능
SqlService interface

public interface SqlService {
    String getSql(String key) throws SqlRetrievalFailureException;
}

SqlReader interface

public interface SqlReader {
    void read(SqlRegistry sqlRegistry);
}

SqlRegistry interface

public interface SqlRegistry {

    void registerSql(String key, String sql);

    String findSql(String key) throws SqlRetrievalFailureException;
}

OXM : ObjectXMLMapping
- XML과 자바오브젝트를 맵핑하여 상호변환해주는 기술

7.4 인터페이스 상속을 통한 안전한 기능확장

DI란 미래를 프로그래밍 하는 것

7.4.2 인터페이스 상속

SqlRegistry interface

public interface SqlRegistry {

    void registerSql(String key, String sql);

    String findSql(String key) throws SqlRetrievalFailureException;
}

UpdatableSqlRegistry interface

public interface UpdatableSqlRegistry extends SqlRegistry {

    void updateSql(String key, String sql) throws SqlUpdateFailureException;

    void updateSql(Map<String ,String> sqlMap) throws SqlUpdateFailureException;
}

SQL 업데이트 기능을 가진 새로운 인터페이스를 만들었을 때 기존에 SqlRegistry 를 사용하던 BaseSqlService 도 새로운 UpdatableSqlRegistry 인터페이스를 이용해야 할까?
- 그렇지 않다.
새로운 SQL 업데이트 기능까지 구현한 SQL 레지스트리 클래스를 MyUpdatableSqlRegistry 라고 할 때, 동일한 오브젝트를 DI 받지만 설계와 코드에서는 각각 필요한 인터페이스에 의존하고 있으면 된다.

7.5 DI를 이용해 다양한 구현 방법 적용하기

ConcurrentHashMap
- HashMap 은 스레드 세이프 하지 않다.
- ConcurrentHashMap 은 안전하면서도 성능이 보장되는 동기화된 HashMap
Test Class

class ConcurrentHashMapSqlRegistryTest {

    UpdatableSqlRegistry sqlRegistry;

    @BeforeEach
    public void setUp() {
        sqlRegistry = new ConcurrentHashMapSqlRegistry();
        sqlRegistry.registerSql("KEY1", "SQL1");
        sqlRegistry.registerSql("KEY2", "SQL2");
        sqlRegistry.registerSql("KEY3", "SQL3");
    }

    @Test
    public void find() {
        checkFindResult("SQL1", "SQL2", "SQL3");
    }

    private void checkFindResult(String expected1, String expected2, String expected3) {
        assertEquals(sqlRegistry.findSql("KEY1"), expected1);
        assertEquals(sqlRegistry.findSql("KEY2"), expected2);
        assertEquals(sqlRegistry.findSql("KEY3"), expected3);
    }

    @Test
    public void unknownKey() {
        Assertions.assertThrows(SqlRetrievalFailureException.class,
                () -> sqlRegistry.findSql("SQL9999!@#$"));
    }

    @Test
    public void updateSingle() {
        sqlRegistry.updateSql("KEY2", "Modified2");
        checkFindResult("SQL1", "Modified2", "SQL3");
    }

    @Test
    public void updateMulti() {
        Map<String, String> sqlmap = new HashMap<>();
        sqlmap.put("KEY1", "Modified1");
        sqlmap.put("KEY3", "Modified3");

        sqlRegistry.updateSql(sqlmap);
        checkFindResult("Modified1", "SQL2", "Modified3");
    }

    @Test
    public void updateWithNotExistingKey() {
        Assertions.assertThrows(SqlUpdateFailureException.class,
                () -> sqlRegistry.updateSql("SQL9999!@#$", "Modified"));
    }
}

interface 구현 클래스

public class ConcurrentHashMapSqlRegistry implements UpdatableSqlRegistry {

    private Map<String, String> sqlMap = new ConcurrentHashMap<>();

    @Override
    public void updateSql(String key, String sql) throws SqlUpdateFailureException {
        if (sqlMap.containsKey(key)) {
            sqlMap.put(key, sql);
            return;
        }

        throw new SqlUpdateFailureException(key + "is empty");
    }

    @Override
    public void updateSql(Map<String, String> sqlMap) throws SqlUpdateFailureException {
        for (Map.Entry<String, String> entry : sqlMap.entrySet()) {
            updateSql(entry.getKey(), entry.getValue());
        }
    }

    @Override
    public void registerSql(String key, String sql) {
        sqlMap.put(key, sql);
    }

    @Override
    public String findSql(String key) throws SqlRetrievalFailureException {
        if (sqlMap.containsKey(key)) {
            return sqlMap.get(key);
        }

        throw new SqlRetrievalFailureException(key + "is empty");
    }
}

컨테이너의 빈 등록 정보 확인

@Autowired DefaultListableBeanFactory bf;

@Test
public void beans() {
    for (String n : bf.getBeanDefinitionNames()) {
        System.out.println(n + " \t " + bf.getBean(n).getClass().getName());
    }
}

8장 스프링이란 무엇인가?

8.1 스프링의 정의

자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크
애플리케이션 프레임워크
- 일반적으로 라이브러리나 프레임워크는 특정 업무 분야나 한 가지 기술에 특화된 목표를 가지고 만들어진다.
- 스프링은 애플리케이션 프레임워크 라는 특징을 갖고 있고, 이는 특정 계층/기술/업무분야에 국한되지 않고 애플리케이션의 전 영역을 포괄하는 범용적인 프레임워크를 말한다.
경량급
- 스프링은 20여 개의 모듈로 세분화되고 수십만 라인에 달하는 코드를 가진 매우 복잡하고 방대한 규모의 프레임워크이다.
- 그럼에도 스프링이 가볍다고 하는 이유는, 불필요하게 무겁지 않기 때문 (<-> EJB)
자바 엔터프라이즈 개발을 편하게
- 단순히 편리한 몇가지 도구나 기능을 제공하는 차원이 아니라, 근본적인 문제점에 도전해서 해결책을 제시한다는 것이 스프링의 특장점.
- 편리한 애플리케이션 개발이란 개발자가 복잡하고 실수하기 쉬운 로우레벨 기술에 많은 신경을 쓰지 않으면서도 애플리케이션의 핵심인 사용자의 요구사항, 즉 비즈니스 로직을 빠르고 효과적으로 구현하는 것을 말한다.
오픈소스
- 소스가 모두에게 공개되고, 특별한 라이선스를 취득할 필요가 없이 얼마든지 가져다 자유롭게 이용해도 된다는 뜻
- 아파치 라이선스 버전 2.0
  - 상업적인 목적의 제품에 포함시키거나 비공개 프로젝트에 자유롭게 이용가능
  - 스프링을 사용한다는 점과 원 저작자를 밝히고, 제품을 패키징 할 때 라이선스 정보를 포함시키는 등 기본적인 의무사항을 따르면 된다.
- 오픈소스의 장점
  - 개방된 커뮤니티 공간 안에서 투명한 방식으로 다양한 참여를 통해 개발되기 때문에 매우 빠르고 유연한 개발이 가능하다는 것.
  - 잠재적인 버그와 문제점이 빠르게 발견되고 해결될 수 있다.
  - 기업/사용자 입장에서 라이선스 비용에 대한 부담이 없다.
- 오픈소스의 단점
  - 지속적이고 안정적인 개발이 계속될지 불확실하다.
  - 스프링은 이런 오픈소스의 문제점과 한계를 잘 알기에, 개발을 책임지고 진행할 수 있는 전문기업을 만들었다.

8.2 스프링의 목적

엔터프라이즈 애플리케이션 개발을 편하게!

8.2.1 엔터프라이즈 개발의 복잡함

엔터프라이즈 시스템이란 서버에서 동작하며 기업과 조직의 업무를 처리해주는 시스템
첫번째는 기술적인 제약조건과 요구사항이 늘어가기 때문
- 엔터프라이즈 시스템을 개발하는 데는 순수한 비즈니스 로직을 구현하는 것 외에도 기술적으로 고려할 사항이 많다. (성능, 보안, 안정성, 확장성)
- 타 시스템 연계, 분산 트랜잭션 등 기술적인 요구는 점차 심화되고 그에 따른 복잡도는 증가하여 개발자 개개인이 져야 할 기술적인 부담은 점점 더 커진다.
두번째는 엔터프라이즈 애플리케이션이 구현해야 할 핵심기능인 비즈니스 로직의 복잡함이 증가하기 때문
또, 업무 프로세스를 변경하고 조종하는 것을 상시화할 만큼 변화의 속도가 빨라졌다.
- 기능 요구사항, 업무 정책 등이 바뀌기 때문에 애플리케이션을 자주 수정해야 한다.
복잡함을 가증시키는 원인
- 단지 양이 많고 어렵다는 뜻이 아님.
- 세부 요소가 이해하기 힘든 방식으로 얽혀있고, 그 때문에 쉽게 다루기 어렵다.
- 근본적인 비즈니스 로직과 엔터프라이즈 기술이라는 두 가지 복잡함이 한데 얽혀 있기 때문

8.2.2 복잡함을 해결하려는 도전

제거될 수 없는 근본적인 복잡함
- 그 복잡함을 효과적으로 상대할 수 있는 전략과 기법이 필요.
실패한 해결책 : EJB
- 애플리케이션 로직을 담은 핵심코드에서 일부 기술적인 코드가 제거된 것은 사실이지만, 오히려 EJB 환경과 스펙에 종속되는 코드로 만들어져야 하는 부담감이 가증
- 복잡함을 덜으려다 오히려 더 큰 복잡함을 추가
비침투적인 방식을 통한 효과적인 해결책 : 스프링
- EJB의 실패를 교훈삼아 출발.
- 기술적인 복잡함을 애플리케이션 핵심 로직의 복잡함에서 제거하는 것을 목표로 둔 것은 동일하나
- EJB 처럼 개발자의 코드에 난입해서 지저분하고 복잡한 코드를 만들어버리는 실수를 하지 않았다.
- 어떤 기술을 적용했을 때 그 기술과 관련된 코드나 규약 등이 코드에 등장하는 경우를 침투적인(invasive) 기술이라고 한다.
- 비침투적인(non-invasive) 기술은 기술의 적용 사실이 코드에 직접 반영되지 않는다. 어딘가에는 기술의 적용에 따라 필요한 작업을 해줘야 하겠지만, 애플리케이션 코드 여기저기에 불쑥 등장하거나, 코드의 설계와 구현 방식을 제한하지 않는다.

8.2.3 복잡함을 상대하는 스프링의 전략

기본 전략은 비즈니스 로직을 담은 애플리케이션 코드와 엔터프라이즈 기술을 처리하는 코드를 분리시키는 것.
기술적 복잡함을 상대하는 전략
- 첫번째 문제 : 기술에 대한 접근방식이 일관성 없고, 특정환경에 종속적이다.
  - 공략방법은 추상화
    - 로우레벨 기술 구현 부분과 기술을 사용하는 인터페이스를 분리하고, 환경과 세부 기술에 독립적인 접근 인터페이스를 제공하는 것이 가장 좋은 해결책이다.
- 두번째 문제 : 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여 등장한다.
  - 공략방법은 AOP
비즈니스와 애플리케이션 로직의 복잡함을 상대하는 전략
- 객체지향 기술
핵심도구 : 객체지향과 DI

8.3 POJO 프로그래밍

8.3.1 스프링의 핵심: POJO

8.3.2 POJO란 무엇인가?

단순한 Java 오브젝트

8.3.3 POJO의 조건

특정 규약에 종속되지 않는다.
- 특정 규약을 따라 비즈니스 컴포넌트를 만들어야 하는 경우 POJO 가 아니다.
특정 환경에 종속되지 않는다.
- 특정 벤더나 서버의 특정 기업의 프레임워크 안에서만 동작 가능한 경우 POJO 가 아니다.
- 비즈니스 로직을 담은 코드에 HttpServletRequest 나 HttpSession, 캐시와 같은 API 가 등장하거나 웹 프레임워크의 클래스를 직접 이용하는 부분이 있다면 그것은 진정한 POJO 라고 볼 수 없다.
진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트

8.3.4 POJO의 장점

기술과 환경에 종속되지 않는다.
- 검증 및 테스트 작성이 수월하다.
- 자동화된 테스트에 유리하다.
객체지향 설계가 자유롭다.

8.3.5 POJO 프레임워크

스프링은 POJO를 이용한 엔터프라이즈 애플리케이션 개발을 목적으로 하는 프레임워크
스프링은 개발자들이 복잡한 엔터프라이즈 기술보다는 객체지향적인 설계와 개발의 원리에 좀 더 집중할 수 있도록 돕는다.

8.4 스프링의 기술

스프링에는 POJO 프로그래밍을 손쉽게 할 수 있도록 지원하는 세 가지 가능기술을 제공한다.
- IoC/DI, AOP, PSA

8.4.1 IoC/DI

직접 자신이 사용할 오브젝트를 new 키워드로 생성해서 사용하는 강한 결합을 쓰는 방법보다 나은 점은 무엇일까?
- 유연한 확장이 가능하게 하기 위해서
DI의 활용 방법
- 핵심기능의 변경
- 핵심기능의 동적인 변경
- 부가기능의 추가
- 인터페이스의 변경
- 프록시
- 템플릿/콜백
- 싱클톤과 오브젝트 스코프
- 테스트

8.4.2 AOP

AOP와 OOP는 서로 배타적이 아니다.
AOP의 적용 기법
- 스프링과 같이 다이내믹 프록시 사용
- 자바 언어의 한계를 넘어서는 언어의 확장을 이용하는 방법
  - e.g.) AspectJ 사용
AOP 적용 단계
- 미리 준비된 AOP 이용
  - e.g.) @Transactional
- 전담팀을 통한 정책 AOP 적용
  - 보안, 로깅, 트레이싱, 성능 모니터링 등
- AOP의 자유로운 이용

8.4.3 PSA (포터블 서비스 추상화)

환경과 세부 기술의 변화에 관계없이 일관된 방식으로 기술에 접근할 수 있게 해주는 PSA

도서 - 토비의 스프링 3.1 Vol 1, 1장~4장

Thu, 01 Apr 2021 00:00:00 +0000

토비의 스프링 3.1 Vol 1 (~ 315p)

1장 오브젝트와 의존관계

단어장

리팩토링
- 기존의 코드를 외부의 동작방식에는 변화 없이 내부 구조를 변경해서 재구성하는 작업 또는 기술
디자인 패턴
- 소프트웨어 설계 시 특정 상황에서 자주 만나는 문제를 해결하기 위해 사용할 수 있는 재사용 가능한 솔루션
템플릿 메소드 패턴
- 상속을 통해 슈퍼클래스의 기능을 확장할 때 사용하는 가장 대표적인 방법
- 자주 변경되며 확장할 기능은 서브클래스에서 만들도록 하는 것
- 서브클래스에서 선택적으로 오버라이드 할 수 있도록 만들어둔 메소드를 훅(hook) 메소드 라고 한다.
팩토리 메소드 패턴
- 서브클래스에서 구체적인 오브젝트 생성 방법을 결정
- 서브클래스에서 오브젝트 생성 방법과 클래스를 결정할 수 있도록 미리 정의해둔 메소드를 팩토리 메소드 라고 한다.
객체지향 설계 원칙
- SOLID
- SRP(단일 책임 원칙), OCP(개방 폐쇄 원칙), LSP(리스코프 치환 원칙), ISP(인터페이스 분리 원칙), DIP(의존관계 역전 원칙)
개방 폐쇄 원칙 (OCP)
- Open-Closed Principle
- 객체지향 설계 원칙 중 하나
- 클래스나 모듈은 확장에 열려있어야 하고, 변경에는 닫혀있어야 한다.
전략 패턴
- 자신의 기능 맥락에서 필요에 따라 변경이 필요한 알고리즘을 인터페이스를 통해 외부로 분리시키고,
- 이를 구현한 구체적인 알고리즘 클래스를 필요에 따라 바꿔서 사용할 수 있게 하는 디자인 패턴
빈(Bean)
- 스프링에 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트
빈 팩토리
- 스프링 IoC 를 담당하는 핵심 컨테이너
- 빈 등록, 생성, 조회 등 관리
애플리케이션 컨텍스트
- 빈 팩토리를 확장한 IoC 컨테이너
- 빈팩토리 기능 + 부가서비스
싱글톤 패턴
- 애플리케이션 내에서 클래스를 제한된 인스턴스 개수(주로 하나)만 존재하도록 강제하는 패턴

1.2 DAO의 분리

관심사의 분리
- Separation of Concerns
- 관심사가 같은 것끼리 하나의 객체 or 친한 객체
- 관심사가 다른 것은 가능한 한 서로 영향을 주지 않도록 분리

UserDao add() 메소드의 관심사항

  public void add(User user) throws SQLException, ClassNotFoundException {
      Class.forName ("org.h2.Driver");
      Connection c = DriverManager.getConnection("jdbc:h2:mem:toby-spring", "sa", "");
      PreparedStatement ps = c.prepareStatement(
              "insert into user (id, name, password) values (?,?,?)");

      ps.setString(1, user.getId());
      ps.setString(2, user.getName());
      ps.setString(3, user.getPassword());

      ps.executeUpdate();

      ps.close();
      c.close();
  }

DB와 연결(커넥션)
- 어떤 DB, 드라이버, 로그인 정보, 커넥션 생성방법
DB에 요청할 SQL 문장을 담고 실행
- 파라미터 바인딩, SQL 실행
리소스 해제

중복된 DB 연결코드 메소드 추출

  public void add(User user) throws SQLException, ClassNotFoundException {
      Connection c = getConnection();
      ...
      (생략)
  }

  private Connection getConnection() throws ClassNotFoundException, SQLException {
      Class.forName("org.h2.Driver");
      return DriverManager.getConnection("jdbc:h2:mem:toby-spring", "sa", "");
  }

DB 커넥션 생성 방식의 추상화
- Connection 을 생성하는 구체적인 코드를 상속받은 쪽에서.
```
  public abstract class UserDao {
      ...
      public abstract Connection getConnection() throws ClassNotFoundException, SQLException;
  }

  public class CustomUserDao extends UserDao {

      @Override
      public Connection getConnection() throws ClassNotFoundException, SQLException {
          Class.forName("org.h2.Driver");
          return DriverManager.getConnection("jdbc:h2:mem:toby-spring", "sa", "");
      }
  }
```
이렇게 슈퍼클래스에 기본적인 로직의 흐름을 만들고, 그 기능의 일부를 추상메소드나 오버라이딩이 가능한 메소드로 만든 뒤 서브 클래스에서 이런 메소드를 필요에 맞게 구현해서 사용하도록 하는 방법을 템플릿 메소드 패턴 이라고 한다.

또한 UserDao의 getConnection() 메소드는 Connection 타입 오브젝트를 생성한다는 기능을 정의해놓은 추상 메소드. UserDao의 서브클래스의 getConnection() 구현이 Connection 오브젝트를 어떻게 생성할 것인지 결정하는 방법. 이렇게 서브클래스에서 구체적인 오브젝트 생성 방법을 결정하게 하는 것을 팩토리 메소드 패턴
- 단점
  - 상속을 사용했다.
  - 다중상속을 허용하지 않기에, UserDao가 다른 목적을 위해 상속을 사용하고 있었다면?
  - 상속관계는 두 가지 다른 관심사에 대해 긴밀한 결합을 허용함

1.3 DAO의 확장

클래스의 분리

  public class UserDao {

      private SimpleConnectionMaker simpleConnectionMaker;

      public UserDao() {
          simpleConnectionMaker = new SimpleConnectionMaker();
      }

      public void add(User user) throws SQLException, ClassNotFoundException {
          Connection c = simpleConnectionMaker.makeNewConnection();
          ...
      }
  }

  public class SimpleConnectionMaker {

      public Connection makeNewConnection() throws ClassNotFoundException, SQLException {
          Class.forName("org.h2.Driver");
          return DriverManager.getConnection("jdbc:h2:mem:toby-spring", "sa", "");
      }
  }

DB 커넥션 생성기능을 새로운 클래스로 분리, 독립 시킨다.

단점
- UserDao가 SimpleConnectionMaker 라는 특정 클래스에 종속되어 있다.
  - UserDao 코드 수정 없이 DB 커넥션 생성 기능을 변경할 방법이 없다.
- DB 커넥션 제공 클래스의 메소드 명이 다를 수 있다.

인터페이스의 도입

긴밀한 연결 사이 추상적인 느슨한 연결고리를 만들어준다.

  public interface ConnectionMaker {
      Connection makeConnection() throws ClassNotFoundException, SQLException;
  }

  public class SimpleConnectionMaker implements ConnectionMaker {

      @Override
      public Connection makeConnection() throws ClassNotFoundException, SQLException {
          Class.forName("org.h2.Driver");
          return DriverManager.getConnection("jdbc:h2:mem:toby-spring", "sa", "");
      }
  }

  public class UserDao {

      private ConnectionMaker connectionMaker;

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

      ...
  }

  public class Application {

      public static void main(String[] args) throws SQLException, ClassNotFoundException {
            
          UserDao dao = new UserDao(new SimpleConnectionMaker());
          ...
      }
  }

UserDao 클래스를 높은 응집도와 낮은 결합도 (high coherence and low coupling) 를 갖도록 리팩토링 높은 응집도 란, 하나의 책임 또는 관심사에만 집중되어있는 형태 낮은 결합도 란, 다른 모듈과 느슨하게 연결된 형태

전략 패턴

MainClass - UserDao - ConnectionMaker 구조는 전략(Strategy) 패턴에 해당한다.
UserDao 는 전략 패턴의 컨텍스트
- 컨텍스트는 자신의 기능을 수행하는데 필요한 기능 중 변경 가능한 DB 연결 방식이라는 알고리즘을 ConnectionMaker 라는 인터페이스로 정의하고
- 이를 구현한 클래스(즉 전략)를 변경하며 사용할 수 있게 분리했다.
컨텍스트(UserDao) 를 사용하는 클라이언트(MainClass) 는 컨텍스트가 사용할 전략(ConnectionMaker를 구현한 클래스)을 컨텍스트의 생성자 등을 통해 선택, 제공

1.4 제어의 역전(IoC)

오브젝트 팩토리
```
  public class DaoFactory {

      public UserDao userDao() {
          return new UserDao(new SimpleConnectionMaker());
      }
  }

  public class Application {

      public static void main(String[] args) throws SQLException, ClassNotFoundException {
            
          UserDao dao = new DaoFactory().userDao();
          ...
      }
  }
```
책임의 분리, 어떤 ConnectionMaker 구현 클래스를 사용할 지 결정하는 기능을 팩토리 클래스에게 완벽히 위임한다. 오브젝트를 생허나는 쪽과 생성된 오브젝트를 사용하는 쪽의 역할과 책임을 깔끔하게 분리 어떻게 만들지와 어떻게 사용할지는 분명 다른 관심이다.

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

일반적인 프로그램 흐름 상
- main() 메소드와 같은 프로그램 시작부에서 다음 사용할 오브젝트를 결정하고, 결정한 오브젝트를 생성하고, 만들어진 오브젝트에 있는 메소드를 호출하고, 그 오브젝트 메소드 안에서 다음에 사용할 것을 결정하고 호출하는 식의 작업이 반복된다.
- 모든 오브젝트가 능동적으로 자신이 사용할 클래스를 결정하고, 언제 어떻게 그 오브젝트를 만들지를 스스로 관장한다.
- 모든 종류의 작업을 사용하는 쪽에서 제어하는 구조
제어의 역전이란 이러한 제어 흐름의 개념을 거꾸로 뒤집는 것.
- 오브젝트가 자신이 사용할 오브젝트를 스스로 선택하지 않는다. 생성하지도 않는다. 자신도 어떻게 만들어지고 어디서 사용되는지 알 수 없다.
- 제어 권한을 갖는 특별한 오브젝트에 의해 결정되고 만들어진다.
제어의 역전의 개념을 쉽게 보면
- UserDao 개선 작업 시 서브클래스를 만들었을 때.
- 서브클래스가 getConnection() 을 구현하지만, 메소드가 언제 어떻게 사용될지는 자신은 모른다.
- 슈퍼클래스의 템플릿 메소드에서 필요시 호출해서 사용하는 것.
- 이처럼 제어권을 상위에 넘기고 자신은 필요할 때 호출되어 사용되도록 한다는 개념
라이브러리와 프레임워크의 차이
- 라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다.
- 동작 중 필요한 기능이 있을 때 능동적으로 라이브러리 사용.
- 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다.
- 프레임워크 위에 개발한 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만든 방식.
- 즉 필자는 분명한 제어의 역전개념이 적용되어있어야 프레임워크라고 말하고 있다.

1.5 제어의 역전(IoC)

스프링 IoC
- 빈 팩토리(빈을 생성하고 관계를 설정) 이자 애플리케이션 컨텍스트(구성요소의 제어) 이다.
  - 사실 똑같은 말
- 적용
```
  @Configuration
  public class DaoFactory {

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

  @Bean
  public ConnectionMaker connectionMaker() {
      return new SimpleConnectionMaker();
  }
  }
```
이 클래스는 이제 자바 코드의 탈을 쓴 스프링 전용 설정정보라고 볼 수 있다.
- 이렇게 스프링을 적용 했을 때 얻을 수 있는 이득을 앞으로 알아보자.
애플리케이션 컨텍스트의 동작방식
- - 애플리케이션 컨텍스트 DaoFactory 클래스를 설정정보로 등록
  - 애플리케이션 컨텍스트 @Bean이 붙은 메소드의 이름을 가져와 빈 목록 생성
  - 클라이언트 가 애플리케이션 컨텍스트 의 getBean() 메소드를 호출
  - 애플리케이션 컨텍스트 는 빈 목록에서 요청한 이름을 찾아 return.
- 장점
  1. 클라이언트는 구체적인 팩토리 클래스를 알 필요가 없다.
    - 프로그램이 커져서 팩토리 클래스가 늘어나도 애플리케이션 컨텍스트를 이용하여 일관된 방식으로 원하는 오브젝트를 가져올 수 있다.
  2. 애플리케이션 컨텍스트는 종합 IoC 서비스를 제공해준다.
    - 오브젝트 생성 및 관계설정 뿐 아니라 오브젝트 생성 방식, 시점, 전략, 자동생성, 후처리, 설정 방식 다변화 등 오브젝트를 효과적으로 활용할 수 있는 다양한 기능을 제공한다.
  3. 애플리케이션 컨텍스트는 빈을 검색하는 다양한 방법을 제공한다.
    - 빈의 이름 뿐 아니라 타입, 어노테이션 등으로 빈을 찾을 수도 있다.

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

오브젝트가 동일하다
- 하나의 오브젝트만 존재하는 것이고 두 개의 오브젝트 레퍼런스 변수를 갖고 있다.
오브젝트가 동등하다
- 기준에 따라 두 오브젝트의 정보가 동등하다고 판단하는 것.
스프링은 여러 번에 걸쳐 빈을 요청하더라도 매번 동일한 오브젝트를 돌려준다.
애플리케이션 컨텍스트는 싱글톤을 저장하고 관리하는 싱글톤 레지스트리 이다.
최초 제한된 리소스에서 성능을 확보하기 위해 싱글톤으로 고안
- 스펙에서 강제하지 않지만, 서블릿도 대부분 멀티스레드 환경에서 싱글톤으로 동작한다.
싱글톤 패턴은 사용하기 까다롭고 여러가지 문제점이 있다.
- 안티패턴이라고 생각하는 사람도 존재
싱글톤 패턴의 한계
- 자바의 싱글톤 구현
```
  public class UserDao {
      private static UserDao INSTANCE;
      ...
      private UserDao(ConnectionMaker connectionMaker) {
          this.connectionMaker = connectionMaker;
      }
            
      public static synchronized UserDao getInstance() {
          if (INSTANCE == null) INSTANCE = new UserDao(...);
          return INSTANCE;
      }
  }
```
  클래스 밖에서 Instance 를 생성하지 못하도록 private 생성자 자신과 같은 타입의 static field 정의 스테틱 팩토리 메소드를 만들고, 최초 호출되는 시점 한 번만 Instance 생성 이후 이미 만들어져 스태틱 필드에 저장해둔 오브젝트만 넘겨준다
- 문제점
  1. private 생성자를 갖고 있기에 상속할 수 없다.
  2. 테스트하기 힘들다
    - Mocking 이 힘들고, 오브젝트를 다이내믹하게 주입하기 힘들다.
  3. 서버환경에서 싱글톤이 하나만 만들어지는 것을 보장할 수 없다.
    - 서버 클래스 로더 구성에 따라, 싱글톤 클래스임에도 하나 이상의 오브젝트가 만들어질 수 있다.
    - 여러 JVM 에 분산되어 설치되면 각각 독립적으로 오브젝트가 생성되기에 싱글톤 가치가 떨어진다.
  4. 싱글톤의 사용은 전역 상태를 만들 수 있기에 바람직하지 못하다.
싱글톤 레지스트리
- 스프링이 직접 싱글톤 형태의 오브젝트를 만들고 관리하는 기능
- 스태틱 메소드와 private 생성자를 사용하지 않고, 평범한 자바 클래스를 싱글톤으로 활용할 수 있다.
- 싱글톤 환경이 아니면 자유롭게 오브젝트를 만들 수 있고, 테스트가 용이해진다.
- 고전적인 싱글톤 패턴을 대신한다.
싱글톤과 오브젝트의 상태
- 싱글톤은 멀티스레드 환경이라면 여러 스레드가 동시에 접근해서 사용할 수 있다.
- 때문에 무상태(stateless) 방식으로 만들어져야 한다.
- 읽기전용 정보 외에 인스턴스 필드를 사용하면 위험하다.
스프링 빈의 스코프
- 빈이 생성되고, 존재하고, 적용되는 범위
- 기본은 싱글톤
- prototype 스코프(매번 새로운 오브젝트 생성), request 스코프(HTTP 요청 시 오브젝트 생성), session 스코프 등이 존재

1.7 의존관계 주입(DI)

IoC 컨테이너 = DI 컨테이너
의존하고 있다는 것은 의존대상이 변하면 영향을 미친다는 뜻
A에서 B에 정의된 메소드를 호출해서 사용하는 경우, 사용에 대한 의존관계 가 있다.
- B에 새로운 메소드가 추가되거나, 기존 메소드 형식이 바뀌면 A도 그에따라 수정되어야 한다.
- 이 경우 B는 A에 의존하지 않는다.
UserDao 의 의존관계
- 작업해왔던 UserDao 는 ConnectionMaker 인터페이스에 의존하고 있다.
```
  public class UserDao {

  private ConnectionMaker connectionMaker;
  ...
  }
```
- ConnectionMaker 인터페이스가 변한다면 UserDao 가 직접적인 영향을 받게 된다.
- 하지만 ConnectionMaker 의 구현체인 SimpleConnectionMaker 가 다른 것으로 바뀌거나 내부에서 사용하는 메소드가 변화해도 UserDao에 영향을 주지 않는다.
- 인터페이스에만 의존관계를 만들어두면 구현 클래스와 관계가 느슨해지면서 변화에 영향을 덜 받는 상태가 된다.
  - 즉, 결합도가 낮다.
- 설계 관점의 의존관계는 이렇지만, 런타임 시 설계 시점의 의존관계가 실체화 되는데
  - 런타임 의존관계 또는 오브젝트 의존관계
- 런타임 의존관계는 모델링 시점의 의존관계와는 성격이 분명히 다르다.
- 프로그램이 시작되고 UserDao 오브젝트가 만들어지고 나서 런타임 시에 의존관계를 맺는 대상, 즉 실제 사용대상인 오브젝트를 의존 오브젝트 라고 말한다.
- DI는 이렇게 구체적인 의존 오브젝트와 그것을 사용할 주체, 보통 클라이언트라고 부르는 오브젝트를 런타임 시에 연결해주는 작업을 말한다.
- 정리하면 의존관계의 주입이란 아래 세 가지 조건을 충족한다.
  1. 클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지 않는다. 그러기 위해서는 인터페이스에만 의존하고 있어야 한다.
  2. 런타임 시점의 의존관계는 컨테이너나 팩토리 같은 제3의 존재가 결정한다.
  3. 의존관계는 사용할 오브젝트에 대한 레퍼런스를 외부에서 제공(주입)해줌으로써 만들어진다.
- 핵심은, 설계시점에 알지 못했던 두 오브젝트의 관계를 맺도록 도와주는 제3의 존재가 있다는 것.
의존관계 검색 (DL)
- 코드에서는 구체적인 클래스에 의존하지 않고, 런타임 시에 의존관계를 결정한다는 점은 의존관계 주입과 비슷
- 외부로부터 주입이 아니라 스스로 검색을 이용
- 자신이 필요로 하는 의존 오브젝트를 능동적으로 찾는다. 물론 자신이 어떤 클래스의 오브젝트를 이용할지 결정하지는 않는다.
- 의존관계를 맺을 오브젝트를 결정하는 것과 오브젝트 생성작업은 외부 컨테이너에게 IoC를 맡기지만, 이를 가져올 때는 메소드나 생성자를 통한 주입 대신 스스로 컨테이너에 요청하는 방법을 사용한다.
```
  public UserDao() {
  DaoFactory daoFactory = new DaoFactory();
  this.connectionMaker = daoFactory.connectionMaker();
  }
```
- 이렇게 해도 UserDao는 여전히 자신이 어떤 ConnectionMaker 오브젝트를 사용할지 미리 알지 못한다.
- 여전히 코드의 의존대상은 ConnectionMaker 인터페이스뿐이다.
- 이 경우 단순히 요청이지만, 이런 작업을 일반화한 스프링 애플리케이션 컨텍스트라면 미리 정해놓은 이름을 전달해서 그 이름에 해당하는 오브젝트를 찾게 된다.
```
  public UserDao() {
      ApplicationContext context = new AnnotationConfigApplicationContext(DaoFactory.class);
      this.connectionMaker = context.getBean("connectionMaker", ConnectionMaker.class);
  }
```
- 단점은 UserDao 에서 스프링이나 오브젝트 팩토리를 만들고 API를 이용하는 코드가 섞여있게 되는 것.
- 때문에 대개는 의존관계 주입 방식을 사용하는 편이 낫다.
- 다만 애플리케이션의 기동시점에서 적어도 한 번은 의존관계 검색 방식을 사용해 오브젝트를 가져와야 한다.
  - 스테틱 메소드인 main()에서는 DI를 이용해 오브젝트를 주입받을 방법이 없기 때문이다.
- 서버에서도 마찬가지다.
  - 서버에는 main()과 같은 기동 메소드는 없지만, 사용자의 요청을 받을 때마다 한 번은 의존관계 검색 방식을 사용해 오브젝트를 가져와야 한다.
- 의존관계 검색과 의존관계 주입의 중요한 차이점
  - 의존관계 검색 방식에서 검색하는 오브젝트는 자신이 스프링의 빈일 필요가 없다.
- DI를 원하는 오브젝트는 먼저 자기 자신이 컨테이너가 관리하는 빈이 돼야 한다는 사실을 잊지 말자.

DI 응용

기능 구현의 교환
- 개발용 ConnectionMaker 생성 코드
```
  @Bean
  public ConnectionMaker connectionMaker() {
  return new LocalDBConnectionMaker();
  }
```
- 운영용 ConnectionMaker 생성 코드
```
  @Bean
  public ConnectionMaker connectionMaker() {
  return new ProductionDBConnectionMaker();
  }
```
- DAO가 100개든 1000개이든 각각 커넥션 메이커를 생성하는게 아니기에, 이렇게 딱 한 줄만 수정하면 된다.

부가기능 추가

DAO가 DB를 얼마나 많이 연결해서 사용하는지 파악하고 싶을 경우

부가기능을 추가한 ConnectionMaker 인터페이스를 구현한 클래스를 만들면 된다.

  public class CountingConnectionMaker implements ConnectionMaker {
            
  private int count = 0;
            
  private ConnectionMaker realConnectionMaker;
            
  public CountingConnectionMaker(ConnectionMaker realConnectionMaker) {
      this.realConnectionMaker = realConnectionMaker;
  }
            
  @Override
  public Connection makeConnection() throws ClassNotFoundException, SQLException {
      this.count++;
      return this.realConnectionMaker.makeConnection();
  }
            
  public int getCount() {
      return this.count;
  }
  }

메소드를 이용한 DI
- setter 메소드를 이용한 주입
  - 세터메소드는 외부에서 오브젝트 내부의 애트리뷰트 값을 변경하려는 용도로 주로 사용
  - 파라미터로 전달된 값을 내부의 인스턴스 변수에 저장
  - 부가적으로 입력값에 대한 검증 등의 작업을 수행할 수 있다.
- 일반 메소드를 이용한 주입
  - 파라미터를 하나로 제한하는 세터의 제약이 싫다면 일반 메소드를 사용할 수도 있다.
  - 파라미터 개수가 많아지고 타입이 여러개라면 실수의 가능성이 있음.
  - 여러 개의 초기화 메소드로 나눠서 한 번에 모든 필요한 파라미터를(생성자의 한계) 다 받지 않도록 할 수도 있다.
- 도서에는 setter 메소드를 통한 DI 를 추천하지만, 현재는 constructor DI 를 권장하는 흐름
```
  public class UserDao {

      private ConnectionMaker connectionMaker;

      public void setConnectionMaker(ConnectionMaker connectionMaker) {
          this.connectionMaker = connectionMaker;
      }
      ...
  }

  @Configuration
  public class CountingDaoFactory {

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

1.8 XML을 이용한 설정

DataSource 인터페이스로 변환

직접 작성한 ConnectionMaker는 DB 커넥션을 생성해주는 기능 하나만 정의한 매우 단순한 인터페이스
Java 에서는 DB 커넥션을 포함한 다양한 기능을 추상화 한 DataSource 라는 인터페이스가 존재한다.

DataSource 의 구현 Class 에서 Connection 을 만들어 준 후 사용하면 된다.

  @Configuration
  public class DaoFactory {

  @Bean
  public UserDao userDao() throws ClassNotFoundException {
      return new UserDao(this.dataSource());
  }

  @Bean
  public DataSource dataSource() throws ClassNotFoundException {
      SimpleDriverDataSource dataSource = new SimpleDriverDataSource();

      Class driverClass = Class.forName("org.h2.Driver");
      dataSource.setDriverClass(driverClass);
      dataSource.setUrl("jdbc:h2:mem:toby-spring");
      dataSource.setUsername("sa");
      dataSource.setPassword("");

      return dataSource;
  }
  }

2장 테스트

2.1 UserDaoTest 다시 보기

작은 단위의 테스트
- 테스트하고자 하는 대상이 명확하다면 그 대상에만 집중해서 테스트하는 것이 바람직하다.
- 관심사의 분리
- = Unit Test
- 통제할 수 없는 외부의 리소스에 의존하는 테스트는 단위 테스트가 아니라고 보기도 한다.
  - 예) DB가 매번 달라지고, 테스트를 위해 DB를 특정상태로 만들 수 없다면
자동수행 테스트 코드
- 테스트를 자주 수행해도 부담이 없도록 자동으로 수행될 수 있어야 한다.
지속적인 개선과 점진적인 개발을 위한 테스트
- 지속적인 개선의 작은 단계를 거치는 동안 테스트를 수행해 확신을 가지고 코드를 변경하면, 전체적으로 코드를 개선하는 작업에 속도가 붙고 더 쉬워진다.
- 새로운 기능이 기대대로 동작하는지 확인할 수 있을 뿐 아니라, 기존 기능들이 수정한 코드에 영향받지 않고 여전히 잘 동작하는지를 확인할 수 있다.
UserDaoTest의 문제점
- 수동 확인 작업의 번거로움
- 실행 작업의 번거로움

2.2 UserDaoTest 개선

테스트 검증의 자동화
- 모든 테스트는 성공과 실패의 두 가지 결과를 가질 수 있다.
  - 또 실패는 테스트가 진행되는 동안에 에러가 발생해서 실패하는 경우(테스트 에러)와
  - 테스트 작업 중에 에러가 발생하진 않았지만 그 결과가 기대한 것과 다르게 나오는 경우(테스트 실패)로 구분해볼 수 있다.

테스트에 일부 자동화 코드 추가

  if (!user.getName().equals(user2.getName())) {
      System.out.println("테스트 실패 (name)");
  } else if (!user.getPassword().equals(user2.getPassword())) {
      System.out.println("테스트 실패 (password)");
  } else {
      System.out.println("테스트 성공");
  }

테스트를 돌리고 마지막 출력메시지가 “테스트 성공” 이라고 나오는지 확인하는 것 뿐이다.

테스트란 개발자가 마음 편하게 잠자리에 들 수 있게 해주는 것 - 켄트 벡
개발 및 유지보수 과정에서 코드 수정 시 마음의 평안을 얻고
- 자신이 만지는 코드에 대해 항상 자신감을 가질 수 있으며
- 새로 도입한 기술 적용에 문제가 없는 지 확인할 수 있는 가장 좋은 방법은
- 빠르게 실행 가능한 자동화된 테스트를 만들어두는 것이다.

JUnit 테스트로 전환

JUnit 은 프레임워크

  @Test
  public void addAndGet() throws SQLException, ClassNotFoundException {
  // given
  ApplicationContext context = new AnnotationConfigApplicationContext(CountingDaoFactory.class);
  UserDao dao = context.getBean("userDao", UserDao.class);

  User user = new User();
  user.setId("choising");
  user.setName("seungmin");
  user.setPassword("hello");

  dao.add(user);
  User user2 = dao.get(user.getId());
        
  // expect
  assertEquals(user2.getName(), user.getName());
  assertEquals(user2.getPassword(), user.getPassword());
  }

2.3 JUnit

UserDao 클래스 deleteAll(), getCount() 메소드 추가

  public void deleteAll() throws SQLException, ClassNotFoundException {
      Connection c = connectionMaker.makeConnection();

      PreparedStatement ps = c.prepareStatement("delete from user");
      ps.executeUpdate();

      ps.close();
      c.close();
  }

  public int getCount() throws SQLException, ClassNotFoundException {
      Connection c = connectionMaker.makeConnection();

      PreparedStatement ps = c.prepareStatement("select count(*) from user");

      ResultSet rs = ps.executeQuery();
      rs.next();
      int count = rs.getInt(1);

      rs.clearWarnings();
      ps.close();
      c.close();

      return count;
  }

기존 테스트코드에 deleteAll(), getCount() 검증 코드 추가

  @Test
  public void addAndGet() throws SQLException, ClassNotFoundException {
      ApplicationContext context = new AnnotationConfigApplicationContext(CountingDaoFactory.class);
      UserDao dao = context.getBean("userDao", UserDao.class);

      dao.deleteAll();
      assertEquals(dao.getCount(), 0);    // here
      User user = new User();
      user.setId("choising");
      user.setName("seungmin");
      user.setPassword("hello");

      dao.add(user);
      assertEquals(dao.getCount(), 1);    // here
      User user2 = dao.get(user.getId());

      assertEquals(user2.getName(), user.getName());
      assertEquals(user2.getPassword(), user.getPassword());
  }

getCount() 테스트 케이스 추가

  @Test
  public void count() throws SQLException, ClassNotFoundException {
      ApplicationContext context = new AnnotationConfigApplicationContext(CountingDaoFactory.class);
      UserDao dao = context.getBean("userDao", UserDao.class);

      User user1 = new User("zingo", "노징고", "1234");
      User user2 = new User("choising", "최싱", "12345");
      User user3 = new User("forever", "포에버", "123456");

      dao.deleteAll();
      assertEquals(dao.getCount(), 0);

      dao.add(user1);
      assertEquals(dao.getCount(), 1);

      dao.add(user2);
      assertEquals(dao.getCount(), 2);

      dao.add(user3);
      assertEquals(dao.getCount(), 3);
  }

addAndGet() 테스트 케이스 보완 및 추가

  @Test
  public void addAndGet() throws SQLException, ClassNotFoundException {
      ApplicationContext context = new AnnotationConfigApplicationContext(CountingDaoFactory.class);
      UserDao dao = context.getBean("userDao", UserDao.class);

      User user1 = new User("zingo", "노징고", "1234");
      User user2 = new User("choising", "최싱", "12345");

      dao.deleteAll();
      assertEquals(dao.getCount(), 0);

      dao.add(user1);
      dao.add(user2);
      assertEquals(dao.getCount(), 2);

      User userGet1 = dao.get(user1.getId());
      assertEquals(userGet1.getName(), user1.getName());
      assertEquals(userGet1.getPassword(), user1.getPassword());

      User userGet2 = dao.get(user2.getId());
      assertEquals(userGet2.getName(), user2.getName());
      assertEquals(userGet2.getPassword(), user2.getPassword());
  }

파라미터로 주어진 id에 해당하는 사용자를 가져오는 지 검증

get() 메소드의 예외상황 테스트

  @Test
  public void getUserFailure() throws SQLException, ClassNotFoundException {
      ApplicationContext context = new AnnotationConfigApplicationContext(CountingDaoFactory.class);
      UserDao dao = context.getBean("userDao", UserDao.class);
        
      dao.deleteAll();
      assertEquals(dao.getCount(), 0);
        
      assertThrows(EmptyResultDataAccessException.class, () -> {
          dao.get("unkown_id");
      });
  }

테스트는 실패한다. get() 메소드에서 쿼리 결과의 첫 번째 row를 가져오게하는 rs.next()를 실행할 때 가져올 row 가 없기 때문. 해당 테스트가 성공하도록 get() 메소드를 수정한다.

  public User get(String id) throws SQLException, ClassNotFoundException {
      // ... (생략)
        
      User user = null;
      if (rs.next()) {
          user = new User();
          user.setId(rs.getString("id"));
          user.setName(rs.getString("name"));
          user.setPassword(rs.getString("password"));
      }

      // ... (생략)

      if (user == null) {
          throw new EmptyResultDataAccessException(1);
      }

      return user;
  }

부정적인 케이스를 먼저 만드는 습관을 들이는 게 좋다.
- 예외적인 상황을 빠뜨리지 않는 꼼꼼한 개발이 가능하다.
테스트 주도 개발(TDD)
- 이처럼 테스트 코드를 먼저 만들고, 테스트를 성공하게 해주는 코드를 작성하는 방식의 개발
- = 테스트 우선 개발(TFD)
- “실패한 테스트를 성공시키기 위한 목적이 아닌 코드는 만들지 않는다” 는 기본 원칙
테스트 코드 개선
- 세 개의 테스트 메소드에 반복적으로 등장하는 앞의 코드 중복 제거
```
  ...
  private UserDao dao;

  @BeforeEach
  public void setUp() {
      ApplicationContext context = new AnnotationConfigApplicationContext(CountingDaoFactory.class);
      this.dao = context.getBean("userDao", UserDao.class);
  }
  ...
```
- JUnit 프레임워크의 테스트 메소드 실행 과정
  1. 테스트 클래스에서 @Test 가 붙은 public, void, 파라미터가 없는 테스트 메소드를 모두 찾는다.
  2. 테스트 클래스의 오브젝트를 하나 만든다.
  3. @Before가 붙은 메소드가 있으면 실행한다.
  4. @Test가 붙은 메소드를 하나 호출하고 테스트 결과를 저장해둔다.
  5. @After가 붙은 메소드가 있으면 실행한다.
  6. 나머지 테스트 메소드에 대해 2~5번을 반복한다.
  7. 모든 테스트의 결과를 종합하여 돌려준다.
  - JUnit5 에서는 @BeforeEach 와 @AfterEach 를 사용하면 동일한 기대결과를 볼 수 있다.
  - 테스트 메소드 실행시 마다 새로운 오브젝트를 만들기에, 각 테스트가 서로 영향을 주지 않고 독립적으로 실행됨이 확실히 보장된다.
  - 또한 인스턴스 변수도 부담없이 사용할 수 있다.
  - 테스트 메소드 일부에서만 공통적으로 사용되는 코드가 있다면 @Before 보다 일반적인 메소드 - 추출방법으로 메소드를 분리하는 것이 낫다.
픽스처 (Fixture)
- 테스트를 수행하는 데 필요한 정보나 오브젝트
- UserDaoTest 의 dao 가 픽스처

2.4 스프링 테스트 적용

테스트 메소드의 컨텍스트 공유
- JUnit 확장기능은 테스트가 실행하기 전 딱 한 번 애플리케이션 컨텍스트를 만들어 두고, 테스트 오브젝트가 만들어질 때마다 특별한 방법을 이용해 애플리케이션 컨텍스트 자신을 오브젝트의 특정 필드에 주입한다.
테스트 클래스의 컨텍스트 공유
- 여러 개의 테스트 클래스가 있는데 모두 같은 설정파일을 가진 애플리케이션 컨텍스트를 사용한다면, 테스트 클래스 사이에서도 애플리케이션 컨텍스트를 공유한다.
컨텍스트를 공유함으로 성능 대폭 향상
@DirtiesContext
- 애플리케이션 컨텍스트 상태를 변경한다는 것을 알려준다.
- 이 annotation 이 붙은 테스트 클래스(메소드) 에는 애플리케이션 컨텍스트 공유를 하지 않는다.
- @DirtiesContext 을 사용하면 테스트 성능이 나빠짐으로 테스트를 위한 별도의 DI 설정으로 해결할 수도 있다.
일반적으로 테스트하기 좋은 코드가 좋은 코드일 가능성이 높다.
스프링 컨테이너 없이 테스트할 수 있는 방법을 최우선 고려
- 가장 수행속도가 빠르고 테스트 자체가 간결하다.

2.5 학습 테스트로 배우는 스프링

학습 테스트
- 자신이 만들지 않은 프레임워크/라이브러리 등을 테스트하는 행위
- 목적은 API나 프레임워크의 기능을 테스트로 보면서 사용방법을 익히려는 것
- 기능검증 목적이 아닌 사용방법 검증 목적
학습 테스트의 장점
- 다양한 조건에 따른 기능을 손쉽게 확인해볼 수 있다.
- 학습 테스트 코드를 개발 중에 참고할 수 있다.
- 프레임워크나 제품을 업그레이드할 때 호환성 검증을 도와준다.
- 테스트 작성에 대한 좋은 훈련이 된다.
- 새로운 기술을 공부하는 과정이 즐거워진다.
  - 이건 너무 주관적인 것 아닐까?
버그 테스트
- 코드에 오류가 있을 때 그 오류를 가장 잘 드러내줄 수 있는 테스트
버그 테스트의 장점
- 테스트의 완성도를 높여준다.
- 버그의 내용을 명확하게 분석해준다.
- 기술적인 문제를 해결하는 데 도움이 된다.

3장 템플릿

OCP
- 코드에서 어떤 부분은 변경을 통해 그 기능이 다양해지고 확장하려는 성질
- 어떤 부분은 고정되어있고 변하지 않으려는 성질
- 변화의 특성이 다른 부분을 구분하고, 각각 다른 목적과 다른 이유에 의해 다른 시점에 독립적으로 변경될 수 있는 효율적인 구조를 만들어주는 것이 바로 OCP(개방폐쇄원칙)
템플릿이란, 이렇게 바뀌는 성질이 다른 코드 중에서 변경이 거의 일어나지 않으며 일정한 패턴으로 유지되는 특성을 가진 부분을 독립시켜서 효과적으로 활용할 수 있도록 하는 방법

3.1 다시 보는 초난감 DAO

deleteAll() 메소드에서 예외처리가 되어있지 않은 예.

  public void deleteAll() throws SQLException, ClassNotFoundException {
      Connection c = connectionMaker.makeConnection();

      PreparedStatement ps = c.prepareStatement("delete from user");
      ps.executeUpdate();             // 이런데서 작업을 하다가 죽으면 리소스가 반환되지 않는다.

      ps.close();
      c.close();
  }

예외처리

  public void deleteAll() throws SQLException, ClassNotFoundException {
      Connection c = null;
      PreparedStatement ps = null;
        
      try {
          c = connectionMaker.makeConnection();
          ps = c.prepareStatement("delete from user");
          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) {
                    
              }
          }
      }
  }

수많은 부분이 변하지 않는 부분이 된다. 위 코드에서 변하는 부분은 ps = c.prepareStatement("delete from user") 이 Line 뿐이다.

변하는 부분을 메소드로 추출

  public void deleteAll() throws SQLException, ClassNotFoundException {
      ...
      ps = this.makeStatement(c);
      ...
  }

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

해당 부분을 추상메소드로 만들고, 해당 클래스를 추상클래스로 변경 후 구체적인 makeStatement() 정의를 서브클래스에게 위임한다.

  public abstract class UserDao {
      ...
      abstract protected PreparedStatement makeStatement(Connection c) throws SQLException;
      ...
  }

makeStatement() 를 구현한 UserDao 서브클래스

  public class UserDaoDeleteAll extends UserDao {

      @Override
      protected PreparedStatement makeStatement(Connection c) throws SQLException {
          PreparedStatement ps;
          ps = c.prepareStatement("delete from user");
          return ps;
      }
  }

이처럼 변하지 않는 부분은 슈퍼클래스에 두고 변하는 부분은 추상 메소드로 정의해둬서 서브클래스에서 오버라이드하여 새롭게 정의해 쓰도록 하는 것이 템플릿 메소드 패턴
- 상속을 통해 기능을 확장해서 사용하는 것
클래스 기능을 확장하고 싶을 때 마다 상속을 통해 확장이 가능한 구조가 되었다.
- 상위 DAO 클래스에 불필요한 변화는 생기지 않는 구조
- 하지만 이렇게되면 DAO 로직마다 상속을 통해 새로운 클래스를 만들어야 한다.
- UserDao 처럼 JDBC 메소드가 4개인 경우
- 클래스를 설계하는 시점에서 구조가 고정된다.
  - 관계에 대한 유연성이 떨어진다.
전략패턴을 적용해보자
- OCP를 잘 지키면서, 템플릿 메소드 패턴보다 유연하고 확장성이 뛰어남
- 오브젝트를 컨텍스트(context) 와 전략(Strategy) 로 분리하고, 클래스 레벨에서는 인터페이스를 통해서만 의존하도록 만드는 패턴
- 확장에 해당하는 변하는 부분을 별도의 클래스로 만들어 추상화된 인터페이스를 통해 위임하는 방식
- Context 의 contextMethod() 에서 일정한 구조를 가지고 동작,
  - 특정 확장 기능은 Strategy 인터페이스를 통해 외부의 독립된 전략 클래스에 위임
- deleteAll() 메소드에서 변하지 않는 부분이 contextMethod() 가 될 것이다.
  - JDBC를 이용한 DB 업데이트 작업 이라는 변하지 않는 맥락(context) 를 갖는다.
  - deleteAll() 의 Context
    - DB 커넥션 가져오기
    - PreparedStatement 를 만들어줄 외부 기능 호출하기
    - 전달받은 PreparedStatement 실행하기
    - 예외 throw
    - 리소스 close
  - 볼드처리한 해당 부분이 전략에 해당한다.
```
  public interface StatementStrategy {
      PreparedStatement makePreparedStatement(Connection c) throws SQLException;
  }
```
```
  public class DeleteAllStatement implements StatementStrategy {
      @Override
      public PreparedStatement makePreparedStatement(Connection c) throws SQLException {
          return c.prepareStatement("delete from user");
      }
  }
```
```
  public class UserDao {
      ...
      public void deleteAll() throws SQLException, ClassNotFoundException {
          Connection c = null;
          PreparedStatement ps = null;

          try {
              StatementStrategy strategy = new DeleteAllStatement();            
              ps = strategy.makePreparedStatement(c);
              ps.executeUpdate();
              ...
          }
          ...
      }
```
  컨텍스트 안에서 구체적인 전략 클래스인 DeleteAllStatement 를 사용하도록 고정되어 있는 것이 문제

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

전략패턴에 따르면 Context가 어떤 전략을 사용하게 할 것인가는 앞단의 Client 가 결정하는 것이 일반적

UserDao.class

  public void deleteAll() throws SQLException, ClassNotFoundException {
      jdbcContextWithStatementStrategy(new DeleteAllStatement());
  }

  private void jdbcContextWithStatementStrategy(StatementStrategy strategy) throws ClassNotFoundException, SQLException {
      Connection c = null;
      PreparedStatement ps = null;

      try {
          c = connectionMaker.makeConnection();
          ps = strategy.makePreparedStatement(c);
          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) {

              }
          }
      }
  }

deleteAll() 메소드가 Client 클라이언트와 컨텍스트 클래스를 분리하지는 않았음

결국 이 구조에서 오브젝트 생성과 컨텍스트로의 전달을 담당하는 책임을 분리시킨 것이 바로 ObjectFactory 이며, 이를 일반화 한 것이 앞에서 살펴봤던 의존관계 주입(DI)
- DI란 이러한 전략패턴의 장점을 일반적으로 활용할 수 있도록 만든 구조
- 일반적으로 DI는 의존관계에 있는 두 개의 오브젝트와 이 관계를 다이내믹하게 설정해주는 오브젝트 팩토리(DI 컨테이너), 그리고 이를 사용하는 클라이언트라는 4개의 오브젝트 사이에서 일어난다.
- 때로는 구조에 따라 하나의 클래스가 클라이언트와 오브젝트 팩토리의 책임을 함께 지고 있을 수도 있고, 클라이언트와 전략, 클라이언트와 DI 관계에 있는 두 개의 오브젝트가 모두 하나의 클래스에 담길 수도 있다.
- 이런 경우에는 DI가 매우 작은 단위의 코드와 메소드 사이에서 일어나기도 한다.
  - 이런 케이스를 마이크로 DI 또는 코드에 의한 DI라는 의미로 수동 DI 라 한다.

add() 메소드 개선하기

  public class AddStatement implements StatementStrategy {

      private User user;

      public AddStatement(User user) {
          this.user = user;
      }

      @Override
      public PreparedStatement makePreparedStatement(Connection c) throws SQLException {
          PreparedStatement ps = c.prepareStatement(
                  "insert into user (id, name, password) values (?,?,?)");

          ps.setString(1, user.getId());
          ps.setString(2, user.getName());
          ps.setString(3, user.getPassword());

          return ps;
      }
  }

  public class UserDao {
      ...
      public void add(User user) throws SQLException, ClassNotFoundException {
          jdbcContextWithStatementStrategy(new AddStatement(user));
      }
      ...
  }

현 구조의 단점은
- DAO 메소드마다 새로운 StatementStrategy 구현 클래스를 만들어야 한다는 점
- User 와 같은 부가정보가 필요할 경우 인스턴스 변수를 만들어야 한다는 점

로컬 클래스

클래스 파일이 많아지는 문제를 해결

UserDao 클래스 안에 내부 클래스로 정의하는것

  public class UserDao {

  ...
  public void add(User user) throws SQLException, ClassNotFoundException {
      class AddStatement implements StatementStrategy {

          @Override
          public PreparedStatement makePreparedStatement(Connection c) throws SQLException {
              PreparedStatement ps = c.prepareStatement(
                      "insert into user (id, name, password) values (?,?,?)");

              ps.setString(1, user.getId());
              ps.setString(2, user.getName());
              ps.setString(3, user.getPassword());

              return ps;
          }
      }
            
      jdbcContextWithStatementStrategy(new AddStatement());
  }
  ...
  }

메소드 안에 클래스를 넣는 건 처음 봄. 신기하당. 클래스 파일이 줄어드는 것과, 내부 클래스의 특징을 이용해 로컬 변수를 바로 가져다 사용할 수 있는 장점

익명 클래스

  public class UserDao {
      ...
      public void add(User user) throws SQLException, ClassNotFoundException {
          jdbcContextWithStatementStrategy(new StatementStrategy() {
              @Override
              public PreparedStatement makePreparedStatement(Connection c) throws SQLException {
                  PreparedStatement ps = c.prepareStatement(
                          "insert into user (id, name, password) values (?,?,?)");

                  ps.setString(1, user.getId());
                  ps.setString(2, user.getName());
                  ps.setString(3, user.getPassword());

                  return ps;
              }
      });
      ...
  }

중첩 클래스
- 독립적인 오브젝트로 만들어질 수 있는 static class
- 정의된 클래스의 오브젝트 안에서만 만들어질 수 있는 내부 클래스(inner class)
  - scope 에 따라 세 가지로 구분된다.
  - 멤버 필드 처럼 오브젝트 레벨에 정의되는 member inner class
  - 메소드 레벨에 정의되는 local class
  - 익명 내부 클래스
전략 패턴의 구조로 보자면 UserDao의 메소드가 Client, 익명 내부 클래스가 개별 전략, jdbcContextWithStatementStrategy() 메소드는 컨텍스트.
- 컨텍스트 메소드는 UserDao 내의 PreparedStatemnet 를 실행하는 기능
- 이 메소드는 Specific 하게 UserDao 용이 아니라, JDBC의 일반적인 작업 흐름을 담고 있으므로, UserDao 클래스 밖으로 독립시켜 모든 DAO가 사용할 수 있게 할 수 있다.
```
  public class UserDao {

  private ConnectionMaker connectionMaker;

  private JdbcContext jdbcContext;
        
  ...
  }
```
- JdbcContext 를 Bean 으로 등록, UserDao 가 JdbcContext Class 를 DI 받는 방식
  - 인터페이스가 아닌 클래스를 직접 DI
  - 강한 응집도를 갖는 클래스, 다른 구현체 변경 니즈가 없는 경우.
  - 귀찮으니까 클래스를 사용하자는 건 잘못된 생각이지만, 이같은 경우 클래스를 직접 DI 해도 ㄱㅊ
  - 찝찝하면 이또한 인터페이스로 해도 ㄱㅊ
- UserDao 의 수동 DI
```
  public class UserDao {

      private ConnectionMaker connectionMaker;

      private JdbcContext jdbcContext;

      public UserDao(ConnectionMaker connectionMaker) {
          this.connectionMaker = connectionMaker;
          this.jdbcContext = new JdbcContext(this.connectionMaker);
      }
  }
```
  - 굳이 인터페이스를 둘 필요 없는 긴밀한 관계는 어색하게 따로 빈으로 분리하지 않고, 내부에서 직접 만들어 사용할 수도 있음.
  - 분명하게 설명할 자신이 없다면 인터페이스를 사이에 둔 평범한 DI 가 좋을지도..?

3.5 템플릿과 콜백

전략 패턴의 기본 구조
- 복잡하지만 바뀌지 않는 일정한 패턴을 갖는 작업흐름(context)
- 일부분만 자주 바꿔서 사용해야 하는 경우(strategy)
위에서 적용한 방식은 전략 패턴의 구조에 익명 내부클래스를 활용한 방식
- 이런 방식을 스프링에서 템플릿/콜백 패턴 이라고 부른다.
- context = template
- 익명 내부 클래스 오브젝트 = callback
템플릿
- 고정된 작업 흐름을 가진 코드를 재사용한다는 의미
콜백
- 실행되는 것을 목적으로 다른 오브젝트의 메소드에 전달되는 오브젝트
- 파라미터로 전달되지만 값을 참조하기 위한 것이 아니라 특정 로직을 담은 메소드를 실행시키기 위함
- functional object
템플릿/콜백의 특징
- 콜백은 보통 단일 메소드 인터페이스를 구현한 익명 내부 클래스 (전략 패턴의 전략은 여러 메소드 가능)
- 템플릿의 작업 흐름 중 특정 기능을 위해 한 번 호출되는 경우가 일반적이기 때문
- 여러 가지 종류의 전략을 사용해야 한다면 하나 이상의 콜백 오브젝트를 사용할 수도?
- 콜백 인터페이스의 메소드에는 보통 파라미터가 있다.
  - 템플릿 작업 흐름 중에 만들어지는 컨텍스트 정보를 전달
- 클라이언트는 템플릿 안에서 실행될 로직을 담은 콜백 오브젝트 생성 , 템플릿 메소드 호출 시 파라미터로 전달
- 템플릿은 정해진 작업 흐름을 따라 진행, 내부의 참조정보를 가지고 콜백 오브젝트 메소드 호출
  - 콜백은 클라이언트 메소드 정보와 템플릿이 제공한 참조정보를 이용해서 작업을 수행하고 그 결과를 템플릿에 return
- 템플릿은 콜백 return 정보를 사용하여 작업을 마무리, 경우에 따라 클라이언트에 return
클라이언트가 템플릿 메소드를 호출하면서 콜백 오브젝트를 전달하는 것은 메소드레벨의 DI
전략패턴과 DI의 장점을 익명 내부 클래스 사용 전략과 결합한 독특한 활용법

콜백의 분리와 재활용

익명 내부 클래스 사용을 최소화 해보자

익명 내부 클래스를 사용하는 부분을 메소드로 추출하고, 변경되는 부분 (문자열) 만 전달하도록 변경

  public class UserDao {
  ...
  public void deleteAll() throws SQLException, ClassNotFoundException {
      executeSql("delete from user");
  }

  private void executeSql(final String query) throws ClassNotFoundException, SQLException {
      this.jdbcContext.workWithStatementStrategy(new StatementStrategy() {
          @Override
          public PreparedStatement makePreparedStatement(Connection c) throws SQLException {
              return c.prepareStatement(query);
          }
      });
  }
  ...
  }

모든 고정된 sql 을 실행하는 dao 메소드는 deleteAll() 메소드처럼 executeSql() 을 호출하는 한 줄이면 끝.

이건 UserDao 에만 종속되는 코드가 아니므로 공통으로 다시 추출
- 클라이언트는 익명 내부 클래스 사용도 없고 깔끔, 단순
- JdbcContext 안에 클라이언트와 템플릿, 콜백이 모두 함께 공존하면서 동작하는 구조
고정된 작업 흐름을 갖고 있으면서 여기저기서 자주 반복되는 코드가 있다면, 중복되는 코드를 분리할 방법을 생각해보는 습관을 기르자.
- 먼저 메소드로 분리하는 간단한 시도를 해보고
- 일부 작업을 필요에 따라 바꾸어 사용해야 한다면 인터페이스를 사이에 두고 분리해서 전략 패턴을 적용하고 DI로 의존관계를 관리하도록
- 바뀌는 부분이 동시에 여러 종류가 있다면 템플릿/콜백 패턴 적용을 고려

간단한 템플릿/콜백 예제

public interface LineCallback {
    int doSomethingWithLine(String line, int value);
}

public class Calculator {

    public int calcSum(String filepath) throws IOException {
        LineCallback sumCallback = (line, value) -> value + Integer.parseInt(line);
        return this.lineReadTemplate(filepath, sumCallback, 0);
    }

    public int calcMultiply(String filepath) throws IOException {
        LineCallback multiplyCallback = (line, value) -> value * Integer.parseInt(line);
        return this.lineReadTemplate(filepath, multiplyCallback, 1);
    }

    public int lineReadTemplate(String filepath, LineCallback callback, int initVal) throws IOException {
        BufferedReader br = null;
        try {
            br = new BufferedReader(new FileReader(filepath));
            int res = initVal;
            String line = null;

            while ((line = br.readLine()) != null) {
                res = callback.doSomethingWithLine(line, res);
            }
            return res;
        } catch (IOException e) {
            System.out.println(e.getMessage());
            throw e;
        } finally {
            if (br != null) {
                try {
                    br.close();
                } catch (IOException e) {
                    System.out.println(e.getMessage());
                }
            }
        }
    }

}

public class CalcTest {

    Calculator calculator;
    String numFilePath;

    @BeforeEach
    public void setUp() {
        this.calculator = new Calculator();
        this.numFilePath = getClass().getResource("/numbers.txt").getPath();
    }

    @Test
    public void sumOfNumbers() throws IOException {
        assertEquals(calculator.calcSum(this.numFilePath), 10);
    }

    @Test
    public void multiplyOfNumbers() throws IOException {
        assertEquals(calculator.calcMultiply(this.numFilePath), 24);
    }
}

제너릭 추가하기

public interface LineCallback<T> {
  T doSomethingWithLine(String line, T value);
}

public class Calculator {

    public int calcSum(String filepath) throws IOException {
        LineCallback<Integer> sumCallback = (line, value) -> value + Integer.parseInt(line);
        return this.lineReadTemplate(filepath, sumCallback, 0);
    }

    public int calcMultiply(String filepath) throws IOException {
        LineCallback<Integer> multiplyCallback = (line, value) -> value * Integer.parseInt(line);
        return this.lineReadTemplate(filepath, multiplyCallback, 1);
    }

    public String concatenate(String filepate) throws IOException {
        LineCallback<String> concatenateCallback = (line, value) -> value + line;
        return this.lineReadTemplate(filepate, concatenateCallback, "");
    }

    public <T> T lineReadTemplate(String filepath, LineCallback<T> callback, T initVal) throws IOException {
        BufferedReader br = null;
        try {
            br = new BufferedReader(new FileReader(filepath));
            T res = initVal;
            String line = null;

            while ((line = br.readLine()) != null) {
                res = callback.doSomethingWithLine(line, res);
            }
            return res;
        } catch (IOException e) {
            System.out.println(e.getMessage());
            throw e;
        } finally {
            if (br != null) {
                try {
                    br.close();
                } catch (IOException e) {
                    System.out.println(e.getMessage());
                }
            }
        }
    }

}

3.6 스프링의 JdbcTemplate

public class UserDao {

    private JdbcTemplate jdbcTemplate;

    public UserDao(DataSource dataSource) {
        this.jdbcTemplate = new JdbcTemplate(dataSource);
    }

    public void add(final User user) {
        this.jdbcTemplate.update("insert into user (id, name, password) values (?,?,?)",
                user.getId(), user.getName(), user.getPassword());
    }

    public User get(String id) {
        return this.jdbcTemplate.queryForObject("select * from user where id = ?", new Object[]{id},
                new RowMapper<User>() {
                    public User mapRow(ResultSet rs, int rowNum) throws SQLException {
                        User user = new User();
                        user.setId(rs.getString("id"));
                        user.setName(rs.getString("name"));
                        user.setPassword(rs.getString("password"));
                        return user;
                    }
                });
    }

    public void deleteAll() {
        this.jdbcTemplate.update("delete from user");
    }

    public int getCount() {
        return this.jdbcTemplate.queryForObject("select count(*) from user", Integer.class);
    }

    public List<User> getAll() {
        return this.jdbcTemplate.query("select * from user order by id",
                new RowMapper<User>() {
                    @Override
                    public User mapRow(ResultSet rs, int rowNum) throws SQLException {
                        return new User(rs.getString("id"), rs.getString("name"), rs.getString("password"));
                    }
                });
    }
}

Negative Test
```
  @Test
  public void getAllNegative() {
      dao.deleteAll();

      List<User> users = dao.getAll();
      assertEquals(users.size(), 0);
  }
```
- 자신이 만든 메소드가 아니더라도, 크기가 0인 리스트 오브젝트를 return 하는지, null 을 return 하는지 확인해 볼 필요가 있다.

4장 예외

4.1

예외가 발생하면 그것을 catch 로 잡고 아무것도 하지않고 넘어가는 것은 정말 위험한 일이다.
- 원치않는 예외가 발생하는 것보다도 훨씬 더 나쁜 일이다.
- 예외가 발생했는데 그것을 무시하고 계속 진행해버리기 때문
- 어떠한 경우에도 이런 코드를 만들면 안된다.
```
  } catch (SQLException e) {
  System.out.println(e);  // 이것도
  e.printStackTrace();    // 이것도
  }
```
- 예외 처리의 핵심 원칙은 모든 예외는 적절하게 복구되든지 아니면 작업을 중단시키고 통보되든지.
- 예외를 무시하거나 잡아먹어 버리는 코드를 만들지 말라.
무의미하고 무책임한 throws
```
  public void method1() throws Exception {
      method2();
  }

  public void method2() throws Exception {
      method3();
  }

  public void method3() throws Exception {
      ...
  }
```
- 예외를 일일이 catch 하기도 귀찮고, 매번 정확하게 예외 이름을 적어서 선언하기도 귀찮아서.
- 이 경우, 사용 시 throws Exception 으로 얻을 수 있는 정보가 없다.
  - 예외가 진짜 발생하는건지, 어떤 예외가 발생할 수 있는 건지, 습관적으로 복붙한건지…
- 이것도 당연히 안티패턴

4.1.2 예외의 종류와 특징

자바에서 throw 를 통해 발생시킬 수 있는 예외는 크게 세 가지가 있다.

Error
- java.lang.Error 클래스의 서브클래스들
- 주로 JVM 에서 발생 (OOM, ThreadDeath)
- Appliaction 레벨에서 대응 방법이 없어 처리를 신경쓰지 않아도 된다.
Exception / Checked Exception
- java.lang.Exception 클래스와 서브클래스
- Checked Excpetion 은 Exception 클래스의 서브클래스이면서 RuntimeException 클래스를 상속하지 않은 것
- 반드시 예외처리를 해야한다
  - try/catch, throws
  - 그렇지 않으면 compile error
- 자바 초기 설계자들은 전부 checked exception 을 사용하고자 했던 듯
  - 대표적으로 IOException, SQLException
RuntimeException / Unchecked Exception
- RuntimeException 클래스를 상속한 것
- 예외처리를 강제하지 않는다.
- 주로 프로그램의 오류
  - NPE, IllegalArgumentException

4.1.3 예외처리 방법

예외 복구
- 예외상황을 파악하고 문제를 해결해서 정상 상태로 돌려놓는 것
- 사용자에게 예외상황으로 비쳐도 애플리케이션에서는 정상적으로 설계된 흐름을 따라 진행되도록
- 이를테면 네트워크가 불안하여 원격 DB 서버에 접속하다 실패해서 SQLException 이 발생할 경우 재시도 횟수를 정하고 재시도를 해볼 수 있다.
  - 복구가 될 수도 있지만 정해진 횟수를 초과하면 복구를 포기해야 함
- 예외처리를 강제하는 checked exception 은 어떤식으로든 복구할 가능성이 있는 경우
예외처리 회피
- throws, catch -> rethrow
- 템플릿/콜백 패턴에서 콜백 오브젝트 메소드는 대부분 예외를 회피한다.
  - 콜백 오브젝트의 역할이 아니라고 보기 때문, 템플릿 레벨에서 처리
- 무책임한 회피는 ㄴㄴ
  - 다른 오브젝트에게 예외처리 책임을 분명히 지게 하거나
  - 사용하는 쪽에서 예외를 다루는 게 최선의 방법이라는 확신이 있어야 한다.
예외 전환
- 발생한 예외를 적절한 예외로 전환하여 메소드 밖으로 던지는 것
  - 첫째 목적
    - 예외상황에 대한 의미를 분명하게 해줄 수 있는 예외로 변경하기 위해
    - 예를 들어 회원가입 시 아이디가 같은 사용자가 있어 DB Save 에서 SQLException 이 발생하였다면
      - 서비스 계층에서는 왜 SQLException 이 발생했는지 알 수 없다.
      - 이 때 DupliacateUserIdException 같은 예외로 변경해서 던진다면?
  - 둘째 목적
    - 예외를 처리하기 쉽고 단순하게 만들기 위해 포장(wrap) 하는 것
    - 예를 들어 비즈니스 로직에서 의미 있는 예외거나 복구 가능한 예외가 아닌 checked Exception 을 runtime Exception 으로 wraping 하여 던지는 것
- 전환하는 예외는 보통 발생한 예외를 담아 중첩 예외로 만드는 것이 좋다.
```
  catch(SQLException e) {
      ...
      throw Duplication(e);
  }
```

4.1.4 예외처리 전략

자바가 처음 만들어 질 때 많이 사용되던 애플릿이나 AWT, 스윙을 사용한 독립형 애플리케이션에서는 통제 불가능한 시스템 예외여도 애플리케이션 작업이 중단되지 않게 해주고 상황을 복구해야 했다.
- 예를 들어 워드 파일 열기 기능에서 입력한 이름의 파일을 찾을 수 없다고 애플리케이션이 종료될 수는 없기에
하지만 자바 엔터프라이즈 서버환경은 다르다.
- 수많은 사용자 각각의 독립적인 요청(작업)의 예외발생 시 작업을 일시 중지하고 사용자와 바로 커뮤니케이션 하여 예외상황을 복구할 수 있는 방법이 없다.
- 예외가 발생하지 않도록 차단하는 것과, 예외 발생 시 해당 요청의 작업을 취소하고 서버관리자나 개발자에게 통보해주는 편이 낫다.
때문에 checked exception 의 활용도와 가치는 점점 떨어지고 있다.
예전에는 복구할 가능성이 조금만 보이면 checked exception 으로 만들 생각을 했으나, 이제는 항상 복구 가능한 상황이 아니면 unchecked exception 으로 만드는 경향
런타임 예외를 사용하는 경우 컴파일러가 예외처리를 강제하지 않으므로 충분히 신경써야 한다.
- API 문서나 레퍼런스 문서 등을 통해, 메소드를 사용할 때 발생할 수 있는 예외의 종류와 원인, 활용방법을 자세히 설명해두자.
애플리케이션 예외
- 비지니스 로직에서 처리되어야 하는 예외
  - 이를테면 잔고 이상의 돈을 출금하려 할 때,
- 이 때는 반드시 catch 하여 에러처리를 하라는 의미로 checked exception 으로 만드는 것을 권장

4.2 예외 전환

JdbcTemplate 이 던지는 DataAccessException은 런타임 예외로 SQLException 을 포장해주는 역할을 한다.
- 또한 상세한 예외정보를 의미있고 일관성 있는 예외로 전환해서 추상화해주려는 용도로 쓰이기도.
Jdbc 의 한계
- 비표준 SQL
  - 각 벤더사 마다 조금씩 다른 SQL
  - 이건 7장에서 다시 보자.
- SQLException의 비표준 에러코드
  - 각 벤더사의 전용 코드이다.
  - getSQLState() 로 예외상황에 대한 상태정보를 가져올 수는 있고, 이는 어느정도 표준이 있다.
  - 스프링 JdbcTemplate 은 DataAccessException 으로 SQLException 을 대체하고
    - DB별 에러코드를 분류해서 맵핑해놓음.
    - 때문에 DB의 종류와 상관 없이 중복 키 에러는 DuplicationKeyException 이 발생.
DataAccessException
- DataAccessException 은 JDBC 의 SQLException 을 전환하는 용도로만 만들어 진 것이 아니다.
- 의미가 같은 예외라면 JDBC 이외 자바 데이터 액세스 기술의 종류와 상관없이 일관된 예외가 발생하도록 만들어준다.
- 데이터 액세스 기술에 독립적인 추상화된 예외를 제공하는 것.
  - 스프링은 진짜 천잰가..?
DAO 인터페이스와 구현과 분리
- DAO를 따로 사용하는 가장 중요한 이유는 데이터 엑세스 로직을 담은 코드를 성격이 다른 코드에서 분리하기 위함.
- 분리된 DAO는 전략패턴을 적용해 구현방법을 변경해서 사용할 수도 있고.
- DAO를 사용하는 쪽에서 DAO 내부에서 어떤 데이터 액세스 기술을 사용하는지 신경쓰지 않아도 된다.
  - 구체적인 클래스 정보와 구현 방법을 감추고, DI를 통해 제공되도록 만드는 것이 바람직하다.
- DataAccessException 예외 추상화를 잘 적용하면 이상적

4.2.4 기술에 독립적인 UserDao 만들기

인터페이스 네이밍
- I라는 접두어를 붙이는 방법
- 인터페이스 이름을 단순화 하고 구현 클래스는 각각의 특징을 명시하는 방법

UserDao Interface

  public interface UserDao {

      void add(User user);

      User get(String id);

      List<User> getAll();

      void deleteAll();

      int getCount();
  }

UserDao 구현체, UserJdbcDao 클래스

  public class UserJdbcDao implements UserDao {

      private JdbcTemplate jdbcTemplate;

      public UserJdbcDao(DataSource dataSource) {
          this.jdbcTemplate = new JdbcTemplate(dataSource);
      }

      @Override
      public void add(User user) {
          ...
      }

      @Override
      public User get(String id) {
          ...
      }

      @Override
      public List<User> getAll() {
          ...
      }

      @Override
      public void deleteAll() {
          ...
      }

      @Override
      public int getCount() {
          ...
      }
  }

JdbcTemplate 을 사용했을 때 중복 키 테스트
```
  @Test
  public void duplicateKey() {
      dao.deleteAll();

      dao.add(user1);
      assertThrows(DuplicateKeyException.class, () -> {
          dao.add(user1);
      });
  }
```
- DuplicateKeyException 은 JDBC 를 이용하는 경우에만 발생
  - 하이버네이트는 ConstraintViolationException 등
- 때문에 DAO에서 사용하는 데이터 액세스 기술과 상관없이 동일한 예외를 얻고 싶다면 직접 예외를 정의해두고 예외전환 이 필요하다

예외전환 학습테스트

  @Test
  public void sqlExceptionTranslate() {
      dao.deleteAll();

      try {
          dao.add(user1);
          dao.add(user1);
      } catch (DuplicateKeyException e) {
          SQLException sqlException = (SQLException)e.getRootCause();
          SQLExceptionTranslator sqlExceptionTranslator = new SQLErrorCodeSQLExceptionTranslator(this.dataSource);
          Assertions.assertTrue(sqlExceptionTranslator.translate(null, null, sqlException) instanceof DuplicateKeyException);
      }
  }

핵심은 DAO 를 데이터 액세스 기술에서 독립시키려면 인터페이스 도입과 런테임 예외 전환, 기술에 독립적인 추상화된 예외로 전환이 필요하다.

인터뷰를 준비해보자 from. 더개발자 인터뷰 가이드 강의

Mon, 08 Feb 2021 00:00:00 +0000

면접에서 검증당하는 스킬

소프트 스킬

like 커뮤니케이션 스킬
6가지 주요 소프트 스킬
- 고객 중심
  - 질문 예
    - 고객 요구를 만족시켰던 서비스 제공 경험
      - 성공적일 수 있던 핵심적 이유
    - 고객 기대에 만족하는 서비스를 제공하기 힘들었던 경험
      - 다시 그런 업무를 하게된다면 어떻게?
    - 고객이 가지고 있는 문제를 해결해 본 경험
  - 좋은 답변 특징
    - 책임감을 갖고 주기적으로 고객의 요구/이슈를 파악하려는 시도
    - 고객의 요구와 기대를 조사하기 위한 피드백 시스템 구축/운영
    - 고객의 요구와 기대를 조사해 서비스 적용경험
- 결과 도출
  - 비즈니스에 필수적으로 필요한 업무에 집중하고 적절한 품질과 기간 내에 결과를 만들어 내는 역량
    - 문제를 효율적으로 해결, 책임감, 비즈니스에 필요한 도전적인 업무, 동료의 신뢰
  - 질문 예
    - 프로젝트 목표 달성하기 어려웠던 경험과 문제
    - 장기적인 프로젝트에서 오너쉽을 가지고 일한 경험? 각각의 마일스톤을 제때 맞추기위해 어떤 노력을 했는지?
    - 도전적인 프로젝트였지만 동료들과 함께 해낸 경험
  - 후속 질문
    - 해당 프로젝트는 어떻게 참여?
    - 어떤 문제? 어떻게 해결?
    - 다시 돌아봤을 때 성공 요인 or 다르게 시도해보고 싶은 것
  - 좋지 못한 답변
    - 지시에 따르기만 한 경우(수동적인 태도)
    - 충분한 회의/분석 없이 문제해결 시도에 급급
    - 중요한 의사소통 결여
  - 좋은 답변
    - 예정된 일정 내 긍정적인 결과
    - 문제 해결에 필요한 정량적인 데이터를 수집해본 경험(구체적이고 목적성을 띈)
    - 목표를 달성하는데 필요한 업무를 주관적으로 제안하고 실행에 옮긴 경험
    - 지속적으로 목표 달성에 필요한 데이터를 모니터해 본 경험(적절하게 분석하고 주도적으로 해결한)
- 영향력
  - 다른 동료 또는 팀에 좋은 영향/설득
    - 효율적/논리적 커뮤니케이션 능력
    - 긍정적인 관계 형성
  - 질문 예
    - 업무를 위해 설득/이해 시킨 경험
    - 동료와 좋은 관계 형성으로 프로젝트에 긍정적 영향을 미친 경험
    - 다양한 견해를 가지고 있는 관계자들의 요구를 성공적으로 만족시킨 경험
    - 동료나 다른 팀을 설득해 프로세스 개선 경험
  - 좋지 못한 답변
    - 설득에 필요한 정량적인 데이터를 활용 X
    - 관계자들과 신뢰
    - 개인 관심사 중심 업무(A,B 중에 A가 해보고싶어서 했다)
    - 비효율/비논리적 방법으로 관계 형성
  - 좋은 답변 특징
    - 데이터를 근거삼아 설득한 경험
    - 강한 신뢰
    - 관계자들의 견해와 입장을 이해하고, 이해를 바탕으로 업무에 도움
    - 설득을 통해 팀 / 타팀까지 좋은 영향을 주었던 경험
- 적응력
  - 변화하는 환경에 효율적으로 반응하는 능력
    - 끊임없는 탐구/학습
    - 스트레스가 심한 상황에서도 건설적 자세유지
  - 질문 예
    - 조직 개편으로인한 스트레스 경험
    - 업무 처리 방법에 변화를 시도했던 경험
    - 가이드나 정보가 거의 없이 시작했던 프로젝트를 완료했던 경험
  - 좋지 못한 답변
    - 스트레스를 잘 처리하지 못한 경험
    - 정보가 부족한 경우, 비효율적으로 일을 처리한 경험
    - 변하는 상황에 맞추려는 노력이 부족했던 경험
  - 좋은 답변
    - 변하는 상황에 효율적/즉각적 대응 경험
    - 정보가 부족한 경우에도 효율적으로 일을 하거나, 그 자체를 새로운 기회로 삼았던 경험
    - 스트레스가 심한 상황에서 건설적 자세를 유지한 경험 (개인에겐 힘들지만, 조직에서 왜 필요한지, 왜 스트레스인지, 어떻게 해결할 수 있는지 고민)
- 판단력
  - 여러 대안과 관점을 고려하여 결정하는 능력
    - 해결하려는 문제의 범위 결정
    - 가정 X, 근거를 통한 증명
  - 질문 예
    - 업무에서 치명적인 실수를 했던 경험
      - 실수를 통해 배운점이나 개선점을 말하면 좋을듯
    - 여러 대안이 있는 상황에서 어떤 과정을 통해 가장 적절한 방법을 선택했는지(납기가 불충분 할때 어떻게 선택하는지)
    - 복잡했던 문제를 해결하기 전에 판단에 필요한 지식을 습득해야 했던 경험
  - 좋지 못한 답변
    - 여러 대안을 충분히 검토하지 X
    - 서두르거나 충분한 정보 없이 섣부른 판단
    - 동료 또는 타 팀 도움이 필요한 상황에서 도움을 요청하지 않은 경험
  - 좋은 답변
    - 판단에 필요한 정보를 다양한 방법으로 수집하고 검토하여 결정한 경험
    - 필요한 정보를 기반으로 적절한 시간 내에 좋은 판단을 한 경험
    - 필요한 상황에서 적절한 도움을 요청했던 경험
- 협업
  - 동료 또는 다른 팀간의 팀웍 또는 공조를 통해 업무를 해내는 능력
    - 여러 동료 또는 팀의 리소스와 노력을 조합하여 일을 한다
    - 개인의 목표가 아닌 공동의 목표를 달성하려 노력
  - 질문 예
    - 치명적인 이슈를 해결하는데 필요한 다른 팀과 일한 경험
    - 여러 팀과 함께 일해야 했던 프로젝트가 잘 되지 않았던 경험
    - 동료와 마찰이 생겼던 경험
  - 좋지 못한 답변
    - 협업이 필요한 상황에서 최소한의 기여만 한 경험
    - 요청 받은 경우에만 협업했던 경험
    - 협업을 증진시켰던 좋은 사례를 들지 못하는 경우
  - 좋은 답변
    - 협업에서 의미있고 중요한 업무를 했던 경험
    - 필요한 경우 협업을 제시하거나 주도한 경험
    - 협업을 증진 시켰던 좋은 사례

하드 스킬

like 코딩 능력

준비

예상 질문 답변 준비
- 용어 정리
프로그래밍 관련 서적 읽기
자료구조 / 알고리즘 복습
- Big O
- 리스트, 배열, 스택, 큐, 해시 테이블, 힙, 이진 트리 등 자료구조
- 정렬
- BFS, DFS

이력서

기술과 핵심 역량을 구체적으로 명시
- 기술set + 경험 + effect
편견을 제공할 수 있는 정보 최소화
- 정말 시민의식 높은 세상이라면 이게 맞겠지만
- 유리한 편견을 제공할 수 있는 정보를 제공하는 쪽도 고려해봄직할 듯

면접

가장 어려웠던 프로젝트?

질문에 대한 답변 프레임워크

STAR 프레임워크
- Situation : 어떠한 상황
- Task : 어떤 업무(Task) 나 또는 목표(Target) 를 달성해야 했는지
- Action : 그래서 본인이 왜, 무엇을, 어떻게 했으며
- Result : 결과는 어땠는지, 성과는? or 실패했다면 배운 점은?

오퍼 수락 전 확인 할 것

구체적으로 어떤 일을 하게 될 지
- 이를테면 B2C 인지, 플랫폼 성격인지
같이 일을 하게 될 동료 구성원
- 신생 팀인지, 안정화된 팀에 들어가는 케이스인지, 목적/기능조직인지
운영 업무와 개발 업무의 비중
하루 일과(워라밸?)

신규 조직 업무 적응

생소한 키워드를 문맥별로 모아서 질문
- 간단한 질문이 아니라면 30분~1시간 가량 미팅을 잡는게 좋음
처음부터 너무 많은 정보를 파악하려하지말고, 나눠서 정복
장기 or 단기적으로 개선하고 싶은 점들을 기록하고 정리해보자.
- 건설적인 태도로 공유까지 고려

코딩 인터뷰

주요 목적
- 프로그래밍 언어 능력
- 학습 능력 / 적응력
- 문제 분석 및 해결 능력
- 논리적 사고 / 코드로 풀어내는 능력
- 협업에 필요한 의사소통 능력
문제 풀이 프레임워크
- 문제를 명확히 이해했는지 확인
- 가정하고 있거나 가정할 수 있는 것을 확인
- 실제 예를 들어가며 다시 확인 (추후 TC)
- 문제 해결책 고민
- 해결책을 설명하고 시간/공간 복잡도
- 코딩
- 테스트

TIL(20201217)

Thu, 17 Dec 2020 00:00:00 +0000

20201217

QueryDSL 우아콘 이동욱님 세션

QueryDSL 의 exist 메소드 쓰지 않기

queryDsl exists 메소드는 sql exsist 를 쓰지 않는다.
- sql exist 는 하나를 찾자마자 멈추기 때문에 효율적.
그래서 query dsl exsist 메소드나, fetchCount > 1 보다
fetchFirst 가 더 효율적이다!
- 왜냐면 하나를 찾자마자 멈추는 효과때문에

이미 아는 값을 조회하지 말자. as 표현식으로 대체할 수 있다. asString, asNumber

Projcetions.fields(BookPageDto.class,
                   book.name,
                   Expressions.asNumber(bookNo).as("bookNo"),
                   book.id)

Select 절에 Entity 조회를 굳이 안해도 되는지 생각해보기

projections 로 dto 를 가져올 때 id 만 조회해와서
- adItem.customer.id.as(“customerId”)
toEntity() 메소드 시 .customer(new Customer(customerId))
이렇게 ID 만 같은 객체를 생성해도 저장할 때 문제가 없다. 는데 customer 가 다 null 로 저장되지는 않으려나?

group by 최적화

file sort 제거를 위하여
order by null 직접 구현하여 넣어주기
(Order.ASC, NullExpression.DEFAULT, Default);
페이징일 경우 order by null 을 사용하지 못한다.

정렬

조회 결과가 100건 이하라면, 애플리케이션 정렬이 유리하다.

커버링 인덱스

JPQL 은 from 절의 서브쿼리를 사용하지 못하므로
DB 를 두번치는 방법을 사용한다.
- id 만 조회하는 쿼리
- 두번째 진짜 조회
  - where 절에 in 구문에 위 ID 리스트

JPA Bulk inset 는 자제한다.

도서 - Elasticsearch in action (4, 9)

Wed, 11 Nov 2020 00:00:00 +0000

Elasticsearch in action (139p~)

4장 데이터 검색

4.1 검색 요청의 구조

4.1.1 검색 범위 지정하기

_search …
- 전체 클러스터 검색
{index}/_search …
- index 에서 검색
{index}/event/_search …
- index 에서 event type 검색
_all/event/_search, */event/_search …
- 전체 index 에서 event type 검색
{index},other/event,group/_search …
- index 와 다른 인덱스에서 이벤트 및 그룹 타입 검색
+get-toge*,-{index}/_search …
- 명시된 index 제외, get-toge에 해당하는 모든 인덱스에서 검색
다중 인덱스 검색하는 alias 도 사용할 수 있다.
- 당연히 최고 성능을 내려면 최소한의 인덱스를 타도록 하는게 좋다.

4.1.2 검색 요청의 기본 구성 요소

query
- 검색 요청에 있어 가장 중요한 구성 요소
- 점수 기반으로 최적의 도큐먼트를 반환하거나 원치 않는 도큐먼트를 걸러내도록 설정
- DSL 쿼리와 DSL 필터를 사용해서 구성
- e.g.) _search?q=title:elasticsearch
  - title이 elasticsearch 단어와 일치하는 도큐먼트를 찾겠다.
size
- 반환할 도큐먼트 개수
from
- size 와 함께 페이징
- e.g.) _search?from=7&size=5
  - from 7, size 5 라면 8,9,10,11,12 번째 결과를 반환한다.
_source
- _source 필드를 어떻게 반환할 것인가
- _source 하면 완전한 _source를 반환
- 설정으로 반환되는 필드를 걸러낼 수 있다.
- 전체 내용이 필요하지 않을 때 적절히 사용
- e.g.) _search?sort=date:asc&_source=title,date
```
      ...
      "_source": {
          "date" :
          "title" :
      },
      ...
```
  날짜 오름차순 순으로 정렬한 결과에서 최초 10건을 response에 title 과 date 필드만 포함
sort
- e.g.) _search?sort=date:asc
  - 날짜 오름차순으로 정렬한 결과 중 최초 10개를 반환한다.

4.1.3 본문 기반 검색 요청 사용하기

from, size 예제

      curl '..../{index}/_search' -d '{
          "query": {
              "match_all": {}
          },
          "from": 10,
          "size": 10
      }'

_source 필터링 예제

      curl '..../{index}/_search' -d '{
          "query": {
              "match_all": {}
          },
          "_source": ["name", "date"]
      }'

와일드카드도 사용 가능 (name, nation 필드 둘 다 반환할 때) _source: "na*" 이렇게 할 수 도 있음

response 에 포함할 필드(include), 제외할 필드(exclude) 예제

      curl '..../{index}/_search' -d '{
          "query": {
              "match_all": {}
          },
          "_source": {
              "include": ["location.*", "date"],
              "exclude": ["location.geolocation"]
          }
      }'

순서 정렬
- 지정하지 않으면, 일치한 도큐먼트를 _score 값의 내림차순으로 정렬
- 생성일 기준 가장 오래된 것으로 시작해서, 그룹 이름 기준으로, 마지막으로 _score 결과로 정렬 결과를 반환하는 예제
```
      curl '..../{index}/_search' -d '{
          "query": {
              "match_all": {}
          },
          "sort": [
              {"created_on": "asc"},
              {"name": "desc"},
              "_score"
          ]
      }'
```

4.2 쿼리와 필터 DSL

match query 예제

      curl '..../{index}/_search' -d '{
          "query": {
              "match": {
                  "title": "hadoop"
              }
          },
      }'

쿼리가 특정 텀으로 점수 계산하는 것과 달리, 검색에서 필터는 이 도큐먼트가 이 쿼리와 일치 하는가 하는 단순 이진법의 예/아니요 답변만을 반환한다.
- 필터는 일반 쿼리를 사용하는 것보다 더 빠를 수 있고, 캐시할 수 있다.
- 필터 쿼리 예제
```
      curl '..../{index}/_search' -d '{
          "query": {
              "filtered": {
                  "query": {
                      "match": {
                         "title": "hadoop"
                      }
                  },
                  "filter": {
                      "term": {
                          "host": "andy"
                      }
                  }
              }
          },
      }'
```
  일반 쿼리 필터 title hadoop, 텀 필터 host andy
- ES 는 필터를 캐시 해야 할 지에 관해 수동으로 지정하는 기능을 제공한다.
  - 음 살짝 db index 비슷한 기분?

쿼리 대신 필터 사용이 필요할 때 match_all 쿼리가 유용하다.

도큐먼트 점수에 신경쓰지 않을 때 아래와 같이 사용

      curl '..../{index}/_search' -d '{
          "query": {
              "filtered": {
                  "query": {
                      "match_all": {}
                  },
                  "filter": {
                      // 필터 세부 내용
                  }
              }
          },
      }'

쿼리 요소는 이 경우 완벽하게 생략할 수 있다.

query_string 쿼리
- AND, OR 처럼 불린 연산자로 서로 다른 텀을 검색하고, -(마이너스) 연산을 사용해서 결과로부터 도큐먼트 제외하는걸 합칠 수 있다.
- 가독성이 떨어지고 확장하기 어려운 단점
- 웹 사이트 사용자에게 노출되면 위험하다는 점

텀 쿼리와 텀 필터

텀 쿼리

      curl '..../{index}/_search' -d '{
          "query": {
              "term": {
                  "tags": "elasticsearch" // 내용
              }
          },
      }'

텀 필터

      curl '..../{index}/_search' -d '{
          "query": {
              "filtered": {
                  "query": {
                      "match_all": {}
                  },
                  "filter": {
                      "term": {
                          "tags": "elasticsearch" // 내용
                      }
                  }
              }
          },
      }'

텀 필터는 점수에 영향을 미치지 않고 텀을 포함하는 도큐먼트

텀즈 쿼리

jym 과 hadoop 중 어느 하나와 일치하는 도큐먼트를 찾는 예제

      curl '..../{index}/_search' -d '{
          "query": {
              "terms": {
                  "tags": ["jym", "hadoop"]
              }
          },
      }'

쿼리 일치 전에 도큐먼트에서 최소 개수의 텀 일치를 강제하려면, minimum_should_match 파라미터를 사용

      curl '..../{index}/_search' -d '{
          "query": {
              "terms": {
                  "tags": ["jym", "hadoop", "lucene"],
                  "minimum_should_match": 2
              }
          },
      }'

4.2.3 매치 쿼리와 텀 필터

매치 쿼리는 몇몇 서로 다른 방식으로 동작할 수 있다.
주요한 두 가지 기능은 boolean, phrase

boolean 기능

기본적으로 쿼리는 boolean 과 or 연산
“Elasticsearch Denver” 텍스트를 검색한다면 “Elasticsearch OR Denver” 로 검색

아래처럼 연산자를 and 로 변경할 수 있다.

      curl '..../{index}/_search' -d '{
          "query": {
              "match": {
                  "name": {
                      "query": "Elasticsearch Denver",
                      "operator": "and"
                  }
              }
          },
      }'

phrase 기능

각 단어의 위치에 따른 검색

leeway 는 토큰사이의 거리

      curl '..../{index}/_search' -d '{
          "query": {
              "match": {
                  "name": {
                      "type": "phrase",   // phrase
                      "query": "enterprise london",
                      "slop": 1           // 텀간 leeway 거리를 가지도록
                  }
              }
          },
      }'

phrase_prefix 쿼리
- phrase 로 검색하는 거에 더해서 마지막 텀에 프리픽스 매칭을 허용
multi_match 로 다중 일치
- 하나의 쿼리를 다중 필드에 검색

4.3.1 bool 쿼리

몇 개의 쿼리라도 특정 부분이 must, should, must_not 로 데이터가 일치하는지 명시하게 하는 쿼리 구문을 이용해서 결합할 수 있다.

bool 쿼리 절	이진 연산 대응	의미
must	and	일치
must_not	not	일치하지 않아야 함
should	or	유사하게 일치하거나 그렇지 않을 수 있다, minimum_should_match 로 일치 개수 설정 가능

bool filter 도 거의 동일

      curl '..../{index}/_search' -d '{
          "query": {
              "filtered": {
                  "query": {
                      "match_all": {}
                  },
                  "filter": {
                      "bool" {
                          "must" : [], // 내용
                          "should": [], // 내용
                          "must_not": [] // 내용
                      }
                  }
              }
          },
      }'

4.4 매치와 필터 쿼리를 넘어서서

4.4.1 범위 쿼리와 필터

2012년 6월 1일 ~ 8월 1일 범위 쿼리 예제

      curl '..../{index}/_search' -d '{
          "query": {
              "range": {
                  "created_on": {
                      "gt": "2012-06-01",
                      "lt": "2012-09-01"
                  }
              }
          },
      }'

필터도 비슷하다.
범위쿼리는 문자열도 지원한다.
범위 쿼리를 만드는 데 99% 경우 필터가 옳은 선택이다.

4.4.2 프리픽스 쿼리와 필터

“query” 에 “prefix”

4.4.3 와일드카드 쿼리

e.g.)

      "query": {
          "wildcard": {
              "title": {
                  "wildcard": "ba*n"
              }
          }
      },

결코 가볍지 않다. 더 많은 작업이 필요하다.

4.5 존재하는 필드에 필터로 쿼리

4.5.1 Exists 필터

특정 필드에 값을 가지는 도큐먼트

location.geolocation 필드를 가진 도큐먼트만 반환하는 예제

      curl '..../{index}/_search' -d '{
          "query": {
              "filtered": {
                  "query": {
                      "match_all": {}
                  },
                  "filter": {
                      "exists" {
                          "filed": "location.geolocation"
                      }
                  }
              }
          },
      }'

4.5.2 Missing 필터

특정 필드에 값이 없는 도큐먼트

reviews 필드가 없는 도큐먼트 검색하는 예제

      curl '..../{index}/_search' -d '{
          "query": {
              "filtered": {
                  "query": {
                      "match_all": {}
                  },
                  "filter": {
                      "missing" {
                          "filed": "reviews",
                          "existence": false,
                          "null_value": true
                      }
                  }
              }
          },
      }'

null_value 는 해당 필드가 null 이라도 일치한다는 것인데, existence 는 확실하지가 않다.

4.5.3 쿼리를 필터로 변환

ES 는 어떤 쿼리도 필터로 전환하여 사용 할 수 있다.
캐시 쿼리
- “query” 부분은 “fquery” 내부로 이동하고, “query”와 같은 레벨로 “_cache” 옵션
- “_cache”: true
표 4.3

4.7 요약

필터는 점수 계산을 하지 않고 캐시로 쿼리 성능을 올릴 수 있다.

9장 스케일아웃

현재 필요한 지식은 score 와 관련없는 equal 검색 뿐이므로, 5,6,7,8 장을 skip. (사실 6장은 읽긴했는데 필요한 지식 X)

9.1 일래스틱서치 클러스터에 노드 추가하기

더 많은 처리량을 갖게 되기를 원할 때 가장 쉽게 향상시킬 수 있는 방법
클러스트에 노드를 추가하여 수평적으로 확장
- bin/elasticsearch
health check
- GET /_cluster/health?pretty
status
- green : 모든 샤드가 정상, 읽기/쓰기 정상
- yellow : 일부 or 모두의 replica 샤드가 비정상, 읽기/쓰기 정상이나 primary 샤드에 문제가 생기면 데이터 유실 가능성이 있다.
- red : 일부 or 모두의 primary 샤드 비정상, 읽기/쓰기 불가
```
  curl -XGET localhost:9200/_cat/indices?v // primary 당 replica 몇 개 존재하는 지 확인 가능
  curl -XGET localhost:9200/_cat/shards?v // 샤드의 상태 체크
```
노드가 추가되면, ES는 자동으로 모든 노드에 걸쳐서 샤드들을 균등하게 배분하고자 한다.
- 같은 샤드의 primary 와 replica 는 한 노드에 함께 있을 수 없다.

9.2 다른 일래스틱서치 노드 발견하기

추가한 두 번째 노드가 어떻게 첫 번째 노드를 발견하고 자동으로 클러스터에 조인했을까?

9.2.1 멀티캐스트 디스커버리

default
멀티캐스트로 핑을 보내고 같은 클러스터 이름을 가진 다른 ES 노드로부터 응답을 받게 된다.
- elasticsearch.yml 파일의 cluster.name 기본값을 특정한 이름으로 바꿔야 할 듯.

9.2.2 유니캐스트 디스커버리

네트워크 전체와 통신하기보다 지정된 노드 목록에 연결
의도하지 않은 다른 노드들이 클러스터에 연결되는 상황을 방지
다른 노드의 IP 주소와 포트를 지정한다
- elasticsearch.yml 파일에 discovery.zen.ping.unicast.hosts: [””, “”]

9.2.3 마스터 선출 및 장애 감지

노드들이 직접 마스터를 선출함
node.master 값이 false 가 아닌 모든 노드들이 후보
minimum_master_nodes 는 클러스터에 있는 노드 중 얼마나 많은 노드가 마스터가 될 자격이 있는지
- 마스터의 개수가 아닌 마스터 후보 개수
- (전체클러스터 노드 수 / 2) + 1 개로 하는걸 권장함 (1 보다 큰 값이어야 스플릿 브레인을 방지할 수 있다고 하는데 잘 모르겠음)
GET /_cluster/state/master_node,nodes?pretty

9.2.4 장애 감지

discovery.zen.fd.ping_interval(defualt 1s) 마다 핑을 보내고, discovery.zen.fd.ping_timeout(default 30s) 만큼 대기. 그리고 최대 discovery.zen.fd.ping_retries(default 3회) 만큼 재시도 후 노드가 연결이 끊어졌다고 판단
- 필요에 따라 샤드 이동 or 마스터 선출 진행

9.3 클러스터에서 노드 제거하기

노드 해체, 해체된 노드에 있는 모든 샤드를 클러스터 내의 다른 노드로 이동시킨다.

  PUT /_cluster/settings -d ' {
      "transient": {
          "cluster.routing.allocation.exclude._ip": "{ip}"
      }
  }

노드 조회

  GET /_nodes?pretty // 노드 목록 조회

  GET /_cluster/state/routing_table,routing_nodes?pretty // 필터링된 클러스터 상태 조회

9.4 일래스틱서치 노드 업그레이드

9.4.1 롤링 리스타트

무중단 업그레이드
한 번에 하나씩 노드를 정지
레플리카가 있어야 한다.

1. 클러스터의 allocation을 비활성화
PUT '/_cluster/settings' -d '{
    "transient": {
        "cluster.routing.allocation.enable": "none"
    }
}

2. 업그레이드할 노드를 정지
3. 노드 업그레이드
4. 업그레이드된 노드 구동
5. 업그레이드된 노드가 클러스터에 추가되기를 기다림
6. 클러스터의 allocation 활성화
PUT '/_cluster/settings' -d '{
    "transient": {
        "cluster.routing.allocation.enable": "all"
    }
}
7. 클러스터 그린상태

9.5 _cat API

_cat API 목록 확인
```
  GET /_cat
```

9.6 스케일링 전략

9.6.1 오버 샤딩

노드의 수는 주 샤드의 숫자를 넘지 않아야 효과가 있음
- 주 샤드가 1개씩 다 분배되고 나면 남은 노드에는 샤드가 분배될 수 없으므로.
그래서 미리 샤드의 수를 5개, 11개 이런식으로 노드보다 많이 가져가는 걸 오버샤딩이라고 함

9.7 앨리어스

하나 이상의 실제 인덱스를 지칭하기 위해 사용할 수 있는 포인터
뷰와같은 개념이나 파티셔닝 같은 개념으로 활용 가능

앨리어스에 인덱스 추가 / 삭제

  POST /_aliases -d ' {
      "actions": [
          {
              "add": { // 앨리어스에 인덱스 추가
                  "index": "get-together",
                  "alias": "gt-alias"
              }
          },
          {
              "remove": { // 앨리어스에 인덱스 삭제
                  "index": "old-get-together",
                  "alias": "gt-alias"
              }
          }
      ]
  }

앨리어스 생성
```
  PUT /{index}/_alias/{alias}
```
{index} 에는 쉼표로 구분된 인덱스 목록이나 패턴 _all 등이 가능
앨리어스 삭제는 DELETE 메소드로 변경만 하면됨

9.8 라우팅

커스텀하게 라우팅을 한다면, 쿼리에 라우팅 값을 지정하여 요청이 인덱스의 특정 샤드들에 대해서만 수행되도록 할 수 있음

도서 - Elasticsearch in action (1~3)

Wed, 05 Aug 2020 00:00:00 +0000

Elasticsearch in action (~ 138p)

1장 일래스틱서치 소개

일래스틱서치는 오픈소스 검색 라이브러리 아파치 루씬을 기반으로 만들었다.
- 루씬은 자바 애플리케이션에 검색 기능을 구현할 수 있게 해준다.
- 루씬은 역 색인(inverted indexing)을 사용한다.
일래스틱서치 클러스터를 색인, 검색, 관리하기 위해 데이터를 JSON 형태로 HTTP를 통해 전달할 수 있다.

rawdata

ID	태그
1	투표
2	평화
3	투표, 평화
4	평화

색인 데이터

태그 ID

투표 1, 3

평화 2, 3, 4

태그	ID
투표	1, 3
평화	2, 3, 4

완전 일치를 뛰어넘어 검색하기

오타 처리
파생어 지원
통계 사용
제안 제공

일래스틱서치 사용사례

기본값으로 클러스터링 할 수 있어서 하나의 서버에서 실행할 때도 클러스터라고 부른다.

일래스틱서치에서 데이터 구조화하기

일래스틱서치에서는 문서가 계층적일 수 있다.

2장 기능 들여다보기

논리적인 배치 이해하기: 문서, 타입, 색인

문서의 색인을 만들 때 색인 안의 타입에 문서를 넣는다.
- 색인 엄청 어색하다 인덱스가 번역되어 버려서..
색인-타입-ID 조합은 ES 에서 하나의 문서를 유일하게 식별한다.
- 검색할 때 특정 색인의 특정 타입에서 문서를 찾거나, 여러 타입 혹은 여러 색인에 걸쳐 검색할 수 있다.
ES가 문서 기반이라고 했는데, 색인과 검색하는 데이터의 가장 작은 단위가 문서라는 것을 의미한다.

문서

독립적이다. 문서는 필드(name)와 값(ES Denver)을 가지고 있다.
계층을 가질 수 있다. (문서 안의 문서)
유연한 구조로 되어 있다. 즉 미리 정의한 스키마에 의존하지 않는다.
문서는 보통 JSON 표현
필드를 추가하거나 생략할 수 있지만, 필드의 타입은 중요하다.

타입

문서에 대한 논리적인 컨테이너
각 타입에서 필드의 정의는 매핑이라고 부른다.
새로운 문서가 매핑에 존재하지 않는 필드와 함께 색인하면, ES는 자동으로 새로운 필드를 매핑에 추가한다.
- 필드를 추가하기 위해 타입을 추측한다.
- 원하는 타입으로 동작하지 않을 수 있다.
- 데이터의 색인을 만들기 전에 매핑을 정의하는 것이 안전하다.

색인

색인은 매핑 타입의 컨테이너다.
색인은 독립적인 문서 덩어리다.
각각의 색인은 디스크에 같은 파일 집합으로 저장한다.
모든 매핑 타입의 모든 필드를 저장하고 고유의 설정을 한다.
각 색인은 refresh_interval 이라는 설정으로 새로 색인한 문서를 검색할 수 있도록 하는 간격을 정의한다. (기본값은 1초에 한번)
- 준 실시간 (near-real-time)

물리적 배치 이해하기: 노드와 샤드

예) 각 색인은 다섯 개의 주 샤드로 구성되고, 각각은 하나의 복제를 가지고 있어서 총 10개의 샤드 가지게 됨
기술적으로 샤드는 루씬이 여러분의 색인에 대한 데이터를 저장하는 파일들의 디렉토리
샤드는 또한 ES가 노드에서 노드로 옮기는 가장 작은 단위이다.
노드가 충분히 빨라 서로 간에 통신을 할 수 있도록 보장해야한다.
- 스플릿 브레인(split brain) 을 방지하기 위해.
  - 클러스터의 두 파트가 통신할 수 없어 다른 파트가 떨어져 나갔다고 생각하는 것.

문서의 색인을 만들 때 무슨 일이 일어나는가?

우선 문서 ID의 해시값에 기반을 둬서 선택한 주 샤드 중 하나에 보낸다.
그 다음 문서는 주 샤드의 모든 복제에 색인하도록 보내진다.
- 복제가 주 샤드로부터 데이터 동기화 유지
- 동기된 복제는 검색을 제공하고, 주 샤드가 이용 불가한 경우 주 샤드로 자동 승격될 수 있다.

색인을 검색할 때 무슨일이 일어나는가?

색인 검색 시, ES는 해당 색인의 전체 샤드를 찾아야 한다.
검색하는 색인의 주 샤드와 레플리카 샤드 간에 검색 로드를 분배해서, 검색 성능과 고장 감내(fault tolerance)에 유용하게 레플리카를 사용

주 샤드와 레플리카 샤드 이해하기

하나의 샤드는 하나의 루씬 색인이다.
루씬 색인은 역 색인을 포함하는 파일들의 모음이다.
- 역 색인은 ES가 전체 문서를 찾지 않고도, 하나의 텀(단어)을 포함하는 문서를 찾도록 해주는 구조
- 기본 값으로 원문서의 내용과 검색하는 데 도움을 주는 단어사전과 단어 빈도 같은 추가 정보를 저장한다.
ES 색인은 하나 이상의 주 샤드와 0개 이상의 레플리카 샤드로 구성된다.
레플리카는 실행 시간에 추가나 삭제할 수 있지만 주 샤드는 그렇지 않다.
- 색인을 생성하기 전에 샤드의 수를 결정해야 한다.
- 너무 적은 샤드는 확장에 제한하고, 너무 많은 샤드는 성능에 영향을 준다.
검색요청은 전체 데이터를 포함한 주/레플리카 샤드에 전달된다. 그 후에 결과를 집계하여 클라이언트에게 보낸다.

실습

Windows 에서 안되던게 Mac 으로 뚝딱 된다. Mac 짱짱
- install
```
  brew install elasticsearch
```
- run
```
  elasticsearch
```
- get-together index 의 group type 문서를 올려보기
```
  curl -X PUT 'localhost:9200/get-together/group/1?pretty' \
      -H 'Content-Type: application/json;charset=UTF-8' \
      -d ' {
          "name": "Elasticsearch Denver",
          "organizer": "Lee"
          }'
```
- new-index 인덱스 생성해보기
```
  curl -H 'Content-Type: application/json;charset=UTF-8' \
      -X PUT 'localhost:9200/new-index'
```
- https://github.com/dakrone/elasticsearch-in-action -> clone -> ./populate.sh
  - 문제가 있네, es 버전이 달라서 신 버전부터는 String type 이 없어지고 text/keyword 타입으로 나누어졌고
  - curl 요청 시 header 를 더 명확히 전달해야해서 sh 파일이 정상적으로 동작하지 않음
- 데이터 검색 시 쿼리는 q=name:elasticsearch 처럼 특정 필드에 수행하지만, 모든 필드 검색을 원하는 경우 명시하지 않아도 된다.
  - 이럴 경우 _all이라는 특정필드를 사용한다
- 타입을 지정할 수도 있다. 아래에선 group과 event type 만 검색하겠다는 것
```
  curl "localhost:9200/get-together/group,event/_search?q=elasticsearch&pretty"
```
- 모든 인덱스에서 검색하려면 색인명을 생략하는 것도 가능하다.
- 검색 응답은 검색 기준 일치하는 문서 뿐 아니라, 검색 성능이나 결과의 유사도를 확인하는 데 유용한 정보를 포함한다.
```
  {
      "took" : 2          
      "timed_out": false
      // 요청이 얼마나 걸리고 타임아웃 발생여부
            
      "_shards" : {
          "total" : 2,
          "successful" : 2,
          "failed" 0
      }
      // 몇 개의 샤드에 질의했는지

      "hit" : {
          "total" : 2  // 일치하는 문서 수
          "max_score" : 0.9066504, // 일치하는 문서의 최대 점수
          // 일치하는 모든 문서에 대한 통계

          "hits" : { ... // 결과배열
      }
  }
```
- 전체 문서 수는 응답에서 보는 문서 수와 일치하지 않을 수도 있다. (결과 수가 10으로 limit 걸려있어서)
- hits 는 응답에서 보통 가장 관심있는 정보
```
  "hits" : [ {
      "_index" : "get-together",
      "_type" : "group",
      "_id" : "3",
      "_score" : 0.9066504,
      "fields" : {
          "location" : ["San Francisco, California, "USA"],
          "name" : ["Elasticsearch San Francisco"]
      }
  }]
```
  - 어떤 필드를 원하는지 명시하지 않으면 _source 필드가 보인다
- 적절한 쿼리타입 선택
  - 다양한 다른 형태의 쿼리가 존재한다.
  - 쿼리는 결과를 돌려주고 각 결과는 점수가 있다.
  - 점수에 관심이 없다면, 필터 쿼리를 대신 실행할 수 있다.
    - 오직 결과가 검색과 일치하는지만 관심
  - 텀 쿼리
    - 명시한 필드에 나타난 텀별 수치를 보여준다.
      "aggregations" : { "organizers" : { "terms" : { "field" : "organizer" } } }
    - terms 타입 요청, organizer 필드를 찾는 organizers 라고 명명된 집계를 주세요.

es 설정하기

elasticsearch.yml
- 일래스틱 특유의 옵션이 들어가는 주 설정 파일
  - 클러스터 이름 명시 등..
logging.yml
- 로깅 옵션 수정
elasticsearch.in.sh
- es 를 작동시키는 jvm 설정
  - 메모리 설정 조정 등
es 로그 엔트리는 세 가지 파일 형태로 구성된다.
- 메인 로그(cluster-name.log)
- 느린 검색 로그(cluster-name_index_search_slowlog.log)
  - 기본 설정은 0.5초 이상
- 느린 색인 로그(cluster-name_index_indexing_slowlog.log)
  - 색인 작업이 0.5초 이상

클래스터에 노드 추가하기

/_cat/shards?v
- like inux top

3장 데이터 색인, 변경, 삭제

필드
- _timestamp 처럼 새 데이터를 자동으로 도큐먼트에 추가하도록 설정하거나, _ttl 필드를 사용하여 지정된 시간 이후 자동삭제하게끔 할 수 있음
도큐면트 변경 시 동시성 문제 관련된 것을 살펴볼 것이다.

도큐먼트 종류를 정의하는 매핑 사용하기

색인은 타입을 포함하고, 타입은 개별 다큐먼트를 포함한다.
다른 다큐먼트라도 같은 필드를 갖는다면 타입이 같은게 좋다.
GET /_mapping 을 활용하여 타입의 매핑을 확인할 수 있다.
PUT /_mapping 을 활용하여 타입의 매핑을 설정할 수 있다.
이미 존재하는 필드 데이터 타입은 변경할 수 없다.
- 타입의 데이터를 모두 삭제하고, 새 매핑을 입력한 후 데이터 전체를 다시 색인하게 할 수도 있다.

기본 타입

문자열, 숫자, 날짜, 불린
```
  PUT /get-together/new-events/1 -d {
      "name": "Late Night with Elasticsearch"
      "date": "2013-10-25T19:00"
  }
```
- “Late Night with Elasticsearch” 색인 시, 기본 분석기는 모든 문자를 소문자로 만들고 문자열을 단어 단위로 분할한다.
- late, night, with, elasticsearch 4가지 텀을 만들어낸다.
  - 텀은 text로 부터 나온 단어이고, 검색을 위한 기본 단위
매핑에서 분석을 위한 다수의 옵션을 지정할 수 있다.
- 예를 들어, 원본 텀의 동의어 텀을 만들어내는 분석도 설정할 수 있다.
```
  PUT /get-together/_mapping/new-events -d {
  ...
  "name": {
      "type: "string",
      "index": "not_analyzed"
  }
  }
```
- index 기본 값은 analyzed 인데 이렇게하면 전체 문자를 단일 텀으로 인식하는 것.
- index 를 no 로 설정하면 검색이 아예 안됨
  - 검색이 필요없는 필드에 이렇게 설정하면 되겠지?
날짜 타입은 long 숫자로 루씬 색인에 저장함
- UTC 1970 1 1 00:00:00 부터 지정시간까지 ms 숫자로 저장함

문자열을 위한 다중 필드

  PUT /blog/_mapping/posts -d {
      "properties": {
          "tags": {
              "type": "string",
              "index": "analyzed",
              "fields": {             // 두번째 필드 정의
                  "verbatim": {
                      "type": "string",
                      "index": "not_analyzed"
                  }
              }
          }
      }
  }

사전 정의 필드

특수 기능을 갖고있다.
- e.g. _ttl 필드는 특정 시간 이후에 도큐먼트 자동 삭제 기능
필드 이름이 모두 언더스코어(_)로 시작한다.
_source 는 모든것을 저장하고 _all 는 모든것을 색인한다.
_uid 를 내부적으로 사용하고 다른구조로 사용하기 쉽도록 _type과 _id라는 추상적인 개념으로 분리하여 제공한다.

기존 도큐먼트 변경하기

조회 - 처리 - 재색인을 수반한다.
존재하지 않는 도큐먼트를 생성할 때는 upsert
동시에 다수 변경을 실행한다면 동시성 문제가 발생할 수 있다.

데이터 삭제하기

삭제 방법
- 개별 도큐먼트 또는 도큐먼트 그룹 삭제
- 완성된 색인 삭제
- 색인 닫기
  - 실제 삭제는 아닌 것 같고
  - 읽기 쓰기 작업 불허, 메모리 Load X
  - 삭제한 것과 다름이 없지만 디스크에는 남아있어 닫은 색인을 열기만 하면 복구가 된다는 장점

도서 - 클린코드 2 (작성중)

Sun, 19 Jul 2020 00:00:00 +0000

클린코드 (~ 245p)

동시성

객체는 처리의 추상화다. 스레드는 일정의 추상화다.

동시성은 결합을 없애는 전략
- 무엇(What)과 언제(When)를 분리하는 전략
동시성에 대한 일반적인 오해
1. 동시성은 항상 성능을 높여준다.
  - 동시성은 때로 성능을 높여준다.
  - 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나
  - 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우
2. 동시성을 구현해도 설계는 변하지 않는다.
  - 단일 스레드 시스템과 다중 스레드 시스템 설계는 판이하게 다르다.
동시성에 대한 타당한 생각
1. 동시성은 다소 부하를 유발한다.
2. 동시성은 복잡하다.
3. 일반적으로 동시성 버그는 재현하기 어렵다.
4. 동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다.
동시성 방어 원칙
1. SRP
  - 동시성 관련 코드는 다른 코드와 분리해야 한다.
  - 1-1. 자료 범위를 제한하라
    - 임계영역을 활용
    - 공유 자원을 최대한 줄여라
    - 자료를 캡슐화 하라
  - 1-2. 자료 사본을 이용하라
    - 공유 자원을 줄이려면 처음부터 공유하지 않는 방법이 제일 좋다.
    - 복사하여 읽기 전용으로 사용 가능
  - 1-3. 스레드는 가능한 독립적으로 구현하라
    - 다른 스레드와 자료를 공유하지 않는다.
    - 각 스레드는 클라이언트 요청 하나를 처리할 뿐, 비공유 출처에서 가져오며 로컬 변수를 활용.
    - 독립적으로 돌려도 괜찮도록 자료를 독립적인 단위로 분할하라.
2. 라이브러리를 이해하라
  - 스레드 세이프 한 컬렉션을 사용하라.
  - 일부 클래스 라이브러리는 스레드 세이프 하지 않다.
  - java.util.concurrent 패키지가 제공하는 클래스는 다중 스레드 환경에서 사용해도 안전하며, 성능도 좋다.
  - 실제로 ConcurrentHashMap 은 거의 모든 상황에서 HashMap 보다 빠르다고 한다. (정말?)
3. 실행 모델을 이해하라
  - Bound Resource(한정된 자원) : 다중 스레드 환경에서 사용하는 자원으로, 크기나 숫자가 제한적이다. DB 연결, 길이가 일정한 read/write buffere…
  - Mutual Exclusion(상호 배제) : 한 번에 한 스레드만 공유 자료/자원 을 사용할 수 있는 경우
  - Stravation(기아) : 오랫동안 혹은 영원히 자원을 기다린다.
  - Deadlock(데드락) : 여러 스레드가 서로가 끝나기를 기다린다.
  - Livelock(라이브락) : 락을 거는 단계에서 각 스레드가 서로를 방해한다. 스레드는 계속해서 진행하려 하지만, 굉장히 오랫동안 혹은 영원히 진행하지 못한다.
  - 생산자-소비자
    - 생산자는 대기열에 빈 공간이 있을 때 정보를 채우고, 소비자는 대기열에 정보가 있어야 가져온다.
    - 생산자와 소비자는 서로에게 시그널을 보낸다.
      - 생산자는 대기열에 정보를 채운 다음 “대기열에 정보가 있다.”
      - 소비자는 정보를 읽어들인 후 “대기열에 빈 공간이 있다.”
      - 잘못하면 생산자 스레드와 소비자 스레드가 둘 다 진행 가능함에도 불구하고 동시에 서로에게서 시그널을 기다릴 가능성이 존재한다.
  - 읽기-쓰기
    - 읽기 스레드를 위한 주된 정보원 공유 자원을 쓰기 스레드가 이따금 갱신한다고 하자.
    - 간단한 방법, 읽기 스레드가 요청이 없을 때 까지 쓰기 스레드가 기다린다.
      - 읽기 스레드가 계속 이어진다면 쓰기 스레드가 기아 상태에 빠진다.
    - 반면, 쓰기 스레드에게 우선권을 준 상태에서 쓰기 스레드가 계속 이어진다면 처리율이 떨어진다.
    - 양 쪽 균형을 잡으면서 동시 갱신 문제를 피하는 해법이 필요하다.
  - 식사하는 철학자들
    - 둥근 식탁에 철학자 한 무리가 둘러앉아 있고, 각 철학자 왼쪽에는 포크가 놓여있다. 식탁 가운데는 커다란 스파게티 한 접시가 놓여있다.
    - 철학자들은 배가 고프지 않으면 생각하며 시간을 보낸다.
    - 배가 고프면 양손에 포크를 집어들고 스파게티를 먹는다. (양손에 포크를 쥐지 않으면 먹지 못한다.) 먹고 나면 포크를 내려놓고 배가 고플 때까지 생각에 잠긴다.
    - 왼쪽 철학자나 오른쪽 철학자가 포크를 사용중이라면 포크를 내려놓을 때 까지 기다려야 먹을 수 있다.
    - 철학자를 스레드로, 포크를 자원으로 바꿔 생각하면 멀티스레드 문제이다.
4. 동기화하는 메서드 사이에 존재하는 의존성을 이해하라
  - 공유 객체 하나에는 메서드 하나만 사용하라.
  - 공유 객체 하나에 여러 메서드가 필요한 상황일 경우 아래 세 가지 방법을 고려한다,
    1. 클라이언트에서 잠금
      - 클라이언트에서 첫 번째 메서드를 호출하기 전에 서버를 잠근다. 마지막 메서드를 호출할 때까지 잠금을 유지한다.
    2. 서버에서 잠금
      - 서버에다 “서버를 잠그고 모든 메서드를 호출한 후 잠금을 해제하는” 메서드를 구현한다. 클라이언트는 이 메서드를 호출한다.
    3. 연결(Adapted) 서버
      - 잠금을 수행하는 중간 단계를 생성한다. 서버에서 잠금 방식과 유사하지만 원래 서버는 변경하지 않는다.
5. 동기화하는 부분을 작게 만들어라
  - 자바에서 synchronized 키워드를 사용하면 락을 설정한다. 같은 락으로 감싼 모든 코드 영역은 한 번에 한 스레드만 실행이 가능하다.
  - 락은 스레드를 지연시키고 부하를 가중시킨다.
  - 따라서 synchronized 문을 남발하는 코드는 바람직하지 않다.
  - 하지만 임계영역은 반드시 보호해야 한다.
  - 결국 임계영역 수를 최대한 줄여야 한다.
6. 올바른 종료 코드는 구현하기 어렵다
  - 영구적으로 돌아가는 시스템을 구현하는 방법과 잠시 돌다 깔끔하게 종료하는 시스템을 구현하는 방법은 다르다.
  - 깔끔하게 종료하는 코드는 올바로 구현하기 어렵다. 가장 흔히 발생하는 문제가 데드락 이다. 스레드가 절대 오지 않을 시그널을 기다린다.
  - 종료 코드를 개발 초기부터 고민하고 동작하게 초기부터 구현하라.
  - 생각보다 어려우므로 이미 나온 알고리즘을 검토하라.
7. 스레드 코드 테스트하기
  - 테스트가 정확성을 완전히 보장하지는 않는다.
  - 그럼에도 충분한 테스트는 위험을 낮춘다.
    1. 말이 안되는 실패는 잠정적인 스레드 문제로 취급하라
      - 하지만 시스템 실패를 일회성이라 치부하지는 마라.
    2. 다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자
      - 스레드 환경 밖에서 생기는 버그와 스레드 환경에서 생기는 버그를 동시에 디버깅하지 마라.
      - 먼저 스레드 환경 밖에서 코드를 올바로 돌려라.
    3. 다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있게 쓰레드 코드를 구현하라
      - 다중 스레드를 쓰는 코드를 다양한 설정으로 실행하기 쉽게 구현하라.
    4. 다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있게 작성하라
      - 적절한 스레드 개수를 파악하려면 상당한 시행착오가 필요하다.
      - 다양한 설정으로 프로그램의 성능 측정 방법을 강구한다.
    5. 프로세서 수보다 많은 스레드를 돌려보라
    6. 다른 플랫폼에서 돌려보라
    7. 코드에 보조 코드를 넣어 돌려라. 강제로 실패를 일으키게 해보라
다중 스레드 코드는 올바로 구현하기 어렵다. 간단했던 코드가 여러 스레드와 공유 자료를 추가하면서 악몽으로 변한다. 각별히 깨끗하게 코드를 짜야 한다.