🐹 chap9. 리팩터링, 테스팅, 디버깅

9.1 가독성과 유연성을 개선하는 리팩터링

9.1.1 코드 가독성 개선

코드 가독성이 좋다 → 어떤 코드를 다른 사람도 쉽게 이해할 수 있다.

코드 가독성을 개선한다는 것은 우리가 구현한 코드를 다른 사람이 쉽게 이해하고 유지보수할 수 있게 만드는 것을 의미하다. 코드 가독성을 높이려면 코드의 문서화를 잘하고, 표준 코딩 규칙을 준수하는 등의 노력을 기울여야 한다.

[ 코드 가독성을 개선할 수 있는 예시 ]

• 익명 클래스를 람다 표현식으로 리팩터링
• 람다 표현식을 메서드 참조로 리팩터링
• 명령형 데이터 처리를 스트림으로 리팩터링

9.1.2 익명 클래스를 람다 표현식으로 리팩터링하기

하나의 추상 메서드를 구현하는 익명 클래스는 람다 표현식으로 리팩터링할 수 있다.

• Runnable 객체를 만드는 익명 클래스와 이에 대응하는 람다 표현식

// 익명 클래스 
Runnable r1 = new Runnable() {
    public void run() {
        System.out.println("Hello");
    }
};
// 람다 표현식
Runnable r2 = () -> System.out.println("Hello");

하지만 모든 익명 클래스를 람다 표현식으로 변환할 수 있는 것은 아니다.

1. 익명 클래스에서 사용한 this와 super는 람다 표현식에서 다른 의미를 갖는다.
   • 익명 클래스 this : 익명 클래스 자신
   • 람다 this : 람다를 감싸는 클래스를 가리킨다

2. 익명 클래스는 감싸고 있는 클래스의 변수를 가릴 수 있다. (섀도 변수)

   하지만 람다 표현식으로는 변수를 가릴 수 없다.

    int a = 10;
    Runnable r1 = () -> {
        int a = 2; // 컴파일에러
        System.out.println(a);
    };
       
    Runnable r2 = new Runnable() {
        public void run() {
            int a = 2;
            System.out.println(a);
        }
    };
   

