[자바 코딩의 기술] 8장 : 데이터 흐름

8장에서는 자바 함수형 프로그램의 핵심 개념을 설명하겠다.

 

- 함수형 방식이 명령형 방식을 월등히 능가하는 경우.

- 익명 클래스를 명쾌하게 대체하는 방법

- 자료 구조를 더 효율적으로 순회하는 방법

- 옵셔널로 프로그램을 덜 취약하게 만드는 방법

8.1 익명 클래스 대신 람다 사용하기

문제 코드

class Calculator {

    Map<Double, Double> values = new HashMap<>();

    Double square(Double x) {
        Function<Double, Double> squareFunction =
                new Function<Double, Double>() {
                    @Override
                    public Double apply(Double value) {
                        return value * value;
                    }
                };
        return values.computeIfAbsent(x, squareFunction);
    }
}

위 코드는 익명 클래스를 이용해서 Function<Double, Double> 인터페이스를 구현하고 있다.

-> 이러한 익명 클래스는 코드량을 늘리고 타입과 메서드를 반복하며 실제 연산이외의 것들이 장황하게 펼쳐진다.

 

자바 8에서는 익명 클래스 대신 "람다 표현식"으로 코드를 향상시킬 수 있다.

개선 코드

class Calculator {

    Map<Double, Double> values = new HashMap<>();

    Double square(Double value) {
        Function<Double, Double> squareFunction = factor -> factor * factor;
        return values.computeIfAbsent(value, squareFunction);
    }
}

Function<Double, Double> squareFunction = factor -> factor * factor;

처럼 람다식으로 표현했더니 연산 로직이 바로 보이며 코드가 간결해졌다.

 

람다는 함수형 인터페이스, 즉 단일 추상 메서드(SAM)를 포함하는 인터페이스를 구현.

위 예제에서는 Function 인터페이스가 apply() 추상 메서드만 포함하니 람다와 들어맞는다.

 

