공부 기록

디폴트 메서드를 선언하면, 그 인터페이스를 구현한 후 디폴트 메서드를 재정의하지 않은 모든 클래스에서 디폴트 구현이 쓰이게 된다.

디폴트 메서드 덕분에 자바에도 기존 인터페이스에 메서드를 추가할 수 있게 되었다. 하지만 모든 기존 구현체들과 매끄럽게 연동된다는 보장은 없다. 왜냐면 자바 7까지는 인터페이스에 새로운 메서드가 추가될 것을 고려하지 않았기 때문이다. 

자바 8에서는 핵심 컬렉션 인터페이스들에 다수의 디폴트 메서드가 추가되었다. 주로 람다를 활용하기 위해서이다.(7장 참조)

(디폴트 메서드는 불변식을 해치지 않아야 함)

자바 8의 Collection 인터페이스에 추가된 removelf 디폴트 메서드를 보자.

이 메서드는 주어진 predicate가 true를 반환 하면 원소를 제거하는 구조이다. 디폴트 구현은 반복자를 이용해 순회하면서 각 원소를 인수로 넣어 predicate를 호출하고, predicate가 true를 반환하면 반복자의 remove 메서드를 호출해 그 원소를 제거한다.

• Predicate - 인수로 값을 받아 boolean 값을 반환하는 함수로, 람다나 스트림은 제네릭 형태를 사용하는데, Predicate 를 사용하게 되면 boolean을 Boolean으로 변환하는 과정이 없어 더 효율적이다.

위 코드는 범용적으로 구현한 형태이지만 모든 Collection 구현체와 잘 어우러지는 것은 아니다.

org.apache.commons.collections.collection.SynchronizedCollection 를 살펴보자.

// org.apache.commons.collections.collection.SynchronizedCollection: 모든 메서드에서 주어진 락 객체로 동기화한 후 내부 컬렉션 객체에 기능을 위임하는 래퍼 클래스(아이템 18)
public class SynchronizedCollection implements Collection, Serializable {
    private static final long serialVersionUID = 2412805092710877986L;
    protected final Collection collection;
    protected final Object lock; // 아파치 버전은 컬렉션 대신 클라이언트가 제공한 객체로 락을 거는 능력을 추가로 제공
    ...
}

아파치의 SynchronizedCollection 클래스에는 removelf 메서드를 재정의하지 않고 있다.

이 클래스를 자바 8과 함께 사용해서 removelf 의 디폴트 구현을 물려받게 된다면 모든 메서드 호출을 알아서 동기화해주지 못한다.

인터페이스에서 디폴트 메서드로 정의된 removelf은 동기화에 관해 아무것도 모르기 때문에 락 객체를 사용할 수 없다.

=> SynchronizedCollection 인스턴스를 여러 스레드가 공유하는 환경에서 한 스레드가 removelf를 호출하면 ConcurrentModificationException이 발생하거나 다른 예기치 못한 결과로 이어질 수 있다.

자바 플랫폼 라이브러리에서는 이런 문제를 예방하기 위해 구현한 인터페이스의 디폴트 메서드를 재정의하고, 다른 메서드에서는 디폴트 메서드를 호출하기 전에 필요한 작업을 수행하도록 했다. 예컨대 Collections.SynchronizedCollection이 반환하는 package-private 클래스들은 removelf 를 재정의하고, 이를 호출하는 다른 메서드들은 디폴트 구현을 호출하기 전에 동기화를 하도록 했다.

(하지만 자바 플랫폼에 속하지 않은 컬렉션 구현체들은 이를 따라가지 못함)

따라서 디폴트 메서드는 컴파일에 성공하더라도 기존 구현체에 런타임 오류를 일으킬 수 있다는 점을 알아야 한다.

자바 8은 컬렉션 인터페이스에 꽤 많은 디폴트 메서드를 추가했고, 그 결과 기존에 짜여진 많은 자바 코드가 영향을 받을 수 있다.
마찬가지로, 기존 인터페이스에 디폴트 메서드로 새 메서드를 추가하는 일은 꼭 필요한 경우가 아니면 피해야 한다.

하지만 새로운 인터페이스를 만드는 경우라면 디폴트 메서드 구현을 하면 편리하다.(아이템 20)

(단, 디폴트 메서드는 인터페이스로부터 메서드를 제거하거나 기존 메서드의 시그니처를 수정하는 용도가 아니다. 일반적으로 라이브러리 개발자들이 라이브러리를 바꿔도 호환성을 유지하기 위해 사용한다. 용도를 잘 생각하자)

새로운 인터페이스라면 릴리스 전에 서로 다른 방식으로 최소한 세 가지는 구현하여 테스트 하자.

또한 각 인터페이스의 인스턴스를 다양한 작업에 활용하는 클라이언트도 여러 개 만들어 테스트 하자.

아래는 `모던 자바 인 액션` 13장 디폴트 메서드의 활용 패턴 2가지를 정리해 보았다.