3. 익명 클래스는 람다 표현식으로 바꾸면 콘텍스트 오버로딩에 따른 모호함이 초래될 수 있다.

   익명 클래스는 인스턴스화할 때 명시적으로 형식이 정해지는 반면 람다의 형식은 콘텍스트에 따라 달라지기 때문이다.

    interface Task {
        public void execute();
    }
    public static void doSomething(Runnable r){ r.run(); }
    public static void doSomething(Task a){ a.execute(); }
   

   Task를 구현하는 익명 클래스를 전달할 수 있다.

    // Task 지정
    doSomething(new Task() {
        public void execute() {
            System.out.println("Danger danger!!");
        }
    });
   

   하지만 익명 클래스를 람다 표현식으로 바꾸면 메서드를 호출할 때 Runnable과 Task 모두 대상 형식이 될 수 있으므로 문제가 생긴다.

    // Task인지 Runnable인지 명확히 알 수 없음 
    doSomething(() -> System.out.println("Danger danger!!");
   

   즉, doSomething(Runnable)과 doSomething(Task) 중 어느 것을 가리키는지 알 수 없는 모호함이 발생한다.

   명시적 형변환 (Task)를 이용해 모호함을 제거할 수 있다.

    // 명시적 형변환 
    doSomething((Task)() -> System.out.println("Danger danger!!"));
   

   하지만 넷빈즈와 IntelliJ 등을 포함한 대부분의 통합 개발 환경(IDE)에서 제공하는 리팩터링 기능을 이용하면 위 같은 문제가 자동으로 해결된다.

9.1.3 람다 표현식을 메서드 참조로 리팩터링하기

람다 표현식 대신 메서드 참조를 이용하면 가독성을 높일 수 있다.

메서드 참조의 메서드명으로 코드의 의도를 명확하게 알릴 수 있기 때문이다.

// 칼로리 수준으로 요리 그룹화 
Map<CaloricLevel, List<Dish>> dishesByCaloricLevel =
    menu.stream()
        .collect(
            groupingBy(dish -> {
                if (dish.getCalories() <= 400) return CaloricLevel.DIET;
                else if (dish.getCalories() <= 700) return CaloricLevel.NORMAL;
                else return CaloricLevel.FAT;
    }));

람다 표현식을 별도의 메서드로 추출한 다음에 groupingBy에 인수로 전달할 수 있다. 다음처럼 코드가 간결하고 의도도 명확해진다.

// 람다 표현식을 메서드로 추출
Map<CaloricLevel, List<Dish>> dishesByCaloricLevel =
    menu.stream().collect(groupingBy(Dish::getCaloricLevel));

이제 Dish 클래스에 getCaloricLevel 메서드를 추가한다.

public class Dish {
    ...
    public CaloricLevel getCaloricLevel() {
        if (this.getCalories() <= 400) return CaloricLevel.DIET;
        else if (this.getCalories() <= 700) return CaloricLevel.NORMAL;
        else return CaloricLevel.FAT;
    }
}

또한 comparing과 maxBy 같은 정적 헬퍼 메서드를 활용하는 것도 좋다. 이들은 메서드 참조와 조화를 이루도록 설계되었다.

// 비교 구현에 신경 써야 한다. 
inventory.sort(
    (Apple a1, Apple a2) -> a1.getWeight().compareTo(a2.getWeight()));
// 코드가 문제 자체를 설명한다. 
inventory.sort(comparing(Apple::getWeight));

sum, maximum 등 자주 사용하는 리듀싱 연산은 메서드 참조와 함께 사용할 수 있는 내장 헬퍼 메서드를 제공한다.

최댓값이나 합계를 계산할 때 람다 표현식과 저수준 리듀싱 연산을 조합하는 것보다 Collectors API를 사용하면 코드의 의도가 더 명확해진다.

// 저수준 리듀싱 연산을 조합한 코드
int totalCalories =
    menu.stream().map(Dish::getCalories)
        .reduce(0, (c1, c2) -> c1 + c2);

내장 컬렉터를 이용하면 코드 자체로 문제를 더 명확하게 설명할 수 있다.

// 컬렉터 summingInt를 사용(자신이 어떤 동작을 수행하는지 메서드 이름으로 설명)
int totalCalories = menu.stream().collect(summingInt(Dish::getCalories));

9.1.4 명령형 데이터 처리를 스트림으로 리팩터링하기

스트림 API는 데이터 처리 파이프라인의 의도를 더 명확히 보여주기 때문에 반복자를 이용한 기존의 모든 컬렉션 처리 코드를 스트림 API로 바꿔야 한다.

스트림은 쇼트서킷과 게으름이라는 강력한 최적화뿐 아니라 멀티코어 아키텍처를 활용할 수 있는 지름길을 제공한다.

다음 명령형 코드는 필터링 + 추출로 엉킨 코드다.

해당 코드는 의도를 파악하기 어렵고 병렬로 실행시키는 것이 매우 어렵다.

List<String> dishNames = new ArrayList<>();
for(Dish dish: menu) {
    if(dish.getCalories() > 300) {
        dishNames.add(dish.getNames());
    }
}

스트림 API를 이용하면 문제를 더 직접적으로 기술할 수 있을 뿐 아니라 쉽게 병렬화할 수 있다.

menu.parallelStream()
    .filter(d -> d.getCalories() > 300)
    .map(Dish::getName)
    .collect(toList());

명령형 코드의 break, continue, return 등의 제어 흐름문을 모두 분석해서 같은 기능을 수행하는 스트림 연산으로 유추해야 하므로 명령형 코드를 스트림 API로 바꾸는 것은 쉬운 일이 아니다.

9.1.5 코드 유연성 개선

람다 표현식을 이용하면 동작 파라미터화를 쉽게 구현할 수 있다. 즉, 다양한 람다를 전달해서 다양한 동작을 표현할 수 있다. 따라서 변화하는 요구사항에 대응하는 코드를 구현할 수 있다.

ex) 프레디케이트로 다양한 필터링 기능 구현, 비교자로 다양한 비교 기능 만들기

함수형 인터페이스 적용

람다 표현식을 이용하려면 함수형 인터페이스가 필요하다. 따라서 함수형 인터페이스를 코드에 추가해야 한다.

조건부 연기 실행(conditional deferred execution)과 실행 어라운드(execute around) 두 가지 자주 사용하는 패턴으로 람다 표현식 리팩터링을 진행한다.

조건부 연기 실행

실제 작업을 처리하는 코드 내부에 제어 흐름문이 복잡하게 얽힌 코드를 흔히 볼 수 있다.

// 내장 자바 Logger 클래스를 사용하는 예제
if (logger.isLoggable(Log.FINER)) {
    logger.final("Problem: " + generateDiagnostic());
}

위 코드는 다음과 같은 문제가 있다.

• logger의 상태가 isLoggable이라는 메서드에 의해 클라이언트 코드로 노출된다.
• 메시지를 로깅할 때마다 logger 객체의 상태를 매번 확인하는 것은 코드를 어지럽히는 것 뿐이다.

메세지를 로깅하기 전에 logger 객체가 적절한 수준으로 설정되었는지 내부적으로 확인하는 log 메서드를 사용하는 것이 바람직하다.

logger.log(Level.FINER, "Problem: " + generateDiagnostic());

덕분에 불필요한 if문을 제거할 수 있으며 logger의 상태를 노출할 필요가 없다.

하지만 인수로 전달된 메세지 수준에서 logger가 활성화되어 있지 않더라도 항상 로깅 메시지를 평가하게 된다.

람다를 이용해 해당 문제를 해결한다. 특정조건(logger 수준을 FINER로 설정)에서만 메시지가 생성될 수 있도록 메시지 생성 과정을 연기할 수 있어야 한다.

