#09장 리팩토링, 테스팅, 디버깅

Raoul-Gabriel Urma 저, 우정은 역 「Modern Java in Action, 2019」를 읽고 정리하였습니다.

9장 요약

• 람다식은 가독성있고 유연하다.

• 익명 클래스에서 람다로 바꿀시 this, 변수 섀도 등 주의해야 한다.

• 메서드 참조 사용하면 람다보다 가독성 증가한다.

• 람다식은 흔한 객체지향 디자인 패턴에서 발생하는 boilerplate를 제거가능하다.

• 복잡한 람다식은 일반 메서드로 구현할 수 있다.

• 람다식을 사용하면 스택 트레이스를 이해하기 어려워진다.

• 파이프라인 연산시 디버깅은 peek를 사용한다.

이장에서 다룰 내용

• Refactoring code to use lambda expressions

• Appreciating the impact of lambda expressions on object-oriented design patterns

• Testing lambda expressions

• Debugging code that uses lambda expressions and the Streams API

9.1 Refactoring for improved readability and flexibility

Readability

• readability를 위해 보여줄 리팩토링 순서

  • anonymous classes to lambda expressions

  • lambda expressions to method references

  • imperative-style data processing to streams

anonymous classes to lambda expressions

// BEFORE
Runnable r2 = new Runnable(){
	public void run(){
		System.out.println("hello world!");
	}
};

// AFTER
Runnable r1 = () -> {
	System.out.println("hello world!"); 
};

• 전환시 주의

  1. this와 super의 의미는 익명 클래스와 람다식에서 다르고, 익명 클래스 안에서 변수는 enclosing하는 클래스의 변수를 섀도잉할 수 있다.

  2. 오버로딩 면에서 결과 코드가 모호해질 수 있습니다.

// 주의 1. this와 super의 의미는 익명 클래스와 람다식에서 다르고, 익명 클래스 안에서 변수는 enclosing하는 클래스의 변수를 섀도잉할 수 있다.
// 1.1 
int a = 10;
Runnable r1 = () -> {
	int a = 2; // 람다에선 바깥 a가 안에 까지 영향 (컴파일 error)
	System.out.println(a); 
};
// 1.2 
int a = 10;
Runnable r2 = new Runnable(){
	public void run(){
		int a = 2; // 익명 클래스 안에서는 똑같은 변수명 사용해도 상관 x (쉐도잉 가능)
		System.out.println(a);
	}
};
// ----------------------------------------------
// 주의 2. 오버로딩 컨텍스트에서 결과 코드가 모호해질 수 있습니다.

// functional interface와 두 메소드 정의
interface Task { 
	public void execute();
}
public static void doSomething(Runnable r){ r.run(); }
public static void doSomething(Task a){ r.execute(); }

// 익명 클래스 사용시 문제가 없다. 
doSomething(new Task() {
	public void execute() {
		System.out.println("Danger danger!!");
	}
});

// 하지만, 람다 사용시 모호한 호출이 발생 -> 2개의 doSomething이 타겟으로 잡힘 
doSomething(() -> System.out.println("Danger danger!!"));

// explicit cast로 해결이 가능 
doSomething((Task)() -> System.out.println("Danger danger!!"));

// 결론, IDE가 이런것은 잡아주니 걱정 No

lambda expressions to method references

// 예제 1
// BEFORE
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;
 })
);

// AFTER
Map<CaloricLevel, List<Dish>> dishesByCaloricLevel =
	menu.stream().collect(groupingBy(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;
 }
}
// ----------------------------------------------
// 예제 2
// BEFORE
inventory.sort((Apple a1, Apple a2) -> a1.getWeight().compareTo(a2.getWeight()));
// AFTER
inventory.sort(comparing(Apple::getWeight)); // using helper static methods -> 람다보다 간결 
// ----------------------------------------------
// 예제 3
// BEFORE
int totalCalories = menu.stream().map(Dish::getCalories).reduce(0, (c1, c2) -> c1 + c2);
// AFTER
int totalCalories = menu.stream().collect(summingInt(Dish::getCalories)); // summingInt -> built-in helper methods 사용

