공부 기록

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

디폴트 메서드 덕분에 자바에도 기존 인터페이스에 메서드를 추가할 수 있게 되었다. 하지만 모든 기존 구현체들과 매끄럽게 연동된다는 보장은 없다. 왜냐면 자바 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: 단 한번만 값이 할당되는 것 (+ 메소드 레벨에서 오버라이딩을 불가능하게 함)

자바가 제공하는 다중 구현 메커니즘은 인터페이스와 추상 클래스가 있다.

자바 8부터 인터페이스도 디폴트 메서드(default method)를 제공하기 때문에 두 메커니즘 모두 인스턴스 메서드를 구현 형태 로 제공할 수 있게 되었다. 그래서 엄청 헷갈림...ㅠㅠ

둘의 가장 큰 차이는 추상 클래스가 정의한 타입을 구현하는 클래스는 반드시 추상 클래스의 하위 클래스가 되어야 한다는 점이다.

반면 인터페이스가 선언한 메서드를 모두 정의하고 그 일반 규약을 잘 지킨 클래스라면 다른 어떤 클래스를 상속했든 같은 타입으로 취급됨.

인터페이스는 믹스인(mixin) 정의에 안성맞춤이다. 믹스인이란 클래스가 구현할 수 있는 타입으로, 

믹스인을 구현한 클래스에 원래의 `주된 타입` 외에 도 특정 선택적 행위를 제공한다고 선언하는 효과를 준다.

예를 들어 Comparable 은 자신을 구현한 클래스의 인스턴스들끼리는 순서를 정할 수 있다고 선언하는 믹스인 인터페이스로,

대상타입의 주된 기능에 선택적 기능을 ‘혼합 (mixed-in)’한다고 해서 믹스인이라 부른다.

추상 클래스로는 믹스인을 정의할 수 없다. 이유는 앞서와 같이, 기존 클래스에 덧씌울 수 없기 때문이다.

클래스 는 두 부모를 섬길 수 없고, 클래스 계층구조에는 믹스인을 삽입하기에 합리적인 위치가 없다.

래퍼 클래스 관용구(아이템 18)와 함께 사용하면 인터페이스는 기능을 향상 시키는 안전하고 강력한 수단이 된다.
인터페이스의 메서드 중 구현 방법이 명백한 것이 있다면, 그 구현을 아래와 같이 디폴트 메서드로 제공하도록 하자.

단, 디폴트 메서드를 제공할 때는 상속하려는 사람을 위한 설명을 @implSpec 자바독 태그를 붙여 문서화 해야 한다(아이템 19)

디폴트 메서드에도 제약은 있다. 인터페이스는 Object 클래스의 equals나 hashCode 등을 디폴트 메서드로 제공하면 안된다.

=> 따라서 굳이 제공하고 싶다면 abstract 클래스에서 override 해주면서 구현해야 한다.

또한, 아래처럼 여러 인터페이스가 같은 이름을 가진 디폴트 메서드라면 바로 사용할 수 없다. (구현체에서 오버라이드 할 경우는 가능)

한편, 인터페이스와 추상 골격 구현(skeletal implementation) 클래스를 함께 제공하는 식으로 인터페이스와 추상 클래스의 장점을 모두 취하는 방법도 있다. 인터페이스로는 타입을 정의하고, 필요하면 디폴트 메서드 몇 개도 함께 제공하도록 하고, 골격 구현 클래스는 나머지 메서드들까지 구현한다. 이렇게 해두면 단순히 골격 구현을 확장하는 것만으로 이 인터페이스를 구현하는 데 필요한 일이 대부분 완료된다.

=> 템플릿 메서드 패턴

(이전에 왜 HashSet의 경우 AbstractSet 추상클래스를 상속하고 있는데, Set 인터페이스또한 implement하고 있는지에 대한 의문이 들었던 적이 있었고, 이에 대해 살짝 알아본 적이 있었다.)

2021.01.25 - [책을 읽자/Effective Java] - Item4: 인스턴스화를 막으려거든 private 생성자를 사용하라

예시를 통해 보자. 아래 코드는 완벽히 동작하는 List 구현체를 반환하는 정적 팩터리 메서드로, AbstractList 골격 구현으로 활용했다.

	static List<Integer> intArrayAsList(int[] a) {
		Objects.requireNonNull(a);

		return new AbstractList<>() {
			@Override
			public Integer get(int i) {
				return a[i]; // 오토박싱(아이템 6)
			}

			@Override
			public Integer set(int i, Integer val) {
				int oldVal = a[i];

				a[i] = val;// 오토언박싱
				return oldVal; // 오토박싱
			}

			@Override
			public int size() {
				return a.length;
			}
		};
	}