자바 8 API에서는 logger 문제를 해결할 수 있도록 Supplier를 인수로 갖는 오버로드된 log메서드를 제공한다.

// 새로 추가된 log 메서드의 시그니처
public void log(Level level, Supplier<String> msgSupplier)

다음처럼 log 메서드를 호출할 수 있다.

// 람다 사용
logger.log(Level.FINER, () -> "Problem: " + generateDiagnostic());

log 메서드는 logger의 수준이 적절하게 설정되어 있을 때만 인수로 넘겨진 람다를 내부적으로 실행한다. 다음은 log 메서드의 내부 구현 코드다.

public void log(Level level, Supplier<String> msgSupplier) {
    if (logger.isLoggable(level)) {
        log(level, msgSupplier.get()); // 람다 실행
    }
}

만약 클라이언트 코드에서 객체 상태를 자주 확인하거나(ex. logger의 상태), 객체의 일부 메서드를 호출하는 상황(ex. 메시지 로깅)이라면 내부적으로 객체의 상태를 확인한 다음에 메서드를 호출(람다나 메서드 참조를 인수로 사용)하도록 새로운 메서드를 구현하는 것이 좋다. 그러면 코드 가독성이 좋아질 뿐 아니라 캡슐화도 강화된다(객체 상태가 클라이언트 코드로 노출되지 않는다)!

실행 어라운드

매번 같은 준비, 종료 과정을 반복적으로 수행하는 코드가 있다면 이를 람다로 변환할 수 있다. 준비, 종료 과정을 처리하는 로직을 재사용함으로써 코드 중복을 줄일 수 있다.

아래 코드는 파일을 열고 닫을 때 같은 로직을 사용했지만 람다를 이용해 다양한 방식으로 파일을 처리할 수 있도록 파라미터화되었다.

String oneLine = 
    processFile((BufferedReader b) -> b.readLine()); // 람다 전달
String twoLines =
    processFile((BufferedReader b) -> b.readLine() + b.readLine()); // 다른 람다 전달
public static String processFile(BufferedReaderProcessor p) throws IOException {
    try(BufferedReader br = new BufferedReader(new 
        FileReader("ModernJavaInAction/chap9/data.txt"))) {
        return p.process(br); //인수로 전달된 BufferedReaderProcessor를 실행
    }
} // IOException을 던질 수 있는 람다의 함수형 인터페이스 
public interface BufferedReaderProcessor {
    String process(BufferedReader b) throws IOException;
}

람다로 BufferedReader 객체의 동작을 결정할 수 있는 것은 함수형 인터페이스 BufferedReaderProcessor 덕분이다.

9.2 람다로 객체지향 디자인 패턴 리팩터링하기

언어에 새로운 기능이 추가되면서 기존 코드 패턴이나 관용코드의 인기가 식기도 한다.

자바 5: for-each 루프는 에러 발생률이 적으며 간결하므로 기존의 반복자 코드를 대체했다.

자바 7: 다이아몬드 연산자 <> 때문에 기존의 제네릭 인스턴스를 명시적으로 생성하는 빈도가 줄었다.

다양한 패턴을 유형별로 정리한 것이 디자인 패턴(design pattern)이다.

디자인 패턴은 공통적인 소프트웨어 문제를 설계할 때 재사용할 수 있는 검증된 청사진을 제공한다. 몇 가지 예시는 다음과 같다.

• 구조체와 동작하는 알고리즘을 서로 분리하고 싶을 때 방문자 디자인 패턴을 사용할 수 있다.
• 싱글턴 패턴을 이용해서 클래스 인스턴스화를 하나의 객체로 제한할 수 있다.

람다를 이용하면 디자인 패턴으로 해결하던 문제를 더 간단하게 해결하고, 기존의 많은 객체지향 디자인 패턴을 제거하거나 간결하게 재구현할 수 있다.

다음 다섯 가지 패턴을 살펴본다.

• 전략(strategy)
• 템플릿 메서드(template method)
• 옵저버(observer)
• 의무 체인(chain of responsibility)
• 팩토리(factory)

9.2.1 전략

전략 패턴

한 유형의 알고리즘을 보유한 상태에서 런타임에 적절한 알고리즘을 선택하는 기법

그림과 같이 전략 패턴은 세 부분으로 구성된다.

• 알고리즘을 나타내는 인터페이스(Strategy 인터페이스)
• 다양한 알고리즘을 나타내는 한 개 이상의 인터페이스 구현(ConcreteStrategyA, ConcreteStrategyB 같은 구체적인 구현 클래스)
• 전략 객체를 사용하는 한 개 이상의 클라이언트

예를 들어 오직 소문자 또는 숫자로 이루어져야 하는 등 텍스트 입력이 다양한 조건에 맞게 포맷 되어 있는지 검증한다고 가정하자. 먼저 String 문자열을 검증하는 인터페이스부터 구현한다.

public interface ValidationStrategy {
    boolean execute(String s);
}

이번에는 위에서 정의한 인터페이스를 구현하는 클래스를 하나 이상 정의한다.