imperative data processing to Streams

• imperative data를 Streams으로 바꾸는 것은 어려운 작업이다. (break, continue 같은 control-flow를 고려해야기 때문에)

// 예제 3
// BEFORE
// filtering and extracting이 들어간 코드 
List<String> dishNames = new ArrayList<>();
for(Dish dish: menu) {
 if(dish.getCalories() > 300){
	 dishNames.add(dish.getName());
 }
}

// AFTER
List<String> dishNames = menu.parallelStream()
 .filter(d -> d.getCalories() > 300)
 .map(Dish::getName)
 .collect(toList());

Flexibility

• behavior parameterization

• functional interfaces 없이는 람다를 사용할 수 없다.

• 2가지 코드 패턴

  • conditional deferred execution 패턴

  • execute around 패턴

• 이외에, 람다와 간결히 사용될 수 있는 strategy and template-method design patterns 도 다룰 예정

// 1 CONDITIONAL DEFERRED EXECUTION 패턴 
// 예제: 보안 검사 및 로깅와 같은 시나리오에서 조건문이 엉망이 되는 경우
// 문제가 되는 이유: isLoggable 메소드에 의해 클라이언트 코드에 노출
// 문제가 되는 이유: 메시지를 기록하기 전에 로거 logger의 상태를 매번 확인해야 될까?, 코드 복잡 
if (logger.isLoggable(Log.FINER)) {
 logger.finer("Problem: " + generateDiagnostic());
}

// 더나은 코드
// 메시지를 기록하기 전, logger 개체 내부에서 올바른 수준으로 설정되었는지 확인한다.
// 하지만, 여전히 문제점 있다. 로거가 활성화되지 않은 경우에도 항상 평가한다.
logger.log(Level.FINER, "Problem: " + generateDiagnostic());

// 자바 8 API에서 해결한 방식: Supplier 함수형 인터페이스 사용하고, 람다로 전달
// 내부적으로 객체의 상태를 확인한 다음에 메서드를 호출하도록 해준다. (클라이언트 코드에서 개체의 상태를 노출 X)
logger.log(Level.FINER, () -> "Problem: " + generateDiagnostic());

public void log(Level level, Supplier<String> msgSupplier) {
 if(logger.isLoggable(level)){
	 log(level, msgSupplier.get());
 }
}
// ----------------------------------------------
// 2 EXECUTE AROUND 패턴
// 동일한 준비 및 정리 단계로 다른 코드를 둘러싸고 있다면 람다로 (코드 중복 제거 가능)
// 파일을 열고 닫는 로직
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);
 }
}

public interface BufferedReaderProcessor { // 함수형 인터페이스
 String process(BufferedReader b) throws IOException;
}

// 이렇게 함수형 인터페이스에 람다는 항상 동행한다. 

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

• 람다 사용으로, 흔한 객체 지향 패턴에서 boilerplate code를 제거 가능

• 다룰 디자인 패턴 (객체지향에서 주로 사용하는)

  • Strategy: 클래스 동작이나 알고리즘은 런타임에 변경 가능

  • Template method: 추상 클래스는 메서드를 실행하기 위해 템플릿(정의들)을 노출

  • Observer: 변경이 있으면 옵저버에게 전파

  • Chain of responsibility: 리시버 체인을 생성을 생서하고, 송신자와 수신자를 decouple 시켜줄 수 있다. 일반적으로 각 수신기는 다른 수신기에 대한 참조를 가져, 한 객체가 요청을 처리할 수 없으면, 다음 수신자에게 전달하는 방식으로 처리한다.

  • Factory: 부모 인터페이스를 사용해, 클라이언트에게 안의 (구현체나) 로직 노출 없이, 객체 생성 가능

• 디자인 패턴이 가진 문제에 대한 솔루션을 제공 가능하다.

// 1 Strategy
// 코드 요약: 텍스트 유효성 검사 코드 (모두 소문자인지 or 모두 숫자인지)
// ValidationStrategy 인터페이스를 만들고, 그를 구현한 2개 클래스. 
// Validator의 validate 인자에 따라 2개 클래스 중 실행.
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()); // IsNumeric 전략 사용
boolean b1 = numericValidator.validate("aaaa"); // false
Validator lowerCaseValidator = new Validator(new IsAllLowerCase ()); // IsAllLowerCase 전략 사용
boolean b2 = lowerCaseValidator.validate("bbbb");  // true