람다는 아래 처럼 한 줄 또는 여러 줄로 작성 가능하다.

        // single
        Function<Double, Double> squareFunction = factor -> factor * factor;
        
        //  multi-liner
        Function<Double, Double> squareFunction = factor -> {
            return factor * factor;

8.2 명령형 방식 대신 함수형

컬렉션 처리에 대해서는 함수형 프로그래밍 방식이 명령형 방식보다 읽기 쉽다.

문제 코드

class Inventory {

    List<Supply> supplies = new ArrayList<>();

    long countDifferentKinds() {
        List<String> names = new ArrayList<>();
        for (Supply supply : supplies) {
            if (supply.isUncontaminated()) {
                String name = supply.getName();
                if (!names.contains(name)) {
                    names.add(name);
                }
            }
        }
        return names.size();
    }
}

명령형 방식은 무엇을 해야하는지 어떻게 해야하는지 모든 명시적으로 코드를 작성합니다.

 

하지만 메서드의 의도를 확실히 들어내려면 어떻게는 하는지는 빼고 무엇을 하는지만 명시하면 된다.

람다로 무엇이 이루어지길 원하는지만 명시할 수 있다.

개선 코드

class Inventory {

    List<Supply> supplies = new ArrayList<>();

    long countDifferentKinds() {
        return supplies.stream()
                       .filter(supply -> supply.isUncontaminated())
                       .map(supply -> supply.getName())
                       .distinct()
                       .count();
    }
}

1. stream() 컬렉션을 스트림으로 변환 (컬렉션 내 각 원소 참조 가능)
2. filter()를 통해 오염된 원소 걸러냄 (일종의 관문)
3. 각 원소를 변환한다. (어떤 함수가 타입을 다른 타입으로 매핑 // supply에서 .getName()으로)
4. dinstnct()로 중복 걸러 내기
5. count()로 남은 갯수 세기

8.3 람다 대신 메서드 참조

람다 표현식을 사용하면 코드가 읽기 편해진다.

하지만 스트림 중간부터 실행할 수 없고 오직 스트림 전체에 대해서만 실행할 수 있다. (일부만 테스트 하기 어렵다)

 

만약, 람다표현식이 복잡해지고 논리가 많아지면 오류 가능성이 높아지는데 참조가 불가능해 단위 테스트도 안되니 기대대로 동작하는 지 검증할 수 도 없다.

 

자바의 함수형 프로그래밍에서도 메서드 참조를 사용하면 메서드 호출을 람다 표현식에 끼워 넣을 수 있고 품질 보증이 쉬워진다.

개선 코드

class Inventory {

    List<Supply> supplies = new ArrayList<>();

    long countDifferentKinds() {
        return supplies.stream()
                       .filter(Supply::isUncontaminated)
                       .map(Supply::getName)
                       .distinct()
                       .count();
    }
}

일반적인 람다 표현식 대신 미리 정의된 메서드를 스트림 내에서 바로 참조하면 된다.

 

이렇게 하면 메서드 각각을 호출할 수 있고 부정 피하기문제도 해결할 수 있다.

8.4 부수 효과 피하기

함수형 프로그래밍은 입력을 데이터로 받아 출력으로 새루운 데이터를 생성하는 함수이므로 데이터는 불변이다. 따라서 부수 효과(side effect)가 없다.

 

하지만 명령형과 객체 지향 프로그래밍은 데이터를 바꾸므로 부수 효과에 의존한다.

자바는 현재 세 가지 방식을 모두 사용하므로 강력하지만 오류가 발생하기도 쉽다. 따라서 코드 내 부수효과를 최소화하는 방법을 알아야 한다.

문제 코드

class Inventory {

    List<Supply> supplies = new ArrayList<>();

    long countDifferentKinds() {
        List<String> names = new ArrayList<>();

        Consumer<String> addToNames = name -> names.add(name);

        supplies.stream()
                .filter(Supply::isUncontaminated)
                .map(Supply::getName)
                .distinct()
                .forEach(addToNames);
        return names.size();
    }
}

스트림의 forEach() 부분에서 addToNames를 호출하는데 이는 람다 표현식 밖에 있는 리스트에 원소를 추가한다.

-> 이때 부수효과가 발생한다.

 

코드가 기능상에 오류는 없지만 동시 실행이 가능하도록 바꾸면 쉽게 고장이난다. (자바는 여러 스레드 간 부수효과 발생에 대해 보장하지 않으므로)

 

그러면 "부수효과"를 일으키지 않으면서 람다 표현식을 종료하려면 어떻게 해야 할까?

개선 코드

class Inventory {

    List<Supply> supplies = new ArrayList<>();

    long countDifferentKinds() {
        List<String> names = supplies.stream()
                                     .filter(Supply::isUncontaminated)
                                     .map(Supply::getName)
                                     .distinct()
                                     .collect(Collectors.toList());
        return names.size();
    }
}

위 코드에서 가장 중요한 부분은 람다 표현식에서 생성하는 리스트이다.

리스트를 직접 만들지 않고 컬렉션 내 스트림에 남아 있는 각 원소를 collect() 했다.

 

이때 리스트를 만들기 위해서는 collect(Collectors.toList());로 스트림을 종료해야만 한다.
(Collectors.toSet()하면 Set 자료구조로 만듬)

 

**요약**

- 스트림을 종료시킬 때 forEach()는 부수효과를 일으키니 가능하면 쓰지말자

- collect()와 reduce()를 쓰려고 하자. (스트림 직접 종료 + 원하는 자료구조 생성 가능)

8.5 복잡한 스트림 종료 시 컬렉트 사용하기

복잡한 스트림 종료 시에 부수효과를 피하는 방법을 익혀보자..

 

우리가 원하는 데이터는
supplies 리스트 내 고유 원소 수를 모두 세는 대신 남은 제품 수를 이름별로 묶어 계산하는 Map<String, Long>형태를 만들기를 원한다.

 

쿼리로 생각하자면 'SELECT name, count(*) FROM supplies GROUP BY name;'이라고 볼 수 있다.

문제 코드

class Inventory {

    List<Supply> supplies = new ArrayList<>();

    Map<String, Long> countDifferentKinds() {
        Map<String, Long> nameToCount = new HashMap<>();

        Consumer<String> addToNames = name -> {
            if (!nameToCount.containsKey(name)) {
                nameToCount.put(name, 0L);
            }
            nameToCount.put(name, nameToCount.get(name) + 1);
        };

        supplies.stream()
                .filter(Supply::isUncontaminated)
                .map(Supply::getName)
                .forEach(addToNames);
        return nameToCount;
    }
}

개선 코드

class Inventory {

    List<Supply> supplies = new ArrayList<>();

    Map<String, Long> countDifferentKinds() {
        return supplies.stream()
                       .filter(Supply::isUncontaminated)
                       .collect(Collectors.groupingBy(Supply::getName,
                               Collectors.counting())
                       );
    }
}

스트림의 결과를 Collection으로 만들어야 할 경우 우리는 Collectors를 이용해 원하는 자료구조 형태로 만들 수 있다. (toList(), toSet(), toMap())

 

위 코드에서는 Collectors.groupingBy() 연산자를 Supply 인스턴스의 스트림에 적용한다. 이 연산자는 Map자료구조를 반환한다.

그룹핑바이의 첫번째 인자로는 키 타입에 해당하는 string, 두번째 인자로는 갯수인 Long을 넣어준다.

 

그러면 우리가 원하는 이름별 항목 수인 Map<String, Long>이 결과로 반환된다.

 

collect() 방식이 문제 코드 보다 훨씬 간결하고 요점을 잘 전달하며 심지어 SQL 쿼리 처럼 읽힌다.

Collectors는 이외에도 joining(), maxBy() 등 많은 기능을 제공하고 있다.

8.6 스트림 내 예외 피하기

문제 코드

class LogBooks {

    static List<LogBook> getAll() throws IOException {
        return Files.walk(Paths.get("/var/log"))
                    .filter(Files::isRegularFile)
                    .filter(LogBook::isLogbook)
                    .map(path -> {
                        try {
                            return new LogBook(path);
                        } catch (IOException e) {
                            throw new UncheckedIOException(e);
                        }
                    })
                    .collect(Collectors.toList());
    }
}

문제코드를 보면 예외를 처리하는 방식이 매우 복잡하고 좋아보이지 않는다.

 

그렇다면 함수형 프로그래밍에서는 어떻게 예외를 처리해야 할까?

개선 코드

class LogBooks {

    static List<LogBook> getAll() throws IOException {
        try (Stream<Path> stream = Files.walk(Paths.get("/var/log"))) {
            return stream.filter(Files::isRegularFile)
                         .filter(LogBook::isLogbook)
                         .flatMap(path -> {
                             try {
                                 return Stream.of(new LogBook(path));
                             } catch (IOException e) {
                                 return Stream.empty();
                             }
                         })
                         .collect(Collectors.toList());
        }
    }
}

여전히 try-catch문을 사용하지만 flatMap()을 사용한다.

이를 통해 어떤 타입을 다른 타입의 Stream으로 매핑한다. 문제가 발생하면 단지 Stream.empty()를 반환한다.

 

예외를 피하려면 함수형 방식을 따르세요..

8.7 널 대신 옵셔널

객체를 가르키지 않는 참조는 null을 가르킨다. null 참조로 메서드를 참조하면 NullPointerException이 발생한다.

 

자바 8과 람다 표현식의 등장 이후 기존의 널 보호 이외의 널 객체를 해결할 다른 방법이 생겼다.

 문제 코드

class Communicator {

    Connection connectionToEarth;

    void establishConnection() {
        // used to set connectionToEarth, but may be unreliable
    }

    Connection getConnectionToEarth() {
    	
        return connectionToEarth;
    }
}

기존에는 if 문을 추가해 null인지 아닌지 검증했을 것이다. 하지만 if 문을 사용하면 람다 표현식을 조합해서 사용하기란 불가능하다.

자바는 더 좋은 방법을 사용하고 있다.

 

개선 코드

    static void main2() {
        Communicator communicationSystem = new Communicator();

        communicationSystem.getConnectionToEarth()
                            .ifPresent(connection ->
                                connection.send("Houston, we got a problem!")
                            );
    }

자바는 connectionToEarth가 없을 수도 있따는 것을 "Optional"을 통해서 명시한다. Optional에는 객체가 null일수도 있고 아닐수도 있다.

 

이렇게 사용함으로써 얻을 수 있는 이점은 호출자가 null값을 어떻게 처리할 지 생각해볼 수 있게한다는 점이다.

여전히 예외는 발생할 수 있지만 호출자가 이를 적절히 해결할 수 있게 해준다.

 

8.8 선택 필드나 매개변수 피하기

문제 코드

class Communicator {

    Optional<Connection> connectionToEarth;
    
    void setConnectionToEarth(Optional<Connection> connectionToEarth) {
        this.connectionToEarth = connectionToEarth;
    }
    Optional<Connection> getConnectionToEarth() {
        return connectionToEarth;
    }
}

필드나 매개변수에 옵셔널 타입을 사용하면 안된다. 이는 코드를 더 복잡해지게 만들 뿐이다.

옵셔널은 '부재'와 '존재'의 상태를 가지는데 이 옵셔널이 null이면 더 부재하다는 뜻인가..? 아무튼 이해 안됨.. 아무튼 쓰면 헷갈림

만약, 필드와 메서드 매개변수 타입에서 Optional을 사용했다면 제거해라. 그리고 오직 반환값에서만 사용해라.

개선 코드

class Communicator {

    Connection connectionToEarth;

    void setConnectionToEarth(Connection connectionToEarth) {
        this.connectionToEarth = Objects.requireNonNull(connectionToEarth);
    }
    Optional<Connection> getConnectionToEarth() {
        return Optional.ofNullable(connectionToEarth);
    }

    void reset() {
        connectionToEarth = null;
    }
}

8.9 옵셔널을 스트림으로 사용하기

옵셔널은 null을 훌륭히 대체할 수 있다. 뿐만 아니라 자바 내 람다 표현식에 옵셔널 클래스를 추가하면 좋다.

=> Optional은 0개 또는 1개 원소만 포함하는 특별한 형식의 스트림이다.

 

옵셔널이 스트림이기 때문에 filter(), map()과 같은 일반적인 스트림 연산을 바로 적용할 수 있다.

문제 코드

class BackupJob {

    Communicator communicator;
    Storage storage;

    void backupToEarth() {
        Optional<Connection> connectionOptional =
                communicator.getConnectionToEarth();
        if (!connectionOptional.isPresent()) {
            throw new IllegalStateException();
        }

        Connection connection = connectionOptional.get();
        if (!connection.isFree()) {
            throw new IllegalStateException();
        }

        connection.send(storage.getBackup());
    }
}

위 코드는 어느 부분이 보기 좋지 않을까?

 

옵셔널은 명령형이 아닌 함수형 프로그래밍을 위해 만들어졌다.

따라서 두 방식 간에 변환을 위해 위 코드에서도 get() 같은 메서드로 변환이 수행된 것을 확인할 수 있다.

이러한 문맥교환이 없어지면 좀 더 코드를 향상시킬 수 있다.

개선 코드

class BackupJob {

    Communicator communicator;
    Storage storage;

    void backupToEarth() {
        Connection connection = communicator.getConnectionToEarth()
                .filter(Connection::isFree)
                .orElseThrow(IllegalStateException::new);
        connection.send(storage.getBackup());
    }
}

함수형으로 작성시 옵셔널 클래스에 들어있는 메서드를 사용할 수 있다.

filter(), map(), flatMap()과 같은 스트림 중간 연산과 orElse(), orElseThrow(), orElseet(), ifPresent()를 활용할 수 있다.

 

**실행 흐름**

1. filter()를 사용해 연결이 이어져있고 사용할 수 있는지 확인
2. 연결할 수 없다면 예외 발생
3. 연결 가능하므로 send() 실행

함수형으로 작성하면 기존의 명령형보다 코드가 간결해지고 실행 흐름을 이해하기 쉬워진다.

8.10 8장에서 배운 내용

함수형 방식은 자바를 새롭게 프로그래밍 할 수 있는 방식이다.

익숙해지려고 노력하자.

메서드 참조, 옵셔널, 람다 표현식 등을 적극 활용하자.