// 오직 소문자로 이루어졌는지 검증
public class IsAllLowerCase implements ValidationStrategy {
    public boolean execute(String s) {
        return s.matches("[a-z]+");
    }
}

// 오직 숫자로 이루어졌는지 검증
public class IsNumeric implements ValidationStrategy {
    public boolean execute(String s) {
        return s.matches("\\d+");
    }
}

지금까지 구현한 클래스를 다양한 검증 전략으로 활용할 수 있다.

public class Validator {
    private final ValidationStrategy strategy;
    public Validator(ValidationStrategy v) {
        this.strategy = v;
    }
    public boolean validate(String s) {
        return strategy.execute(s);
    }
}

Validator numericValidator = new Validator(new IsNumeric());
boolean b1 = numericValidator.validate("aaaa"); // false 반환
Validator lowerCaseValidator = new Validator(new IsAllLovwerCase());
boolean b2 = lowerCaseValidator.validate("bbbb"); // true 반환 

람다 표현식 사용

ValidationStrategy는 함수형 인터페이스며 Predicate과 같은 함수 디스크립터를 갖고 있다. 따라서 다양한 전략을 구현하는 새로운 클래스를 구현할 필요 없이 람다 표현식을 직접 전달하면 코드가 간결해진다.

Validator numericValidator = 
    new Validator((String s) -> s.matches("[a-z]+")); // 람다를 직접 전달
boolean b1 = numericValidator.validate("aaaa");

Validator lowerCaseValidator = 
    new Validator((String s) -> s.matches("\\d+")); // 람다를 직접 전달
boolean b2 = lowerCaseValidator.validate("bbbb");

위 코드에서 확인할 수 있듯이 람다 표현식을 이용하면 전략 디자인 패턴에서 발생하는 자잘한 코드를 제거할 수 있다. 람다 표현식은 코드 조각(또는 전략)을 캡슐화한다. 즉, 람다 표현식으로 전략 디자인 패턴을 대신할 수 있다.

9.2.2 템플릿 메서드

템플릿 메서드

‘이 알고리즘을 사용하고 싶은데 그대로는 안 되고 조금 고쳐야 하는’ 상황에 적합하다.

간단한 온라인 뱅킹 애플리케이션을 구현한다고 가정하자. 사용자가 고객 ID를 애플리케이션에 입력하면 은행 데이터베이스에서 고객 정보를 가져오고 고객이 원하는 서비스를 제공할 수 있다.

예를 들어 고객 계좌에 보너스를 입금한다고 가정하자. 은행마다 다양한 온라인 뱅킹 애플리케이션을 사용하며 동작 방법도 다르다. 다음은 온라인 뱅킹 애플리케이션의 동작을 정의하는 추상 클래스다.

abstract class OnlineBanking {
    public void processCustomer(int id) {
        Customer c = Database.getCustomerWithId(id);
        makeCustomerHappy(c);
    }
    abstract void makeCustomerHappy(Customer c);
}

processCustomer 메서드는 온라인 뱅킹 알고리즘이 해야 할 일을 보여준다. 우선 주어진 고객 ID를 이용해서 고객을 만족시켜야 한다. 각각의 지점은 OnlineBanking 클래스를 상속받아 makeCustomerHappy 메서드가 원하는 동작을 수행하도록 구현할 수 있다.

람다 표현식 사용

람다나 메서드 참조로 알고리즘에 추가할 다양한 컴포넌트를 구현할 수 있다.

이전에 정의한 makeCustomerHappy의 메서드 시그니처와 일치하도록 Consumer 형식을 갖는 두 번째 인수를 processCustomer에 추가한다.

public void processCustomer(int id, Consumer<Customer> makeCustomerHappy) {
    Customer c = Database.getCustomerWithId(id);
    makeCustomerHappy.accept(c);
}

이제 onlineBanking 클래스를 상속받지 않고 직접 람다 표현식을 전달해서 다양한 동작을 추가할 수 있다.