// 람다로 교체시
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");
// 이전 장에도 토의하듯이, 아마도, IsAllLowerCase나 IsNumeric이 자주 사용되는 코드면 class로 구현해도 될것 같음...
// ----------------------------------------------
// 2 Template method
// 코드 요약: 지점 마다 고객을 행복하게 로직 실행하게 한다. (지점마다 고객을 만족시키는 방법이 다르다고 가정)
// 지점마다 OnlineBanking를 구현하여 makeCustomerHappy를 오버라이딩을 강제하는 템플릿.
	abstract class OnlineBanking {
	public void processCustomer(int id){
		Customer c = Database.getCustomerWithId(id);
		makeCustomerHappy(c);
	}
	abstract void makeCustomerHappy(Customer c);
}

// 람다 사용시
// 람다 사용을 위해 OnlineBanking의 processCustomer 메소드 변경.
// Consumer 함수형 인터페이스를 사용하여, 람다로 간단하게 넘기도록 한다. (이제 subclassing 필요 x)
public void processCustomer(int id, Consumer<Customer> makeCustomerHappy) {
	Customer c = Database.getCustomerWithId(id);
	makeCustomerHappy.accept(c); 
}

new OnlineBankingLambda().processCustomer(1337, (Customer c) -> System.out.println("Hello " + c.getName());
// ----------------------------------------------
// 3 Observer
// 코드 요약: 피드를 올리면, 뉴스 회사들이 이를 가져가 자기네 방식대로 프린트 한다.
// Observer 인터페이스 생성 후, 3개 구현체(NYTimes, Guardian, LeMonde) 생성 
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 인터페이스 생성 후, 옵저버들을 관리해줄 Feed 클래스가 구현 
interface Subject {
	void registerObserver(Observer o);
	void notifyObservers(String tweet);
}
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에 관찰자 등록 후, notify 실행
Feed f = new Feed();
f.registerObserver(new NYTimes());
f.registerObserver(new Guardian());
f.registerObserver(new LeMonde());
f.notifyObservers("The queen said her favourite 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);
 }
});

// ----------------------------------------------
// 4 Chain of responsibility -> 헬갈린다...
// 코드 요약: 인풋 스트링을 원하도록 출력을 위해, 여러 종류의 처리기(헤더 추가와 스펠링 체크기)를 만들어, 제공한다. 여기선, 스펠링 체크를 먼저하고, 헤더를 붙이는 체이닝을 구성한다. 
// 추상클래스 ProcessingObject에서 하위 클래스의 handleWork 구현을 강요해, 공통 로직을 실행한다.
public abstract class ProcessingObject<T> {
	protected ProcessingObject<T> successor;
	public void setSuccessor(ProcessingObject<T> successor){
		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);
}

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?!!

// 람다 사용시
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); // andThen 으로 체이닝
String result = pipeline.apply("Aren't labdas really sexy?!!");

// ----------------------------------------------
// 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);
	}
 }
}
Product p = ProductFactory.createProduct("loan"); // 스트링 인자인 "loan"을 요청하니 공장에서 Loan 객체를 만들어 보내준다.

// 람다 사용시
// 간단히 Loan 객체 생성한고 했을때
Supplier<Product> loanSupplier = Loan::new;
Loan loan = loanSupplier.get();

// 이렇게 맵을 만들어서 처리도 가능
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);
}

public static Product createProduct(String name){
	Supplier<Product> p = map.get(name); // loan이 들어오면 맵에서 Loan::new 메서드 참조를 가져온다. 
	if(p != null) return p.get(); // Supplier.get을 사용해 Loan 객체 생성 
	throw new IllegalArgumentException("No such product " + name);
}

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);
	}
}
// ----------------------------------------------
// 예제 1: 일반적인 유닛 테스트 작성법 
// 스크린에서 포인트 이동 시스템
// moveRightBy는 public 이므로 잘 작동한다. 
@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());
}
// ----------------------------------------------
// 예제 2: 보이는 람다 표현식의 동작 테스팅 
public class Point {
	//...
	// 정적 필드 추가
	public final static Comparator<Point> compareByXAndThenY =
		 comparing(Point::getX).thenComparing(Point::getY);
	//...
}