이 예시는 int 배열을 받아 Integer 인스턴스의 리스트 형태로 보여주는 어댑터 패턴이기도 하다. int 값과 Integer 인스턴스 사이의 박싱과 언박싱 때문에 성능은 그리 좋지 않으며, 익명 클래스(아이템 24) 형태를 사용했음

골격 구현 클래스를 우회적으로 이용할 수도 있는 방법도 있다.

인터페이스를 구현한 클래스에서 해당 골격 구현을 확장한 private 내부 클래스를 정의하고, 각 메서드 호출을 내부 클래스의 인스턴스에 전달하는 방법을 사용하면 된다. 아이템 18에서 다룬 래퍼 클래스와 비슷한 이 방식을 시뮬레이트한 다중 상속(simulated multiple inheritance)이라 하며, 다중 상속의 많은 장점을 제공하는 동시에 단점은 피하게 해준다. 예시는 아래와 같다.

public interface Food {

}

public class Pizza implements Food{

}

public class Truck {

    public void driveTo(String destination) {
        System.out.println("drive to " + destination);
    }
}

아래와 같이 Kitchen 인터페이스로 함수를 정의해 두고 AbstractKitchen으로 공통적으로 turnLightOn/Off 골격 함수를 정의한다.

public interface Kitchen {

    void cook(Food food);
    void turnLightOn();
    void turnLightOff();
}

public abstract class AbstractKitchen implements Kitchen {

    @Override
    public void turnLightOn() {
        System.out.println("light on");
    }

    @Override
    public void turnLightOff() {
        System.out.println("light off");
    }
}

public class PizzaTruck extends Truck implements Kitchen {

    private final InnerAbstractKitchen innerAbstractKitchen = new InnerAbstractKitchen();

    @Override
    public void cook(Food food) {
        innerAbstractKitchen.cook(food);
    }

    @Override
    public void turnLightOn() {
        innerAbstractKitchen.turnLightOn();
    }

    @Override
    public void turnLightOff() {
        innerAbstractKitchen.turnLightOff();
    }

    private static class InnerAbstractKitchen extends AbstractKitchen {

        @Override
        public void cook(Food food) {
            System.out.println("cook " + food.getClass().getSimpleName());
        }
    }
}

마지막으로 골격 inner 클래스에서 남은 함수 cook을 정의할 수 있다.

과제

github.com/dolly0920/Effective_Java_Study/issues/40

책을 읽으며 고려하지 못했던 부분에 대해 과제로 더 정리해 볼 수 있도록 좋은 이슈를 올려주셨다.

1. 추상 클래스와 인터페이스의 차이
   • 추상클래스는 다중 상속 불가/인터페이스는 다중 구현 가능
   • 추상클래스의 목적은 상속 후 기능 확장/인터페이스의 목적은 필요한 메서드를 미리 정의하며 구현 객체가 같은 동작을 하도록 보장하는 것
   • 추상 클래스는 인스턴스 필드로 공통 상태를 가질 수 있다/인터페이스는 인스턴스 변수를 가질 수 없다.
2. Java8 에 추가된 인터페이스의 기능과 그 이유
   • java8에 추가된 인터페이스 기능은 default method이다
   • default method은 그동안 인터페이스에서 함수 구현이 불가능했던 것을 가능하도록 만들었다. 
   • 람다를 사용하기 좀 더 좋음
   • 출처: stackoverflow.com/questions/55780860/how-do-java-8-default-methods-h%D0%B5lp-with-lambdas

public interface Animal {

    default String jump() {
        return "jump";
    }
}

public class Cat implements Animal {

    @Override
    public String jump() {
        return "cat is jumping";
    }
}

public class Dog implements Animal {

}

import java.util.ArrayList;
import java.util.List;
import com.example.sypark9646.item20.interface_default_method.Animal;
import com.example.sypark9646.item20.interface_default_method.Cat;
import com.example.sypark9646.item20.interface_default_method.Dog;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class InterfaceDefaultMethodTest {

    @DisplayName("lambda에서 interface default method 동작 테스트")
    @Test
    void traverseAnimals() {
        List<Animal> animals = new ArrayList<>();
        animals.add(new Cat());
        animals.add(new Dog());
        animals.add(new Cat());
        animals.add(new Dog());
        animals.add(new Cat());
        animals.add(new Dog());
        animals.add(new Cat());
        animals.add(new Dog());
        animals.add(new Cat());
        animals.add(new Dog());

        animals.stream().map(Animal::jump)
            .forEach(System.out::println);
    }
}