new OnlineBankingLambda().processCustomer(1337, (Customer c) ->
    System.out.println("Hello " + c.getName());

람다 표현식을 이용하면 템플릿 메서드 디자인 패턴에서 발생하는 자잘한 코드도 제거할 수 있다.

9.2.3 옵저버

옵저버 디자인 패턴

어떤 이벤트가 발생했을 때 한 객체(주제)가 다른 객체 리스트(옵저버)에게 자동으로 알림을 보내야 하는 상황에서 사용

• GUI 애플리케이션에서 옵저버 패턴이 자주 등장한다. 버튼 같은 GUI 컴포넌트에 옵저버를 설정할 수 있다. 그리고 사용자가 버튼을 클릭하면 옵저버에 알림이 전달되고 정해진 동작이 수행된다.
• 주식의 가격(주제) 변동에 반응하는 다수의 거래자(옵저버) 예제에서도 옵저버 패턴을 사용할 수 있다.

옵저버 패턴으로 트위터 같은 커스터마이즈된 알림 시스템을 설계하고 구현할 수 있다. 다양한 신문 매체(뉴욕타임스, 가디언, 르몽드)가 뉴스 트윗을 구독하고 있으며 특정 키워드를 포함하는 트윗이 등록되면 알림을 받고 싶어한다.

우선 다양한 옵저버를 그룹화할 Observer 인터페이스가 필요하다.

Observer 인터페이스는 새로운 트윗이 있을 때 주제(Feed)가 호출할 수 있도록 notify라고 하는 하나의 메서드를 제공한다.

interface Observer {
    void notify(String tweet);
}

이제 트윗에 포함한 다양한 키워드에 대한 동작을 수행할 수 있는 여러 옵저버를 정의할 수 있다.

class NYTimes implements Observer {
    public void notify(String tweet) {
        if(tweet != null && tweet.contains("money")) {
            System.out.println("Breaking news in NY! " + tweet);
        }
    }
}
class Guardian implements Observer {
    public void notify(String tweet) {
        if(tweet != null && tweet.contains("queen")) {
            System.out.println("Yet more news from London..." + tweet);
        }
    }
}
class LeMonde implements Observer {
    public void notify(String tweet) {
        if(tweet != null && tweet.contains("wine")) {
            System.out.println("Today cheese, wine and news! " + tweet);
        }
    }
}

그리고 주제도 구현해야 한다. 다음은 Subject 인터페이스의 정의다.

interface Subject {
    void registerObserver(Observer o);
    void notifyObservers(String tweet);
}

주제는 registerObsesrver 메서드로 새로운 옵저버를 등록한 다음에 notifyObservers 메서드로 트윗의 옵저버에 이를 알린다.

class Feed implements Subject {
    private final List<Observer> observers = new ArrayList<>();
    public void registerObserver(Observer o) {
        this.observers.add(o);
    }
    public void notifyObservers(String tweet) {
        observers.forEach(o -> o.notify(tweet));
    }
}

Feed는 트윗을 받았을 때 알림을 보낼 옵저버 리스트를 유지한다. 이제 주제와 옵저버를 연결하는 데모 애플리케이션을 만들 수 있다.

Feed f = new Feed();
f.registerObserver(new NYTimes());
f.registerObserver(new Guardian());
f.registerObserver(new LeMonde());
f.notifyObservers("The queen said her favorite book is Modern Java in Action!");

가디언도 우리의 트윗을 받아볼 수 있게 되었다.

람다 표현식 사용하기

세 개의 옵저버를 명시적으로 인스턴스화하지 않고 람다 표현식을 직접 전달해서 실행할 동작을 지정할 수 있다.

f.registerObserver((String tweet) -> {
    if(tweet != null && tweet.contains(" money ")) {
        System.out.println("Breaking news in NY! " + tweet);
    }
});
f.registerObserver((String tweet) -> {
    if(tweet != null && tweet.contains(" queen ")) {
        System.out.println("Yet more news from London... " + tweet);
    }
});

9.2.4 의무 체인

의무 체인 패턴

작업 처리 객체의 체인(동작 체인 등)을 만들 때 사용

한 객체가 어떤 작업을 처리한 다음에 다른 객체로 결과를 전달하고, 다른 객체도 해야 할 작업을 처리한 다음에 또 다른 객체로 전달하는 식이다.

일반적으로 다음으로 처리할 객체 정보를 유지하는 필드를 포함하는 작업 처리 추상 클래스로 의무 체인 패턴을 구성한다. 작업 처리 객체가 자신의 작업을 끝냈으면 다음 작업 처리 객체로 결과를 전달한다.

// 작업 처리 객체 예제 코드
public abstract class ProcessingObject<T> {
    protected ProcessingObject<T> successor;
    public void setSuccessor(ProcessingObject<T> succesor) {
        this.successor = successor;
    }
    public T handle(T input) {
        T r = handleWork(input);
        if(successor != null) {
            return successor.handle(r);
        }
        return r;
    }
    abstract protected T handleWork(T input);
}

handle 메서드는 일부 작업을 어떻게 처리해야 할지 전체적으로 기술한다. ProcessingObject 클래스를 상속받아 handleWork 메서드를 구현하여 다양한 종류의 작업 처리 객체를 만들 수 있다.

다음의 두 작업 처리 객체는 텍스트를 처리하는 예제다(위 패턴 활용 예제)

public class HeaderTextProcessing extends ProcessingObject<String> {
    public String handleWork(String text) {
        return "From Raoul, Mario and Alan: " + text;
    }
}

public class SpellCheckerProcessing extends ProcessingObject<String> {
    public String handleWork(String text) {
        return text.replaceAll("labda", "lambda");
    }
}

두 작업 처리 객체를 연결해서 작업 체인을 만들 수 있다.

ProcessingObject<String> p1 = new HeaderTextProcessing();
ProcessingObject<String> p2 = new SpellCheckerProcessing();
p1.setSuccessor(p2); // 두 작업 처리 객체를 연결한다. 
String result = p1.handle("Aren't labdas really sexy?!!");
System.out.println(result);
// 'From Raoul, Mario and Alan: Aren't lambdas really sexy?!!' 출력

람다 표현식 사용

위 패턴은 함수 체인(함수 조합)과 비슷하다.

작업 처리 객체를 Function<String, String>, 더 정확히 표현하자면 UnaryOperator 형식의 인스턴스로 표현할 수 있다. andThen 메서드로 조합해서 체인을 만들 수 있다.

UnaryOperator<String> headerProcessing =
    (String text) -> "From Raoul, Mario and Alan: " + text; // 첫 번째 작업 처리 객체
UnaryOperator<String> spellCheckerProcessing =
    (String text) -> text.replaceAll("labda", "lambda"); // 두 번째 작업 처리 객체
Function<String, String> pipeline = 
    headerProcessing.andThen(spellCheckerProcessing); // 동작 체인으로 두 함수를 조합한다. 
String result = pipeline.apply("Aren't labdas really sexy?!!");

9.2.5 팩토리

팩토리 디자인 패턴

인스턴스화 로직을 클라이언트에 노출하지 않고 객체를 만들 때 사용

예를 들어 은행에서 취급하는 대출, 채권, 주식 등 다양한 상품을 만들어야 한다고 가정하자. 다음 코드에서 보여주는 것처럼 다양한 상품을 만드는 Factory 클래스가 필요하다.

public class ProductFactory {
    public static Product createProduct(String name) {
        switch(name){
            case " loan " : return new Loan();
            case " stock " : return new Stock();
            case " bond " : return new Bond();
            default: throw new RuntimeException("No such product " + name);
        }
    }
}

여기서 Loan, Stock, Bond 모두 Product의 서브형식이다. createProduct 메서드는 생산된 상품을 설정하는 로직을 포함할 수 있다.

이는 부가적인 기능일 뿐 위 코드의 진짜 장점은 생성자와 설정을 외부로 노출하지 않음으로써 클라이언트가 단순하게 상품을 생산할 수 있다는 것이다.

Product p = ProductFactory.createProduct("loan");

람다 표현식 사용

생성자도 메서드 참조처럼 사용할 수 있다.

다음은 Loan 생성자를 사용하는 코드다.

Supplier<Product> loanSupplier = Loan::new;
Loan loan = loanSupplier.get();

이제 다음 코드처럼 상품명을 생성자로 연결하는 Map을 만들어서 코드를 재구현할 수 있다.

final static Map<String, Supplier<Product>> map = new HashMap<>();
static {
    map.put("loan", Loan::new);
    map.put("stock", Stock::new);
    map.put("bond", Bond::new);
}

이제 Map을 이용해서 팩토리 디자인 패턴에서 했던 것처럼 다양한 상품을 인스턴스화할 수 있다.

public static Product createProduct(String name) {
    Supplier<Product> p = map.get(name);
    if(p != null) return p.get();
    throw new IllegalArgumentException("No such product " + name);
}

팩토리 패턴이 수행하던 작업을 자바 8의 새로운 기능으로 깔끔하게 정리했다.

하지만 팩토리 메서드 createProduct가 상품 생성자로 여러 인수를 전달하는 상황에서는 이 기법을 적용하기 어렵다. 단순한 Supplier 함수형 인터페이스로는 이 문제를 해결할 수 없다.

예를 들어 세 인수(Integer 두개, 문자열 하나)를 받는 상품의 생성자가 있다고 가정하자. 세 인수를 지원하려면 TriFunction이라는 특별한 함수형 인터페이스를 만들어야 한다. 결국 다음코드처럼 Map의 시그니처가 복잡해진다.

public interface TriFunction<T, U, V, R> {
    R apply(T t, U u, V v);
}
Map<String, TriFunction<Integer, Integer, String, Product>> map
    = new HashMap<>();

9.3 람다 테스팅

프로그램이 의도대로 동작하는지 확인할 수 있는 단위 테스팅을 진행해야 한다. 소스 코드의 일부가 예상된 결과를 도출할 것이라 단언하는 테스트 케이스를 구현한다.

예를 들어 다음처럼 그래픽 애플리케이션의 일부인 Point 클래스가 있다고 가정하자.

public class Point {
    private final int x;
    private final int y;
    private Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
    public int getX() { return x; }
    public int getY() { return y; }
    public Point moveRightBy(int x) {
        return new Point(this.x + x, this.y);
    }
}

다음은 moveRightBy 메서드가 의도한 대로 동작하는지 확인하는 단위 테스트다.

@Test
public void testMoveRightBy() throws Exception {
    Point p1 = new Point(5, 5);
    Point p2 = p1.moveRightBy(10);
    assertEquals(15, p2.getX());
    assertEquals(5, p2.getY());
}

9.3.1 보이는 람다 표현식의 동작 테스팅

moveRightBy는 public 이므로 위 코드는 문제없이 작동한다. 따라서 테스트 케이스 내부에서 Point 클래스 코드를 테스트할 수 있다. 하지만 람다는 익명(결국 익명 함수)이므로 테스트 코드 이름을 호출할 수 없다.

따라서 필요하다면 람다를 필드에 저장해서 재사용할 수 있으며 람다의 로직을 테스트할 수 있다. 메서드를 호출하는 것처럼 람다를 사용한다.

예를 들어 Point 클래스에 compareByXAndThenY라는 정적 필드를 추가했다고 가정하자(compareByXAndThenY를 이용하면 메서드 참조로 생성한 Comparator 객체에 접근할 수 있다).

public class Point {
    public final static Comparator<Point> compareByXAndThenY =
        comparing(Point::getX).thenComparing(Point::getY);
    ...
}

람다 표현식은 함수형 인터페이스의 인스턴스를 생성한다는 사실을 기억하자. 따라서 생성된 인스턴스의 동작으로 람다 표현식을 테스트할 수 있다.

@Test
public void testCompaingTwoPoints() throws Exception {
    Point p1 = new Point(10, 15);
    Point p2 = new Point(10, 20);
    int result = Point.compareByXAndThenY.compare(p1, p2);
    assertTrue(result < 0);
}

9.3.2 람다를 사용하는 메서드의 동작에 집중하라

람다의 목표는 정해진 동작을 다른 메서드에서 사용할 수 있도록 하나의 조각으로 캡슐화하는 것이다. 그러려면 세부 구현을 포함하는 람다 표현식을 공개하지 말아야 한다.

람다 표현식을 사용하는 메서드의 동작을 테스트함으로써 람다를 공개하지 않으면서도 람다 표현식을 검증할 수 있다.

public static List<Point> moveAllPointsRightBy(List<Point> points, int x) {
    return points.stream()
                .map(p -> new Point(p.getX() + x, p.getY()))
                .collect(toList());
}

위 코드에 람다 표현식 p → new Point(p.getX() + p.getY());를 테스트하는 부분은 없다. 그냥 moveAllPointsRightBy 메서드를 구현한 코드일 뿐이다. 이제 moveAllPointsRightBy 메서드의 동작을 확인할 수 있다.

@Test
public void testMoveAllPointsRightBy() throws Exception {
    List<Point> points = 
        Arrays.asList(new Point(5, 5), new Point(10, 5));
    List<Point> expectedPoints =
        Arrays.asList(new Point(15, 5), new Point(20, 5));
    List<Point> newPoints = Point.moveAllPointsRightBy(points, 10);
    assertEquals(expectedPoints, newPoints);
}

9.3.3 복잡한 람다를 개별 메서드로 분할하기

테스트 코드에서 람다 표현식을 참조할 수 없는데, 한 가지 해결책은 9.1.3절에서 설명한 것 처럼 람다 표현식을 메서드 참조로 바꾸는 것이다(새로운 일반 메서드 선언). 그러면 일반 메서드를 테스트하듯이 람다 표현식을 테스트할 수 있다.

9.3.4 고차원 함수 테스팅

고차원 함수

함수를 인수로 받거나 다른 함수를 반환하는 메서드

고차원 함수를 테스팅하는 것은 어렵다. 메서드가 람다를 인수로 받는다면 다른 람다로 메서드의 동작을 테스트할 수 있다. 예를 들어 프레디케이트로 만든 filter 메서드를 테스트할 수 있다.

@Test
public void testFilter() throws Exception {
    List<Integer> numbers = Arrays.asList(1, 2, 3, 4);
    List<Integer> even = filter(numbers, i -> i % 2 == 0);
    List<Integer> smallerThanThree = filter(numbers, i -> i < 3);
    assertEquals(Arrays.asList(2, 4), even);
    assertEquals(Arrays.asList(1, 2), smallerThanThree);
}

테스트해야 할 메서드가 다른 함수를 반환한다면 어떻게 해야 할까? 이때는 Comparator에서 살펴봤던 것처럼 함수형 인터페이스의 인스턴스로 간주하고 함수의 동작을 테스트할 수 있다.

9.4 디버깅

문제가 발생한 코드를 디버깅할 때 개발자는 다음 두 가지를 가장 먼저 확인해야 한다.

• 스택 트레이스
• 로깅

하지만 람다 표현식과 스트림은 기존의 디버깅 기법을 무력화한다.

9.4.1 스택 트레이스 확인

예를 들어 예외 발생으로 프로그램 실행이 갑자기 중단되었다면 먼저 어디에서 멈췄고 어떻게 멈추게 되었는지 살펴봐야 한다. 바로 스택 프레임에서 이 정보를 얻을 수 있다.

프로그램이 메서드를 호출할 때마다 프로그램에서의 호출 위치, 호출할 때의 인수값, 호출된 메서드의 지역 변수 등을 포함한 호출 정보가 생성되며 이들 정보는 스택 프레임에 저장된다.

따라서 프로그램이 멈췄다면 프로그램이 어떻게 멈추게 되었는지 프레임별로 보여주는 스택 트레이스를 얻을 수 있다. 즉, 문제가 발생한 지점에 이르게 된 메서드 호출 리스트를 얻을 수 있다.

람다와 스택 트레이스

람다 표현식은 이름이 없기 때문에 조금 복잡한 스택 트레이스가 생성된다.

다음은 고의적으로 문제를 일으키도록 구현한 코드다.

import java.util.*;

public class Debugging {
    public static void main(String[] args) {
        List<Point> points = Arrays.asList(new Point(12, 2), null);
        points.stream().map(p -> p.getX()).forEach(System.out::println);
    }
}

프로그램을 실행하면 다음과 같은 스택 트레이스가 출력된다.

Exception in thread "main" java.lang.NullPointerExceptino
    at Debugging.lambda$main$0(Debugging.java:6) //$0은 무슨 의미인가?
    at Debugging$$Lambda$5/284720968.apply(Unknown Source)
    at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
    at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
...

의도했던 대로 points 리스트의 둘째 인수가 null이므로 프로그램의 실행이 멈췄다.

스트림 파이프라인에서 에러가 발생했으므로 스트림 파이프라인 작업과 관련된 전체 메서드 호출 리스트가 출력되었다. 메서드 호출 리스트에 다음처럼 수수께끼 같은 정보도 포함되어 있다.

at Debugging.lambda$main$0(Debugging.java:6) 
at Debugging$$Lambda$5/284720968.apply(Unknown Source)

이와 같은 이상한 문자는 람다 표현식 내부에서 에러가 발생했음을 가리킨다.

람다 표현식은 이름이 없으므로 컴파일러가 람다를 참조하는 이름을 만들어낸 것이다.

메서드 참조를 사용해도 스택 트레이스에는 메서드명이 나타나지 않는다. 기존으이 람다 표현식 p → p.getX() 메서드 참조 Point::getX로 고쳐도 여전히 스택 트레이스로는 이상한 정보가 출력된다.

points.stream().map(Point::getX).forEach(System.out::println);

Exception in thread "main" java.lang.NullPointerException
    at Debugging$$Lambda$5/284720968.apply(Unknown Source)
    at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
...

메서드 참조를 사용하는 클래스와 같은 곳에 선언되어 있는 메서드를 참조할 때는 메서드 참조 이름이 스택 트레이서에 나타난다.

import java.util.*;

public class Debugging {
    public static void main(String[] args) {
        List<Integer> numbers = Arrays.asList(1, 2, 3);
        numbers.stream().map(Debugging::divideByZero).forEach(System.out::println);
    }
    // 메서드 참조를 사용하는 클래스(Debugging)과 같은 곳에 선언되어 있는 메서드
    public static int divideByZero(int n) {
        return n / 0;
    }
}

divideByZero 메서드는 스택 트레이스에 제대로 표시된다.

Exception in thread "main" java.lang.ArithmeticException: / by zero
    at Debugging.**divideByZero**(Debugging.java:10) // 스택 트레이스에 divideByZero가 보인다.
    at Debugging.$$Lambda$1/999966131.apply(Unknown Source)
    at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
...

9.4.2 정보 로깅

스트림의 파이프라인 연산을 디버깅한다고 가정했을 때, 다음처럼 forEach로 스트림 결고를 출력하거나 로깅할 수 있다.

List<Integer> numbers = Arrays.asList(2, 3, 4, 5);
numbers.stream()
        .map(x -> x + 17)
        .filter(x -> x % 2 == 0)
        .limit(3)
        .forEach(System.out::println);

다음은 프로그램 출력 결과다.

20
22

안타깝게도 forEach를 호출하는 순간 전체 스트림이 소비된다. 스트림 파이프라인에 적용된 각각의 연산(map, filter, limit)이 어떤 결과를 도출하는지 확인할 수 있다면 좋을 것이다.

이때 peek이라는 스트림 연산을 활용할 수 있다. peek은 스트림의 각 요소를 소비한 것처럼 동작을 실행한다. 하지만 forEach처럼 실제로 스트림의 요소를 소비하지는 않는다.

peek은 자신이 확인한 요소를 파이프라인의 다음 연산으로 그대로 전달한다.

다음 코드에서는 peek으로 스트림 파이프라인의 각 동작 전후의 중간값을 출력한다.

List<Integer> result =
    numbers.stream()
            // 소스에서 처음 소비한 요소를 출력한다.
            .peek(x -> System.out.println("from stream: " + x))
            .map(x -> x + 17)
            // map 동작 실행 결과를 출력한다. 
            .peek(x -> System.out.println("after map: " + x))
            .filter(x -> x % 2 == 0)
            // filter 동작 후 선택된 숫자를 출력한다. 
            .peek(x -> Systeml.out.println("after filter: " + x))
            .limit(3)
            // limit 동작 후 선택된 숫자를 출력한다. 
            .peek(x -> System.out.println("after limit: " + x))
            .collect(toList());

다음은 파이프라인의 각 단계별 상태를 보여준다.

from stream: 2
after map: 19
from stream: 3
after map: 20
after filter: 20
from stream: 4
after map: 21
from stream: 5
after map: 22
after filter: 22
after limit: 22