@Test
public void testComparingTwoPoints() throws Exception {
	Point p1 = new Point(10, 15);
	Point p2 = new Point(10, 20);
	int result = Point.compareByXAndThenY.compare(p1 , p2);
	assertTrue(result < 0);
}
// ----------------------------------------------
// 예제 3: 람다를 사용하는 메서드의 동작에 집중하라. 
public static List<Point> moveAllPointsRightBy(List<Point> points, int x) {
	return points.stream()
		.map(p -> new Point(p.getX() + x, p.getY()))
		.collect(toList());
}

@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); // Point 클래스의 eqauls를 사용하니, 작성 잘하기.
}
// ----------------------------------------------
// 예제 3: higher-order function 테스팅. (고차원 함수란, 함수를 인수로 받거나 다른 함수를 반환하는 메서드)
@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);
}

9.4 Debugging

• 테스팅에서 람다식에 문제가 있을 경우, 어떻게 디버깅을 해야할까?

  • 보통 먼저 스택 트레이스, 로깅 확인하지만, 람다식이나 스트림은 안 먹힌다...

아래 예제 요약: 람다나 메서드 참조 사용시, 람다를 사용하거나 외부 메서드를 사용하는 메서드 참조는 디버깅이 안된다. 다만, 메서드 참조에서, 동일 클래스 내에 메서드 호출이면 디버깅 가능해진다.

// 예제 1: 람다 사용시 디버깅 어려움. 
public class Debugging {
	public static void main(String[] args) {
		List<Point> points = Arrays.asList(new Point(12, 2), null); // 에러가 나게, null을 넣었다.
		points.stream().map(p -> p.getX()).forEach(System.out::println); // 여기 람다는 디버깅에 문제가 될수 있따. 
	}
}

// 결과 
// 스택트레이스의 암호같은 설명
// 클래스에 여러 람다가 있으면 골치가 아플때가 있다. 
Exception in thread "main" java.lang.NullPointerException
 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)

// 예제 2: 메서드 참조 사용시도 디버깅 어려움. 
// 람다에서 메서드 참조로 변경해도, 디버깅이 어렵다는 사실은 바뀌지 않는다. 
public static void main(String[] args) {
	//...
	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)
// ----------------------------------------------
// 예제 3: 다만, 람다나 메서드 참조에서 사용하는 메서드가 "동일 클래스 메서드일 경우" 디버깅 가능. 
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);
	}
	public static int divideByZero(int n){
		return n / 0;
	}
}

// 결과 
// 어디 메서드에서 문제가 나는지 명확히 확인 가능 
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)

• 스트림의 파이프라인 연산을 디버깅하고 싶다면?

• 파이프라인 연산 디버깅 = peek()

// 주어진 리스트에서 17을 더하고 2의 배수들만 출력. (단, 앞에 최대 3개까지만 출력)
//
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

// 만약 map, filter, limit 연산 후 결과들이 각각 어떻게 나오는지 보고 싶다면?
// peek 사용!
List<Integer> numbers = Arrays.asList(2, 3, 4, 5);
List<Integer> result =
numbers.stream()
    .peek(x -> System.out.println("from stream: " + x))
    .map(x -> x + 17)
    .peek(x -> System.out.println("after map: " + x))
    .filter(x -> x % 2 == 0)
    .peek(x -> System.out.println("after filter: " + x))
    .limit(3)
    .peek(x -> System.out.println("after limit: " + x))
    .collect(Collectors.toList());

// 결과
// 2랑 4는 filter에서 멈춘다. 
from stream: 2
after map: 19

from stream: 3
after map: 20
after filter: 20
after limit: 20

from stream: 4
after map: 21

from stream: 5
after map: 22
after filter: 22
after limit: 22