2017년 09월 27일

Code coverage : 소스코드에 대한 유닛 테스트를 작성하고 이 테스트가 소스코드의 어느정도를 테스트하고 있는지를 보여주는 것

2017년 09월 26일

STS 설치 후 동작 시 에러 발생
java 9을 설치했때 문제가 있다
[버그리포트][https://bugs.eclipse.org/bugs/show_bug.cgi?id=516050]
java 8로 다시 설치하니 해결됨

용어정리
PMO(Project Management Office) : 프로젝트 관리 조직

통합WBS(Work Breakdown Structure) :
작업분해도 프로젝트의 범위와 최종산출물을 세부요소로 분할한 계층적 구조

WBS는 전체 업무를 분류하여 구성 요소로 만든 후 각 요소를 평가하고 일정 별로 계획하며 그것을 완수할 수 있는 사람에게 할당해 주는 역할

초난감 예외처리

• catch로만 잡고 어떠한 조치도 하지 않는다.
• catch블록을 이용해 화면에 에러메시지를 출력한 것은 예외를 처리한 게 아니다
• 무의미하고 무책임한 throws

모든 예외는 적절하게 복구 되든지 아니면 작업을 중단시키고 운영자 또는 개발자에게 분명하게 통보해야 한다.

예외의 종류와 특징

• Error : java.lang.Error: 시스템에서 뭔가 비정상적인 상황이 발생했을 경우에 사용된다. 주로 VM에서 발생 시키므로 catch블록으로 잡아봤자 아무런 대응 방법이 없다.
• Exception
  • check Exception : 반드시 예외처리를 해야 한다.
  • unCheck Exception
    • RuntimeException : 필요 할 때만 예외처리를 한다.

예외처리 방법

• 예외 복구 : 예외가 처리 됐으면 비록 기능적으로 사용자에게 예외상황으로 비쳐도 애플리케이션 에서는 정상적으로 설계된 흐름을 따라 진행돼야 한다.
  • 정해진 횟수만큼 재시도 해서 실패했다면 예외 복구는 포기해야 한다.
  • 예외처리 코드를 강제하는 체크 예외들 은 이렇게 예외를 어떤 식으로 복구할 가능성이 있는 경우에 사용한다.
• 예외처리 회피 : 예외처리를 자신이 담당하지 않고 자신을 호출한 쪽으로 던져버리는 것
  • 콜백과 템플릿처럼 긴밀하게 역할을 분담하고 있는 관계가 아니라면 자신의 코드에서 발생한 예외를 그냥 던져버리는 건 무책임한 책임회피 일수 있다.
  • 예외를 회피하는 것은 예외를 복구하는 것처럼 의도가 분명해야 한다.
• 예외 전환 : 예외 회피와 비슷하게 예외를 복구해서 정상적인 상태로는 만들 수 없기 때문에 예외를 메소드 밖으로 던지는 것이다. 하지만 예외 회피와 달리, 발생한 예외를 적절한 예외로 전환해서 던진다.
  1. 의미를 분명하게 해줄 수 있는 예외로 바꿔주기 위해 사용, 보통 전환하는 예외는 원래 발생한 예외를 담아서 중첩 예외(nested exception)로 만드는 것이 좋다
  2. 예외를 처리하기 쉽고 단순하게 만들기 위해 포장(wrap)하는 것이다. 중첩 예외를 이용해 새로운 예외를 만들고 원인이 되는 예외를 내부에 담아서 던지는 방식은 같다. 주로 예외처리를 강제하는 체크 예외를 언체크 예외인 런타임 예외로 바꾸는 경우 사용한다.

비즈니스적 예외 처리는 check exception을 사용한다.
복구가 불가능한 예외는 가능한 한 런타임 예외로 포장해서 던지게 해서 다른 계층의 메소드를 작성할 때 불필요한 throw 선언이 들어가지 않도록 해줘야 한다.

예외처리 전략

런타임 예외의 보편화

• JEE 서버 환경에서는 서버의 특정 계층에서 예외가 발생했을 때 작업을 일시 중지하고 사용자와 바로 커뮤니케이션하면서 예외상황을 복구할 수 있는 방법이 없다. 차라리 애플리케이션 차원에서 예외상황을 미리 파악하고, 예외가 발생하지 않도록 차단하는 것이 좋다. 또는 프로그램의 오류나 외부환경으로 인해

애플리케이션 예외

• 예외상황에서는 비즈니스적인 의미를 띤 예외를 던지도록 만드는 것이다. 이때 예외는 의도적으로 체크 예외로 만든다. 자주 발생 가능한 예외상황에 대한 로직을 구현하도록 강제해주는 게 좋다.

예외 전환

JDBC의 한계

• 비표준 SQL
• 호환성 없는 SQLException의 DB 에러 정보

DB 에러코드 매핑을 통한 전환 : 스프링은 DB별 에러 코드를 분류해서 스프링이 정의한 예외 클래스와 매핑해놓은 에러 코드 매핑정보 테이블을 만들어 두고 이를 이용한다.
JDBCTemplate는 SQLException을 단지 런타임 예외인 DataAccessException으로 포장 하는 것이 아니라 DB의 에러 코드를 DataAccessException 계층의 클래스 중 하나로 매핑해 준다.

DAO 인터페이스와 DataAccessException 계층 구조
DataAccessException은 JAVA의 주요 데이터 액세스 기술에서 발생할 수 있는 대부분의 예외를 추상화하고 있다.

정리

• 예외를 잡아서 아무런 조치를 취하지 않거나 의미 없는 throws 선언을 남발하는 것은 위험하다.
• 예외는 복구하거나 예외처리 오브젝트로 의도적으로 전달하거나 적절한 예외로 전환해야 한다.
• 좀 더 의미 있는 예외로 변경하거나, 불필요한 catch/throw를 피하기 위해 런타임 예외로 포장하는 두 가지 방법의 예외 전환이 있다.
• 복구할 수 없는 예외는 가능한 한 빨리 런타임 예외로 전환하는 것이 바람직하다.
• 애플리케이션의 로직을 담기 위한 예외는 체크 예외로 만든다.
• JDBC의 SQLException은 대부분 복구할 수 없는 예외이므로 런타임 예외로 전환될 필요가 있다.
• 스프링은 DataAccessException을 통해 DB에 독립적으로 적용 가능한 추상화된 런타임 예외 계층을 제공한다.
• DAO를 데이터 액세스 기술에서 독립시키려면 인터페이스 도입과 런타임 예외 전환, 기술에 독립적인 추상화된 예외로 전환이 필요하다.

3장 템플릿

리소스 반환과 close() : close는 보통 리소스를 반환한다고 이해하면 된다.

템플릿 메소드 패턴 : 상위 클래스에서 흐름을 제어하고 하위 클래스에서 처리내용을 구체화 시킨다.

전략 패턴 - 템플릿 메소드 패턴

전략 패턴 : 알고리즘을 인터페이스로 정의하고 각각의 알고리즘을 클래스별로 캡슐화해서 각각의 알고리즘을 교체 사용 가능하게 한다.

마이크로 DI

로컬 클래스

중첩클래스의 종류
다른 클래스의 내부에 정의되는 클래스를 중첩 클래스(nested class)라고 한다. 중첩 클래스는 독립적으로 오브젝트로 만들어질 수 있는 static 클래스와 자신이 정의된 클래스의 오브젝트 안에서만 만들어질 수 있는 내부 (inner class)클래스로 구분된다.
내부 클래스는 다시 범위(scope)에 따라 세 가지로 구분된다. 멤버 필드처럼 오브젝트 레벨에 정의되는 멤버 내부 클래스(member inner class)와 메소드 레벨에 정의되는 로컬 클래스(local class) 그리고 이름을 갖지 않는 익명 클래스(anonymous inner class)다. 익명 내부 클래스의 범위는 선언된 위치에 따라 다르다.

내부 클래스에서 외부 변수를 접근할 때 외부 변수는 final로 선언되어 있어야 한다.

익명 내부 클래스
익명 내부 클래스(anonymous inner class)는 이름을 갖지 않는 클래스다. 클래스 선언과 오브젝트 생성이 결합된 형태로 만들어지며, 상속할 클래스나 구현할 인터페이스를 생성자 대신 사용해서 다음과 같은 형태로 만들어 사용한다. 클래스를 재사용할 필요가 없고, 구현한 인터페이스 타입으로만 사용할 경우에 유용하다.

new intefacName () { 클래스 본문 }

-> 람다 식으로 변경이 가능하다 (java 8부터)

3.5. 템플릿과 콜백

Template call back pattern : 전략 패턴의 context를 탬플릿이라 부르고, 익명 내부 클래스로 만들어지는 오브젝트를 콜백이라고 부른다.

정리

• JDBC와 같은 예외가 발생할 가능성이 있으며 공유 리소스의 반환이 필요한 코드는 반드시 try/catch/finally 블록으로 관리해야 한다.
• 일정한 작업 흐름이 반복되면서 그중 일부 기능만 바뀌는 코드가 존재한다면 전략 패턴을 적용한다. 바뀌지 않는 부분은 컨텍스트로, 바뀌는 부분은 전략으로 만들고 인터페이스를 통해 유연하게 전략을 변경할 수 있도록 구성한다.
• 같은 애플리케이션 안에서 여러 가지 종류의 전략을 다이내믹하게 구성하고 사용해야 한다면 컨텍스트를 이용하는 클라이언트 메소드에서 직접 전략을 정의하고 제공하게 만든다.
• 클라이언트 메소드 안에 익명 내부 클래스를 사용해서 전략 오브젝트를 구현하면 코드도 간결해지고 메소드의 정보를 직접 사용할 수 있어서 편리하다.
• 컨텍스트가 하나 이상의 클라이언트 오브젝트에서 사용된다면 클래스를 분리해서 공유하도록 만든다.
• 컨텍스트는 별도의 빈으로 등록해서 DI 받거나 클라이언트 클래스에서 직접 생성해서 사용한다. 클래스 내부에서 컨텍스트를 사용할 때 컨텍스트가 의존하는 외부의 오브젝트가 있다면 코드를 이용해서 직접 DI를 해줄 수 있다.
• 단일 전략 메소드를 갖는 전략 패턴이면서 익명 내부 클래스를 사용해서 매번 전략을 새로 만들어 사용하고, 컨텍스트 호출과 동시에 전략DI를 수행하는 방식을 템플릿/콜백 패턴이라고 한다.
• 콜백의 코드에도 일정한 패턴이 반복된다면 콜백을 템플릿에 넣고 재활용하는 것이 편리하다.
• 템플릿과 콜백의 타입이 다양하게 바뀔 수 있다면 제네릭스를 이용한다.
• 스프링은 JDBC 코드 작성을 위해 JdbcTemplate를 기반으로 하는 다양한 템플릿과 콜백을 제공한다.
• 템플릿은 한 번에 하나 이상의 콜백을 사용할 수도 있고, 하나의 콜백을 여러 번 호출할 수도 있다.
• 템플릿/콜백을 설게할 때는 템플릿과 콜백 사이에 주고받는 정보에 관심을 둬야 한다.

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

8.1 스프링의 정의

자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크

• 애플리케이션 프레임워크 : 애플리케이션의 전 영역을 관통하는 일관된 프로그래밍 모델과 핵심기술을 바탕으로 해서 빠르고 효과적으로 개발할 수있게 도와줌
• 경량급: 코드에서 프레임워크와 서버환경에 의존적인 부분을 제거
• 자바엔터프라이즈 개발을 편하게 : 비즈니스 로직을 빠르고 효과적으로 구현할 수 있다.
• 오픈소스

8.2 스프링의 목적

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

복잡함의 근복적인 원인

• 기술적 복잡함 : 기술적인 제약 조건과 요구사항이 증가 하고 있다.
• 비즈니스 로직의 복잡함 : 기능 요구사항과 업무 정책이 수시로 변경된다.

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

제거될 수 없는 근본적인 복잡함

복잡함의 원인은 제거 대상이 아니다. 대신 그 복잡함을 효과적으로 상대할 수 있는 전략과 기법이 필요하다.

비침투적(non-invasive)인 방식을 통한 효과적인 해결책

기술적 복잡함과 비즈니스 로직의 복잡함을 분리하다.

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

기술적인 복잡함

• 서비스 추상화
• AOP 활용

비즈니스 로직의 복잡함을 상대하는 전략

데이터 중심 설계에서 도메인 객체 중심 설계로 변경

핵심도구 : 객체지향과 DI

8.3 POJO 프로그래밍

분리됐지만 반드시 필요한 엔터프라이즈 서비스 기술을 POJO방식으로 개발된 애플리케이션 핵심 로직을 담은 코드에 제공

8.3.1 스프링의 핵심 POJO

POJO 삼각형 DI: 유연하고 확장가능한 오브젝트를 만들어 두고 그 관계를 외부에서 다이내믹하게 설정해 준다.

8.3.2 POJO란 무엇인가 ?

POJO(Plain Old Java Object)

8.3.3 POJO의 조건

• 특정 규약(context)에 종속되지 않는다.
• 특정 환경에 종속되지 않는다.

진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다. 그런 POJO에 애플리케이션 핵심로직과 기능을 담아 설계하고, 개발하는 방법을 POJO 프로그래밍이라고 한다.

8.3.4 POJO의 장점

• 깔끔한 코드
• 자동화 테스트에 유리
• 객체지향적인 설계를 자유롭게 적용할 수 있다.

8.3.5 POJO 프레임워크

POJO 프로그래밍을 가능하도록 기술적인 기반을 제공하는 프레임 워크
스프링, 하이버네이트
스프링은 개발자가 엔터프라이즈 기술보다 객체지향적인 설계와 개발원리에 집중할 수 있는 기회를 준다.

8.4 스프링의 기술

8.4.1 IoC/DI

DI의 활용방법

• 핵심기능의 변경
• 핵심기능의 동적 변경 : 다이내믹 라우팅 프록시, 프록시 오브젝트 기법
• 부가기능의 추가 : 데코레이터 패턴
• 인터페이스 변경 : 어뎁터 패턴
• 프록시
• 템플릿과 콜백
• 싱글톤과 오브젝트 스코프
• 테스트

8.4.2 AOP

AOP의 적용기법

• 다이내믹 프록시 사용
• AspectJ

AOP의 적용단계

1 단계 : 미리 적용된 AOP만 이용한다.
2 단계 : 젅담팀을 두고 정책 AOP를 관리한다.
3 단계 : 이제 익숙해 졌다면 개발자가 AOP를 자유롭게 사용한다.

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

8.5 정리

• 스프링의 그 개발철학과 목표를 분명히 이해하고 사용해야 한다.
• 스프링은 오픈소스 소프트웨어이며, 애플리케이션 개발의 모든 기술과 영역을 종합적으로 다루는 애플리케이션 프레임워크다.
• 엔터프라이즈 애플리케이션 개발의 복잡함은 비즈니스 로직과 엔터프라이즈 시스템의 기술적인 요구사항으로 발생한다. 기존의 접근 방식은 이 복잡도를 낮추지 못하며 자바의 객체지향적인 장점을 포기해야 한다는 문제점이 있다.
• 자바의 근본인 객체지향적인 원리에 충실하게 개발할 수 있으며, 환경과 규약에 의존적이지 않은 POJO를 이용한 애플리케이션 개발은 엔터프라이즈 시스템 개발의 복잡함이 주는 많은 문제를 해결할 수 있다.
• 스프링의 목적은 이런 POJO를 이용해 엔터프라이즈 애플리케이션을 쉽고 효과적으로 개발할 수 있도록 지원해주는 데 있다.
• POJO 방식의 개발을 돕기 위해 스프링은 IoC/DI, AOP/ PSA와 같은 가능기술을 프레임워크와 컨테이너라는 방식을 통해 제공한다.

스프링이 어떻게 엔터프라이즈 개발의 복잡함을 제거하고, POJO 프로그래밍이라는 효과적인 방법을 사용할 수 있게 하는지 관심을 갖는 것이 스프링을 가장 빠르게 이해하고 적용할 수 있는 지름길이다.