1122 - 1128

1122 - toString을 항상 재정의하라

toString()

Object의 기본 toString메서드는 우리가 작성한 클래스에 적합한 문자열을 반환하는 경우는 거의 없다. 이 메서드는 클래스_이름@16진수로_표현한_해시코드를 반환한다.

toString()을 재정의 해야 하는 이유

equals와 hashCode 규약 만큼 대단히 중요하진 않지만, toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다. toString 메서드는 객체를 println, printf, 문자열 연결 연산자(+), assert 구문에 넘길 때, 혹은 디버거가 객체를 출력할 때 자동으로 불린다. 여러분이 직접 호출하지 않더라도 다른 어딘가에서 쓰인다. 예를들어 객체를 참조하는 컴포넌트가 오류 페이지를 로딩할 때 자동으로 호출 될 수 있다. 이때 toString을 제대로 재정의하지 않는다면 쓸모없는 메시지만 로그에 남는다.

toString 재정의시 주의 사항

• 실전에서 toString은 그 객체가 가진 주요 정보를 모두 반환하는게 좋다.
  • 하지만 객체가 거대하거나 객체의 상태의 문자열로 표현하기 어렵다면, 요약 정보를 담아야한다.
• toString을 구현할 때면 반환값의 포맷을 문서화할지 정해야 한다.
  • 포맷을 명시하면 그 객체는 표준적이고, 명확하고, 사람이 읽을 수 있게 된다.
  • 다만, 포맷을 한번 명시하면 얽매이게 된다.
• 포맷을 명시하든 아니든 의도는 명확히 밝혀야 한다.

/** * 이 약물에 관한 대략적인 설명을 반환한다. * 다음은 이 설명의 일반적인 형태이나, * 상세 형식은 정해지지 않았으며 향후 변경될 수 있다. * * "[약물 #9: 유형=사랑, 냄새=테레빈유, 겉모습=먹물]" */ @Override public String toString() { ... }

• 정적 유틸리티 클래스는 toString을 제공할 이유가 없고, 대부분의 결거 타입도 자바가 이미 완벽한 toString을 제공하니 따로 재정의하지 않아도 된다.
  • 하지만, 하위 클래스들이 공유해야 할 문자열 표현이 있는 추상 클래스라면 toString을 재정의 해줘야 하며, 대다수 컬렉션 구현체는 추상 컬렉션 클래스들의 toStirng메서드를 상속해서 사용한다.

1123 - CrudRepository vs JpaRepository

위 상속관계를 살펴보면, 최상위 부모인 Repository를 CrudRepository가 상속받아 확장시키고, 이를 PagingAndSortingRepository가, 그리고 이를 또 JpaRepository가 상속받아 확장시킨 것을 볼 수 있다.

각각 소스코드를 IDE를 통해 상세히 살펴볼 수 있지만, 구조상으로 JpaRepository의 구현체들이 당연히 더 많다. 사용하고자 하는 도메인이 어느 정도의 수준까지 필요한가에 따라 사용.

• CrudRepository : CRUD 관련 기능을 제공. (간단한 CRUD만 필요한 경우)
• PagingAndSortingRepository : 페이징과 솔팅을 추가로 제공.
• JpaRepository : 위 기능은 물론 JPA 관련 특화된 기능(지속성 컨텍스트 플러시 및 배치에서 레코드 삭제)들을 제공.

1124 - Maven 다중모듈, 의존성

Maven환경 다중 모듈 프로젝트 생성

1. parent 프로젝트 생성
   • Maven Project로 생성
   • packaging : pom
2. 'Parent'의 pom을 상속받는 프로젝트 생성
   • Maven Module로 생성
   • Parent 를 1에서 정의한 프로젝트로 설정

=> 하위 프로젝트는 parent에서 정의한 pom.xml(dependency, repository 등등..) 을 그대로 사용할 수 있다.

다중 모듈간 클래스 사용