첫번째는 선택형 메서드 패턴이다. 자바 8 이전, 디폴트 메서드가 없었을 때에는 인터페이스를 구현하는 클래스에서 오버라이드 한 추상 메서드의 내용이 비어있는 상황을 볼 수 있었다. 그런데, 디폴트 메서드는 기본 구현을 제공할 수 있기 때문에 인터페이스를 구현하는 클래스에서 빈 구현을 제공할 필요가 없어진다. => 불필요한 코드를 줄일 수 있다.

public interface Iterator<E> {
    ...
    default void remove() {
        throw new UnsupportedOperationException("remove");
    }
}

두번째는 동작 다중 상속 패턴이다. 디폴트 메서드를 이용하면 기존에는 불가능했던 동작 다중 상속 기능도 구현할 수 있다.

다중 상속을 받을 때, 다른 클래스나 인터페이스로부터 같은 시그니처를 갖는 메서드를 상속 받을 때 알아야 할 세가지 규칙은 아래와 같다.

1. 클래스가 항상 우선권 => 클래스나 부모 클래스에서 정의한 메서드 > 디폴트 메서드
2. 그 다음으로는 서브 인터페이스가 우선권 => B가 A를 상속받는다면 B가 A보다 우선권
3. 그 다음으로는 여러 인터페이스를 상속받는 클래스가 명시적으로 디폴트 메서드를 오버라이드 하고 호출해야 함. => 아이템 20에서 봤던 것 처럼 명시적으로!

과제

github.com/dolly0920/Effective_Java_Study/issues/41

요번 과제는 Functional Interface 에 대한 정리이다. 

참고: www.baeldung.com/java-8-functional-interfaces

• Functional Interface: 함수형 인터페이스는 하나의 추상 메소드(Single abstract method, 단일 추상 메소드)로 이루어진 인터페이스인데, 여기서 함수의 시그니쳐가 정의되어 있기 때문에 컴파일러가 이 정보를 참고해서 람다에서 생략된 정보들을 추론할 수 있게 된다
• 함수형 인터페이스는 컴파일러가 미리 체크할 수 있도록 `@FunctionalInterface` 어노테이션으로 표시해줄 수 있다. 이 어노테이션은 Runnable 이나 Callable, Comparator 등의 함수형 인터페이스에 붙어있다. => 이때, 인터페이스 내에 딱 하나의 추상메소드가 있는게 아니라면 컴파일 에러를 뱉는다.

아래 내용은 `모던 자바 인 액션`에서 관련된 내용을 간단히 정리한 것이다.

• Stream: 한 번에 한 개씩 만들어지는 연속적인 데이터 항목들의 모임 => 병렬처리를 위해 등장
• Default Method: 구현클래스에서 구현하지 않아도 되는 메서드를 인터페이스에 추가할 수 있는 기능 => 인터페이스를 쉽게 바꿀 수 있도록 도와줌
• Lambda: 메서드로 전달할 수 있는 익명 함수를 단순화 한 것 => 간결한 방식으로 코드 전달

• 함수형 인터페이스: 위 java.util.Collection의 removeIf에서 Predicate<T> 인터페이스로 필터 메서드를 파라미터화 할 수 있었다. 이 Predicate<T>가 함수형 인터페이스이다. 

위에서 알아봤듯이 함수형 인터페이스는 정확히 하나의 추상 메서드를 지정하는 인터페이스이다. Predicate 인터페이스를 보면 알 수 있듯이, 함수형 인터페이스에서도 디폴트 메서드를 포함할 수 있다. 즉, 디폴트 메서드가 있더라도 추상 메서드가 오직 하나이면 함수형 인터페이스이다. 

함수형 인터페이스로는 어떤 일을 할 수 있을까?

람다 표현식으로 함수형 인터페이스의 추상 메서드 구현을 직접 전달할 수 있으므로 전체 표현식을 함수형 인터페이스의 인스턴스로 취급할 수 있다. (함수형 인터페이스보다는 덜 깔끔하지만 익명 내부 클래스로도 같은 기능 구현 가능)

함수형 인터페이스의 추상 메서드 시그니처는 람다 표현식의 시그니처를 가리키는데, 람다 표현식의 시그니처를 서술하는 메서드를 함수 디스크립터라고 한다. 예를 들어 위 Runnable 함수형 인터페이스에서 유일한 추상 메서드 run은 인수와 반환값이 없기 때문에 Runnable 인터페이스는 인수와 반환값이 없는 시그니처로 생각할 수 있다.  

아래는 사용 사례와 람다 예제, 그리고 대응하는 함수형 인터페이스를 정리한 것이다.

하나 주의할 점은, 함수형 인터페이스는 checked Exception을 던지는 동작을 허용하지 않는다. 

즉, 예외를 던지는 람다 표현식을 만들려면 checked Exception을 선언하는 함수형 인터페이스를 직접 정의하거나 람다를 try-catch 블록으로 감싸야 한다.

import java.io.BufferedReader;
import java.io.IOException;

@FunctionalInterface
public interface BufferedReaderProcessor {

