자바 웹프로그래밍 2기 강의 12일차 내용을 정리한 포스팅입니다.

리펙토링

하나의 메소드에서 개발자가 해야하는 부분과 고정된 부분을 분리해보자

// insert method

그렇게 하나의 메소드에서 공통된 부분이 남으면 클래스로 분리해보자

// JdbcTemplate.class

상속을 통해서 클래스간의 종속된 관계를 끊을 수 있는지 찾아보자

추상클래스 / 추상메소드 / 인터페이스를 활용 할 수 있다.

abstract class JdecTemplate {

  abstract void setValues();
  abstract String createQuery();

  ...

}

익명 클래스 활용 (흐름이 어떻게 가는지 좀 정리하자)

상속이 아닌 메소드의 인자로 달라질 수 있는 부분을 정리해보자

가변인자 사용도 고려해보자

클래스간의 중복제거

상속을 통한 중복 제거
- 하위 클래스의 영향을 준다.
구성 (조합) composition
- 추천!
- 메소드간의 커플링을 분리
  - interface 만들어서 분리 가능하다.
  - 인터페이스의 메소드의 인자로 넘긴다. (callback interface)

AutoCloseable 을 상속한 클래스는 try문에서 다 클로즈

Singleton

상태값을 가지지 않고 행위만 가지고 있는 클래스는 Singleton 패턴을 이용하자

public class JdbcTemplate {
    private static JdbcTemplate jdbcTemplate;
    private JdbcTemplate() {
      // 생성자를 private으로 막는다.
    }

    public static JdbcTemplate getInstance() {
      if (jdbcTemplate == null) {
        // 더블 체크드 락킹
        jdbcTemplate = new JdbcTemplate();
      }
      return jdbcTemplate;
    }
}

// 호출 전에도 생성되어 있으나 그래도 깔끔하고 안전하다
public class JdbcTemplate {
 private static JdbcTemplate jdbcTemplate = new JdbcTemplate();

 private JdbcTemplate() {}

 public static JdbcTemplate getInstance() {
   return jdbcTemplate;
 }
}

Singleton, static

static 기반의 단점
- 다형성에 한계가 있다.
- 테스트하기가 번거롭다.

레이어드 아키텍쳐

하나의 기능 추가에 너무 많은 클래스가 필요하다

Service의 역할은? (비지니스 로직을 담는게 서비스가 아니다!!!!)

Controller의 중복 코드를 제거할 수 있다.
다른 기능의 Service를 호출하거나 다수의 DAO를 연결하는 역할을 한다.
Transaction과 Cache 적용과 같은 infra 적용을 위한 단위가 된다.
Service는 가능한 가볍게 구현한다.(thin layer)
Service에 핵심 비즈니스 로직을 구현하지 말고, 로직은 상태 값을 가지고 있는 모델(또는 도메인)이 담당해야 한다.

Model(Domain), DTO, VO

DTO : 바뀔수 있다 (setter 가짐)
VO (immutable object)

Service Layer의 interface를 없애는 추세

인터페이스와 클래스가 1:1 매핑 -> 의미가 없다.
인터페이스는 구현체의 변경이 필요할 경우에 사용하면 된다. (사실 구현체가 변경될 일은 많지 않다.)

스프링 프레임워크

스프링 컨테이너 / DI 컨테이너 / Bean 컨테이너

Bean의 라이프 사이클을 관리! (Bean Container)
각각의 Bean의 의존관계 관리!!
- @Autowired : 서로 연관없는 Bean을 연결해주는 어노테이션
POJO : 순수 자바 오브젝트 (특정 인터페이스에 종속되지 않은)
@EnableWebMVC :