• 별다른 설정 필요 없이, 둘다 Maven 프로젝트이며 같은 Workspace안에 있을 경우 Dependency로 추가

<dependency> 
    <groupId>com.mypjt</groupId> 
    <artifactId>myProjectA</artifactId> 
    <version>0.0.1-SNAPSHOT</version> 
</dependency>

1125 - Spring Bean LifeCycle(스프링 빈 생명주기)

빈 생명주기 콜백

데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다.

스프링 빈도 위와 같은 원리로 초기화 작업과 종료 작업이 나눠서 진행된다.
간단하게 말하면 객체 생성 -> 의존관계 주입이라는 라이프사이클을 가진다.

즉, 스프링 빈은 의존관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료된다.

Spring 의존관계 주입 과정

• 가장 처음에는 Spring IoC 컨테이너가 먼저 만들어지는 과정이 일어난다.
  • Component-Scan으로 Bean을 등록한다.
  • @Configuration, @Controller, @Service 등등 Bean으로 등록할 수 있는 어노테이션들과 설정파일들을 읽어 IoC 컨테이너 안에 Bean으로 등록한다.
• 의존 관계를 주입하기 전의 준비 단계까 존재하는데, 이 단계에서 객체의 생성이 일어난다.
  • 생성자 주입: 객체의 생성과 의존관계 주입이 동시에 일어난다.
  • setter, Field 주입: 객체의 생성 -> 의존관계 주입으로 라이프 사이클이 나누어진다.

스프링 의존관계 주입이 완료된 시점을 어떻게 알 수 있을까?

Bean으로 등록된 객체들은 의존관계 주입이 완료된 후에 초기화 작업을 진행해야 한다.

• 스프링의 Bean LifeCycle

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸 전 콜백 -> 스프링 종료

스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메소드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공한다. 또한 스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 제공한다.

• 초기화 콜백 : 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출
• 소멸전 콜백 : 빈이 소멸되기 직전에 호출

객체의 생성과 초기화를 분리하자
생성자는 필수 정보를 받고, 메모리를 할당해서 객체를 생성하는 책임을 가진다. 반면에 초기화는 이렇게 생성된 값들을 활용해서 외부 커넥션을 연결하는 등 무거운 동작을 수행한다.
따라서 생성자 안에서 무거운 초기화 작업을 함께 하는 것 보다는 객체를 생성하는 부분과 초기화 하는 부분을 명확하게 나누는 것이 유지보수 관점에서 좋다.

빈 생명주기 콜백 지원 방법

• 인터페이스(InitializaingBean, DisposableBean)
• 설정 정보에 초기화 메소드, 종료 메소드 지정
• @PostConstruct, @PreDestroy 어노테이션 지원

1. 인터페이스(InitializaingBean, DisposableBean)

• 상속을 통한 생명주기 콜백 지원
• InitializaingBean -> afterPropertiesSet 메소드로 초기화 지원
• DisposableBean -> destroy 메소드로 소멸을 지원
• 초기화, 소멸메서드의 이름을 변경 할 수 없다.
• 외부 라이브러리에 적용 할 수 없다.
• 현재 거의 사용하지 않는다.

2. @PostConstruct, @PreDestory 어노테이션

• 최신 스프링에서 가장 권장하는 방법.
• 컴포넌트 스캔과 잘어울림.
• javax.annotation.PostConstruct 패키지로, 스프링 종속 X, 자바 표준

3. 빈 등록 초기화, 소멸 메소드 지정

• 설정 정보에 @Bean(initMethod="init", destroyMethod="close")처럼 초기화, 소멸 메소드를 지정

1127 - Filter, Interceptor, AOP 차이

• 공통 프로세스에 대한 처리
  • 로그인 관련(세션체크)처리, 권한체크, XSS방어, pc와 모바일웹의 분기처리, 로그, 페이지 인코딩 변환 등
