Modern Java In Action 정리 - 리팩터링, 테스팅, 디버깅
- 람다 표현식으로 코드 리팩터링하기
- 람다 표현식이 객체지향 설계 패턴에 미치는 영향
- 람다 표현식 테스팅
- 람다 표현식과 스트림 API 사용 코드 디버깅
모던 자바 인 액션 책을 보고 정리한 글입니다.
가독성과 유연성을 개선하는 리팩토링
- 람다, 메서드 참조, 스트림 등의 기능을 이용해 가독성을 높이고 유연한 코드로 리팩토링하는것을 설명.
코드 가독성 개선
- 익명 클래스를 람다 표현식으로 리팩토링
- 람다 표현식을 메서드 참조로 리팩토링
- 명령형 데이터 처리를 스트림으로 리팩토링
익명 클래스를 람다 표현식으로 리팩토링
- 하나의 추상 메서드를 구현하는 익명 클래스는 람다 표현식으로 리팩토링 할 수 있다.
1 |
|
- 모든 익명 클래스를 람다 표현식으로 변환할 수 있는것은 아니다.
- 익명 클래스에서 사용한 this, super는 람다 표현식에서 서로 다른 의미를 가지게 된다.
- this는 익명 클래스 자신을 가리키지만 람다에서 this는 람다를 감싸는 클래스를 의미하게 된다.
- 익명 클래스는 감싸고 있는 클래스의 변수를 가릴수 있다. 하지만 다음 코드에서 보여주는것 처럼 람다 표현식으로는 가릴수 없다.
1 |
|
- 익명 클래스를 람다 표현식으로 변경하면 콘텍스트 오버로딩에 따른 모호함이 초래된다.
- 익명 클래스는 인스턴스화 할때 명시적으로 형식이 정해지는 반면 람다의 형식은 콘텍스트에 따라 달라지기 때문이다.
1 |
|
- 익명 클래스를 람다 표현식으로 변경하는 경우 Runnable 과 Task 중 어떤 클래스를 사용해야 하는지 알수 없으므로 모호함이 발생한다.
- 명시적 형변환을 이용해서 처리할 수 있지만 일반적으로 IDE에서 이러한 모호함을 처리해준다.
람다 표현식을 메서드 참조로 리펙토링 하기
- 람다 표현식을 메소드 참조로 변환하면 가독성을 높아지고 코드의 의도를 명확하게 표현할 수 있다.
1 |
|
- comparingBy와 mayBy 같은 정적 헬퍼 메서드를 활용하는것도 좋다.
1 |
|
명령형 데이터 처리를 스트림으로 리팩토링하기
1 |
|
코드 유연성 개선
- 함수형 인터페이스 적용
- 조건부 연기 실행 패턴
- 실행 어라운드 패턴
- 조건부 연기 실행
- 실제 작업을 처리하는 코드 내부에 제어 흐름문이 복잡하게 얽힌 코드를 흔히 볼 수 있다.
1 |
|
- 위 코드는 다음과 같은 사항에 문제가 있다.
- logger의 상태가 isLoggable이라는 메서드에 의해 클라이언트로 노출된다.
- 메시지를 로깅할 때마다 logger 객체의 상태를 매번 확인해야 할까 ?
- 다음처럼 메시지를 로깅하기 전에 logger 객체가 적절한 수준으로 설정되었는지 내부적으로 확인하는 log 메서드를 사용하는것이 바람직하다.
1 |
|
- 불필요한 if 문은 사라졌지만 여전히 위 코드는 문제가 있다.
- 조건에 맞지 않더라도 항상 로깅 메시지를 평가하게 된다.
- 람다를 이용하여 이러한 문제를 해결하자. 특정 조건에서만 메시지가 생성될 수 있도록 메시지 생성 과정을 연기해야 한다.
- Java 8에서는 이와 같은 문제를 해결할 수 있도록 Supplier를 제공하고 있다.
1 |
|
- log 메서드는 조건에 맞는 경우에만 실행되고 인수로 넘겨진 람다를 내부적으로 실행할 수 있게 변경되었다.
- 이러한 방법으로 객체 상태를 자주확인하는 상황이나 객체의 일부 메서드를 확인한 다음에 메서드를 호출하도록 새로운 메서드를 구현하는것이 좋다.
-
코드의 가독성이 좋아질 뿐만 아니라 캡슐화(객체 상태가 클라이언트로 노출되지 않는다.)가 강화 된다.
- 실행 어라운드
- 매번 같은 준비, 종료 과정을 반복적으로 수행하는 코드를 람다로 리팩토링 해보자.
1 |
|
- 람다로 BufferedReader 객체의 동작을 결정할 수 있는 것은 함수형 인터페이스 BufferedReaderProcessor 덕분이다.
람다로 객체지향 디자인 패턴 리팩터링 하기
- 디자인 패턴에 람다 표현식이 더해지면서 색다른 기능을 발휘 하게 되었다.
- 즉, 람다를 이용하여 이전에 디자인 패턴으로 해결하던 문제를 더 쉽게 간단하게 해결할 수 있다.
- 람다 표현식으로 기존의 많은 객체지향 디자인 패턴을 제거하거나 간결하게 재 구현할 수 있다.
- 이절에선 다섯 가지 패턴을 살펴본다.
- 전략(Strategy)
- 템플릿 메서드(Template Method)
- 옵저버(Observer)
- 의무 체인(Chain of Responsibility)
- 팩토리(Factory)
전략 패턴
- 전략 패턴은 한 유형의 알고리즘을 보유한 상태에서 런타임시 적절한 알고리즘을 선택하는 기법이다.
- 전략 패턴은 크게 클라이언트 -> 전략 -> A, B (런타임시 선택) 으로 구성된다.
- 알고리즘을 나타내는 인터페이스 (Strategy 인터페이스)
- 다양한 알고리즘을 나타내는 한 개 이상의 인터페이스 구현 (StrategyA, StrategyB)
- 전략 객체를 사용하는 한 개 이상의 클라이언트
- 예시로 오직 소문자 또는 숫자로 이루어져야하는 등 텍스트 입력이 다양한 조건에 맞도록 포맷되어있는지 검증하는 로직이 존재한다고 가정하자.
1 |
|
- 람다를 사용하지 않고 위와 같이 구현할 수 있다.
- 람다를 사용한 코드를 살펴보자.
1 |
|
- ValidationStreategy는 함수형 인터페이스이며 Predicate
과 같은 함수 디스크럼터를 갖고 있음을 파악했을것이다. - 따라서 잔략을 구현하는 새로운 클래스를 만드는것보다 람다 표현식을 전달하여 간결하게 나타낼 수 있다.
- 위 코드에서 확인할 수 있듯이 람다 표현식을 전달하면 전략 패턴에서 발생하는 자잘한 코드를 제거할 수 있다.
- 추가적으로 람다 표현식은 전략을 캡슐화 하는 효과도 존재한다.
템플릿 메서드
- 특정 기능의 일부만 변경하여 사용할 수 있는 유연함을 제공하는 패턴이다.
1 |
|
- 람다 표현식 사용
1 |
|
옵저버
- 어떤 이벤트가 발생했을 때 한 객체(Subject)가 다른 객체 리스트(Observer)에 자동으로 알림을 보내야 하는 패턴에서 옵저버 디자인 패턴을 사용한다.
- notifyObserver() -> notify() <- ObserverA, ObserverB
1 |
|
- 람다 표현식 사용하기
1 |
|
- 항상 람다 표현식을 사용하는것은 옳지 않다. 람다 표현식으로 불필요한 코드가 제거 되는것이 바람직하다 할때만 사용하는것을 권장한다.
- 복잡한 로직이나 여러 메서드가 정의된다면 람다 표현식 보다 기존 방식을 고수하는것이 올바르다.
의무 체인
- 작업 처리 객체를 체이닝 형식으로 구현할 때 사용하는 패턴이다.
- 한 객체가 작업을 처리한 다음 다른 객체로 결과를 전달하고 다음 객체가 작업을 처리후 그 다음 객체로 전달하는 형식
- 일반적으로 작업 처리 추상 클래스를 구현하여 의무 체인 패턴을 구현한다.
1 |
|
- 코드를 자세히 살펴보면 템플릿 메서드 패턴이 사용되었음을 알 수 있다.
- handle 메서드는 일부 작업을 어떻게 처리할지 전체적으로 서술한다.
- ProcessingObject 클래스를 상속받아 handleWork 메서드를 구현하여 다양한 종류의 작업 처리 객체를 만들수 있다.
1 |
|
- 람다 표현식 사용
- 이러한 패턴은 함수 체인과 비슷하다. 람다 표현식을 조합하는 방식으로는 기본적으로 compose, andThen이 있다.
- andThen메서드로 이들 함수를 조합 해 체인을 만들어 보자.
1 |
|
팩토리
- 인스턴스화 로직을 클라이언트에 노출하지 않고 객체를 만들기 위해 팩토리 디자인 패턴을 사용한다.
1 |
|
- 람다 표현식 사용
- 생성자도 메서드 참조 처럼 접근이 가능하다.
1 |
|
- 팩토리 패턴이 수행하던 기능을 Java8의 새로운 기능으로 깔끔히 정리 했다.
- 하지만 파라미터가 많아질 경우 코드의 복잡도가 올라가니 적절한 상황에서 사용하도록 하자.
람다 테스팅
- 일반적으로 프로그램이 의도대로 동작하는지 확인할 수 있는 방법은 단위 테스트를 작성하는것이다.
보이는 람다 표현식의 동작 테스팅
- 람다의 동작을 테스트 하기 위해 메서드를 정의하는 것 처럼 람다를 정의하여 테스트 가능하다.
1 |
|
람다를 사용하는 메서드의 동작에 집중
- 람다의 목표는 정해진 동작을 다른 메서드에서 사용할 수 있도록 하나의 조각으로 캡슐화 하는것이다.
- 람다 표현식을 사용하는 메서드의 동작을 테스트 함으로서 람다 표현식을 검증 할 수 있다.
복잡한 람다를 개별 메서드로 분할
- 복잡한 로직이 포함된 람다를 구현하게 된다면 로직을 분리 하거나 메서드 레퍼런스를 활용하도록 하자.
고차원 함수 테스팅
- 함수를 인수로 받거나 다른 함수를 반환하는 메서드는 사용하기도, 테스트하기도 어렵다.
- 메서드가 람다를 인수로 받는다면 다른 람다로 메서드의 동작을 테스트 할 수 있다.
- 테스트해야하는 함수가 다른 함수를 반환한다면 앞서 Comparator와 비슷하게 함수형 인터페이스의 인스턴스로 간주하고 테스트 할 수 있다.
디버깅
- 문제가 발생하느 코드를 디버깅할때는 다음 두가지를 가장 먼저 확인해야한다.
- 스택 트레이스
- 로깅
- 로그를 찍어야 하는 상황이라면 스트림을 소비하지 않는 peek을 사용하도록 하자.