CHAP 09. 모든 것을 함께 사용해보자

Functional Programming in Java 8의 Chapter 9을 요약한 내용 입니다.

람다 표현식을 사용하여 컬렉션을 이터레이션하고, 더욱 경량화된 설계를 하며, 더욱 쉽게 코드를 조합하고 병렬화할 수 있었다.

함수형 스타일을 업무에 성공적으로 적용하기

자바8에서 새롭게 제공되는 개념과 패러다임은 지금까지 자바에서 사용해왔던 명령형 패러다임과 객체 지향 패러다임과는 다르다. 애플리케이션을 개발하는 방법을 어떻게 바꾸어야 하는지 기본적인 몇 가지에 대해 알아보고 그 결과로 어떤 이점을 얻을 수 있는지 확인해보자

더 서술적으로, 덜 명령적으로

코드의 한줄 한줄에 초점을 맞추기 보다는 우리가 해결해야 하는 문제, 개발해야 하는 목표를 코드로 설명할 수 있어야 한다. 이렇게 하기 위해서는 코드에 표현되어 있는 문제의 추상화 헤벨을 높여야 한다.

// 명령형 스타일
int max = 0;
for(int prce : prices) {
		if(max < price) max = price;
}

// 함수형 스타일
final int max = prices.stream()
											.reduce(0, Math::max);

몇 줄의 코드만으로 원하는 것을 얻을 수 있었다. 오류가 발생할 가능성도 훨씬 줄어들었다.

불변성의 선호

가변 변수를 사용하는 것은 좋지 않은 습관이며, 가변 변수를 공유하는 것은 잠재된 재앙이다. 가변 변수를 공유하는 코드는 올바르게 병렬화하기가 거의 불가능하다. 오류를 줄이는 방법은 가능한 가변성을 피하는 것이며 함수형 스타일을 사용하면 가변성을 쉽게 피할 수 있다.

사이드 이펙트 감소

사이드 이펙트가 없는 함수는 다른 함수나 메서드에게 영향을 주지 않으며 함수밖의 어떤 것에도 영향을 주지 않는다. 사이드 이펙트가 존재하는 함수나 메서드는 이해하기 어렵고, 유지 보수도 어려우며, 오류가 발생할 확률이 높고 더 나아가 병렬화하기가 쉽지 않다.

사이드 이펙트가 없다는 것은 참조 투명성 측면에서 중요하다. 이 뜻은 함수에 대한 호출이 프로그램의 결과에 영향을 미치지 않고 함수를 호출하는 부분을 함수의 결괏값으로 대체하더라도 실행하고 결과를 얻는 데는 전혀 문제가 없다는 의미이다.

람다 표현식을 사용할 때, 코드에 사이드 이펙트가 없다는 것을 보장해야 한다. 이렇게 하는 것은 오류의 발생 가능성을 낮추기도 하지만 코드를 쉽게 병렬화해주기도 한다.

문장보다 표현식으로

문장은 액션을 수행하지만 아무것도 리턴하지 않고, 반면에 표현식은 액션을 수행하고 결과를 리턴한다. 람다 표현식을 사용하여 프로그래밍할 때 문장보다는 표현식을 생성하여 사용하는 것이 많은 이점을 얻을 수 있다. 그 이유를 살펴보자

• 문장은 아무것도 리턴하지 않기 때문에, 사이드 이펙트를 발생하거나 메모리를 이상한 값으로 채울 수 있다.

• 문장과 달리 표현식은 두 개 이상의 표현식을 하나로 조합하여 사용할 수 있다

고차 함수를 사용한 설계

자바8에서 우리가 해야 하는 가장 큰 수정은 고차 함수를 사용하여 설계를 해야 한다는 점이다. 지금까지는 메서드에 객체를 넘기는 방법을 사용해왔지만, 이제는 매개변수로 함수를 넘기는 기능을 사용할 수 있다. 이러한 기술은 코드를 좀 더 간결하게 만들어준다.

// 익명 클래스를 사용한 예
button.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent event) {
        JOptionPane.showMessageDialog(frame, "you clicked!");
    }
});

// 람다 표현식을 사용한 예
button.addActionListener(event -> JOptionPane.showMessageDialog(frame, "you clicked!"));

함수형 스타일의 적용

새로운 문법을 선택하는 것은 상대적으로 쉽지만, 설계 방법이나 생각하는 방법을 바꾸는 것은 훨씬 많은 노력이 필요하다. 자바에서 함수형 스타일로 프로그래밍하는 것은 패러다임을 바꾸는 것이다. 이러한 패러다임 변화의 출발점에서 가장 익숙한 방법으로 생각해보는 것은 자연스러운 것이다.

우리가 하고 있는 것을 더 잘하기 위해서는 우리의 방법을 바꿔야 한다. 이 말은 아이디어를 시도해보고 동료들의 피드백을 통해 그 아이디어를 더 발전시켜 나가야 한다는 말이다. 직장 내에서의 코드 리뷰, 동료들 간의 프로그래밍 세션, 그리고 점심시간의 잡담을 통해서도 많은 도움을 얻을 수 있다.