• 스프링에서 사용되는 Filter, Interceptor, AOP 세 가지 기능은 모두 무슨 행동을 하기전에 먼저 실행하거나, 실행한 후에 추가적인 행동을 할 때 사용되는 기능Handler들이다.
• 순서

Filter -> Interceptor -> AOP -> Interceptor -> Filter

1. 서버를 실행시켜 서블릿이 올라오는 동안에 init이 실행되고, 그 후 doFilter가 실행된다.
2. 컨트롤러에 들어가기 전 preHandler가 실행된다.
3. 컨트롤러에서 나와 postHandler, after Completion, doFilter 순으로 진행이 된다.
4. 서블릿 종료 시 destroy가 실행된다.

• Filter와 Interceptor는 Servlet 단위에서 이루어진다. 반면 AOP는 메소드 앞에 Proxy패턴의 형태로 실행된다.
• 실행순서를 보면 Filter가 가장 밖에 있고 그안에 Interceptor, 그안에 AOP가 있는 형태이다.

1. Filter(필터)

말 그대로 요청과 응답을 거른뒤 정제하는 역할을 한다.
서블릿 필터는 DispatcherServlet 이전에 실행이 되는데 필터가 동작하도록 지정된 자원의 앞단에서 요청내용을 변경하거나, 여러가지 체크를 수행할 수 있다.
또한 자원의 처리가 끝난 후 응답내용에 대해서도 변경하는 처리를 할 수가 있다.

실행 메서드

• init() - 필터 인스턴스 초기화
• doFilter() - 전/후 처리
• destroy() - 필터 인스턴스 종료

2. Interceptor(인터셉터)

요청에 대한 작업 전/후로 가로챈다.
필터는 스프링 컨텍스트 외부에 존재하여 스프링과 무관한 자원에 대해 동작한다. 하지만 인터셉터는 스프링의 DispatcherServlet이 컨트롤러를 호출하기 전, 후로 끼어들기 때문에 스프링 컨텍스트(Context, 영역) 내부에서 Controller(Handler)에 관한 요청과 응답에 대한 처리를한다.
스프링의 모든 빈 객체에 접근할 수 있다.
인터셉터는 여러 개를 사용할 수 있고 로그인 체크, 권한체크, 프로그램 실행시간 계산작업 로그확인 등의 업무처리

실행 메서드

• preHandler() - 컨트롤러 메서드가 실행되기 전
• postHandler() - 컨트롤러 메서드 실행직 후 view페이지 렌더링 되기 전
• afterCompletion() - view페이지가 렌더링 되고 난 후

3. AOP

OOP를 보완하기 위해 나온 개념
객체지향의 프로그래밍을 했을 때 중복을 줄일 수 없는 부분을 줄이기 위해 종단면(관점)에서 바라보고 처리한다.
주로 로깅, 트랜잭션, 에러처리 등 비지니스단의 메서드에서 조금 더 세밀하게 조정하고 싶을 때 사용한다.

Interceptor나 Filter와 달리 메소드 전후의 지점에 자유롭게 설정이 가능하다. Interceptor와 Filter는 주소로 대상을 구분해서 걸러내야하는 반면, AOP는 주소, 파라미터, 어노테이션 등 다양한 방법으로 대상을 지정할 수 있다.

AOP의 Advice와 HandlerInterceptor의 가장 큰 차이는 파라미터의 차이다. Advice의 경우 JoinPoint나 ProceedingJoinPoint 등을 활용해서 호출한다. 반면 HandlerInterceptor는 Filter와 유사하가 HttpServletRequest, HttpServletResponse를 파라미터로 사용한다.

AOP의 포인트컷

• @Before: 대상 메서드의 수행 전
• @After: 대상 메서드의 수행 후
• @Atter-returning: 대상 메서드의 정상적인 수행 후
• @After-throwing: 예외발생 후
• @Around: 대상 메서드의 수행 전/후