    String process(BufferedReader b) throws IOException;
}

위 함수형 인터페이스로 정의하거나, Function을 쓰고 싶다면 아래처럼 try-catch로 감싼다

    @DisplayName("Fuction functional interface with try-catch")
    @Test
    void function() {
        Function<BufferedReader, String> func = (BufferedReader b) -> {
            try {
                return b.readLine();
            } catch (IOException e) {
                throw new RuntimeException(e);
            }
        };
    }

아까 람다는 간결한 방식으로 코드를 단순화 하기 위해 나온 방법이라고 했다.

자바 컴파일러는 람다 표현식이 사용된 context(대상 형식)을 이용해서 람다 표현식과 관련된 함수형 인터페이스를 추론할 수 있다.

= 대상 형식을 이용해서 함수 디스크립터를 알 수 있다

= 컴파일러는 람다의 시그니처를 추론할 수 있다. (람다 문법에서 생략 가능)

클래스가 인터페이스를 구현하게 되면, 인터페이스는 클래스가 자신의 인스턴스로 무엇을 할 수 있는지를 클라이언트에 알리는 역할을 한다.

아래와 같은 java.io.ObjectStreamConstants 와 같이 메서드 없이 static final(상수) 필드로만 이루어져있는 인터페이스는 올바르지 않다.

• 클래스 내부에서 사용하는 상수는 외부 인터페이스가 아니라 내부 구현에 해당하는데, 인터페이스의 경우 API로 노출하기 때문
• 인터페이스로 구현할 경우 클라이언트 코드가 내부 구현에 해당하는 상수들에 종속될 수 있다. => 즉, 다음 릴리스에서 상수들을 더는 쓰지 않게 되더라도 바이너리 호환성을 위해 여전히 상수 인터페이스를 구현하고 있어야 한다.
• final이 아닌 클래스가 상수 인터페이스를 구현한다면 모든 하위 클래스의 이름 공간이 그 인터페이스가 정의한 상수 들로 오염되어 버린다.
  • 자바에서의 namespace는 익숙하지 않은 단어이지만, 모든 것을 고유하게 식별하는 이름이라고 생각하면 된다. Java 클래스의 패키지 이름은 클래스의 네임 스페이스 역할을하며 JVM에서 클래스를 고유하게 식별하는 데 도움이 된다.
  • 상수 인터페이스를 Implement 한 클래스에 같은 상수를 가질 경우, 클래스에서 새롭게 정의한 상수가 사용된다.

public interface ConstantInterface {

    public static final int CONSTANT_VALUE = 10;
    public static final String CONSTANT_STRING = "";
}

public class ContaminateConstant implements ConstantInterface {

    public static final int CONSTANT_VALUE = 100;
    public static final String CONSTANT_STRING = "contaminated";
}

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class ConstantInterfaceContaminationTest {

    @Test
    @DisplayName("final이 아닌 클래스가 상수 인터페이스를 구현한다면 모든 하위 클래스의 `이름 공간`이 그 인터페이스가 정의한 상수 들로 오염되어 버린다.")
    void testContamination() {
        ContaminateConstant contaminateConstant = new ContaminateConstant();

        /*
         * 상수 인터페이스를 Implement 한 클래스에 같은 상수를 가질 경우,
         * 클래스에 정의한 상수가 사용되므로 사용자가 의도한 흐름으로 프로그램이 돌아가지 않을 수 있다.
         */

        Assertions.assertAll(
            () -> Assertions.assertNotEquals(ConstantInterface.CONSTANT_STRING, ContaminateConstant.CONSTANT_STRING),
            () -> Assertions.assertNotEquals(ConstantInterface.CONSTANT_VALUE, ContaminateConstant.CONSTANT_VALUE)
        );
        System.out.println(ConstantInterface.CONSTANT_STRING + " " + ContaminateConstant.CONSTANT_STRING);
        System.out.println(ConstantInterface.CONSTANT_VALUE + " " + ContaminateConstant.CONSTANT_VALUE);
    }
}

상수를 공개할 목적이라면 특정 클래스나 인터 페이스와 강하게 연관된 상수일 때, 그 클래스나 인터 페이스 자체에 추가해야 한다.

열거 타입으로 나타내기 적합한 상수라면 열거 타입으로 만들어 공개하면 된다(아이템 34).

그것도 아니라면, 인스턴스화할 수 없는 유틸리티 클래스(아이템 4)에 담아 공개하도록 한다. <- 이 때 인스턴스화 할 수 없도록 Private 생성자를 만들어 두는 것을 잊지 말자!!!

요번 아이템을 보면서 static final 에 대해 조금 헷갈렸는데, `static final` 자체는 상수라는 의미가 아니다.

• static: 메모리 할당을 컴파일 타임에 하는 것 & `해당 클래스`에서 이 이름을 가진 변수가 오직 하나
• final: 단 한번만 값이 할당되는 것 (+ 메소드 레벨에서 오버라이딩을 불가능하게 함)