아이템 20. 추상 클래스보다는 인터페이스를 우선하라
자바 8부터 인터페이스도 디폴트 메서드(default method)를 제공할 수 있다.
자바가 제공하는 다중 구현 메커니즘은 인터페이스, 추상 클래스 이렇게 두 가지다.
자바 8부터 인터페이스도 디폴트 메서드(default method)를 제공할 수 있게 되어 이제는 두 메커니즘 모두 인스턴스 메서드를 구현 형태로 제공할 수 있다.
public interface TimeClient {
void setTime(int hour, int minute, int second);
void setDate(int day, int month, int year);
void setDateAndTime(int day, int month, int year,
int hour, int minute, int second);
LocalDateTime getLocalDateTime();
static ZoneId getZonedId(String zoneString) {
try {
return ZoneId.of(zoneString);
} catch (DateTimeException e) {
System.err.println("Invalid time zone: " + zoneString + "; using default time zone instead.");
return ZoneId.systemDefault();
}
}
default ZonedDateTime getZonedDateTime(String zoneString) {
return ZonedDateTime.of(getLocalDateTime(), getZonedId(zoneString));
} // 인터페이스를 진화시킬 수 있다.
}구현이 명백한 것은 인터페이스의 디폴트 메서드를 사용해 프로그래머의 일감을 덜어줄 수 있다.
추상클래스가 정의한 타입을 구현하는 클래스는 반드시 추상 클래스의 하위 클래스가 되어야 한다. 자바는 단일 상속만을 지원하므로 추상클래스 방식은 새로운 타입을 정의하는 데 커다란 제약을 안게 된다.
기존 클래스에도 손쉽게 새로운 인터페이스를 구현해넣을 수 있다.
인터페이스는 클래스 선언에 implements 구문만 추가하면 끝이다.
반면 기존 클래스 위에 새로운 추상 클래스를 끼워넣기는 어려운 게 일반적이다. 두 클래스가 같은 추상 클래스를 확장하길 원한다면, 그 추상 클래스는 계층구조상 두 클래스의 공통 조상이어야 한다.
인터페이스는 믹스인(mixin)정의에 안성맞춤이다.
원래의 '주된 타입'외에도 특정 선택적 행위를 제공한다고 선언하는 효과를 준다.
public class SimpleTimeClient implements TimeClient, Comparable {
// ... 코드생략
@Override
public int compareTo(Object o) {
// ... 코드생략
}
}Comparable은 자신을 구현한 클래스의 인스턴스끼리는 순서를 정할 수 있다고 선언하는 믹스인 인터페이스다. 대상 타입의 주된 기능에 선택적 기능을 '혼합(mixed in)' 한다고 해서 믹스인이라 부른다.
인터페이스로는 계층구조가 없는 타입 프레임워크를 만들 수 있다.
타입을 계층적으로 정의하면 수많은 개념을 구조적으로 잘 표현할 수 있지만, 현실에는 계층을 엄격히 구분하기 어려운 개념도 있다.
public interface SingerSongwriter extends Singer, Songwriter { // Singer, Songwriter <= 계층구조가 없음.
AudioClip strum();
void actSensitive();
}
래퍼 클래스(아이템 18)와 함께 사용하면 인터페이스는 기능을 향상 시키는 안전하고 강력한 수단이 된다.
추상클래스로 정의해두면 그 타입에 기능을 추가하는 방법은 상속뿐이다. 상속해서 만든 클래스는 래퍼 클래스보다 활용도가 떨어지고 깨지기는 더 쉽다.
인터페이스와 추상 골격 구현(skeletal implementation) 클래스를 함께 제공하는 식으로 인터페이스와 추상 클래스의 장점을 모두 취할 수 있다.
인터페이스 - 타입 정의, 디폴트 메서드 구현
추상 골격 클래스 - 나머지 메서드 구현
단순히 골격 구현을 확장하는 것만으로 이 인터페이스를 구현하는 데 필요한 일이 대부분 완료된다. => 템플릿 메서드 패턴
관례상 인터페이스 이름이 Interface라면 그 골격 구현 클래스의 이름은 AbstractInterface로 짓는다. 컬렉션 프레임워크의 AbstractCollection, AbstractSet, AbstractList, AbstractMap 각각이 바로 핵심 컬렉션 인터페이스의 골격 구현이다.
public class IntArrays {
static List<Integer> intArrayAsList(int[] a) { // int 배열을 받아 Integer 인스턴스의 리스트 형태로 보여주는 어댑터(Adapter)이기도 하다.
Objects.requireNonNull(a);
// 다이아몬드 연산자를 이렇게 사용하는 건 자바 9부터 가능하다.
// 더 낮은 버전을 사용한다면 <Integer>로 수정하자.
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;
}
};
}
}
만약 AbstractList를 사용하지 않고 List를 쓰려고 했다면, 이렇게나 많은 메서드를 구현해야한다. Skeleton 역할을 하는 AbstractList를 사용하여 아주 일부분만 재정의할 수 있다.
시뮬레이트한 다중 상속 (simulated multiple inheritance)
인터페이스를 구현한 클래스에서 해당 골격 구현을 확장한 private 내부 클래스를 정의하고, 각 메서드 호출을 내부 클래스의 인스턴스에 전달한다. 래퍼 클래스와 비슷한 이 방식은 다중 상속의 많은 장점을 제공하는 동시에 단점은 피하게 해준다.
public abstract class AbstractCat {
protected abstract String sound();
protected abstract String name();
}public class MyCat extends AbstractCat {
@Override
protected String sound() {
return "인싸 고양이 두 마리가 나가신다!";
}
@Override
protected String name() {
return "유미";
}
public static void main(String[] args) {
MyCat myCat = new MyCat();
System.out.println(myCat.sound());
System.out.println(myCat.name());
}
}AbstractCat을 상속받은 MyCat이 있다.
▼ Flyable interface
public interface Flyable {
void fly();
}▼ AbstractFlyable
public class AbstractFlyable implements Flyable {
@Override
public void fly() {
System.out.println("너랑 딱 붙어있을게!");
}
}MyCat 클래스가 이미 AbstractCat을 상속받고 있기 때문에, AbstractFlyable 을 추가로 상속 받지 못한다.
public class MyCat extends AbstractCat implements Flyable {
private MyFlyable myFlyable = new MyFlyable();
@Override
protected String sound() {
return "인싸 고양이 두 마리가 나가신다!";
}
@Override
protected String name() {
return "유미";
}
public static void main(String[] args) {
MyCat myCat = new MyCat();
System.out.println(myCat.sound());
System.out.println(myCat.name());
myCat.fly();
}
@Override
public void fly() {
this.myFlyable.fly();
}
private class MyFlyable extends AbstractFlyable {
@Override
public void fly() {
System.out.println("날아라.");
}
}
}1) Flyable interface를 구현하고 2) private class를 AbstractFlyable을 상속을 받는다. 3) Flyable interface 를 구현한 메서드에, 선언한 private MyFlyable myFlyable 필드의 메서드를 위임하면 마치 상속을 한 것처럼 사용할 수 있다.
템플릿 메서드 패턴
알고리즘 구조를 서브 클래스가 확장할 수 있도록 템플릿으로 제공하는 방법이다. 추상 클래스는 템플릿을 제공하고 하위 클래스는 구체적인 알고리즘을 제공한다.
▼ Abstract class
public abstract class FileProcessor {
private String path;
public FileProcessor(String path) {
this.path = path;
}
public final int process() { // template method
try(BufferedReader reader = new BufferedReader(new FileReader(path))) {
int result = 0;
String line = null;
while((line = reader.readLine()) != null) {
result = getResult(result, Integer.parseInt(line));
}
return result;
} catch (IOException e) {
throw new IllegalArgumentException(path + "에 해당하는 파일이 없습니다.", e);
}
}
protected abstract int getResult(int result, int number);
}▼ Concrete class
public class Plus extends FileProcessor {
public Plus(String path) {
super(path);
}
@Override
protected int getResult(int result, int number) {
return result + number;
}
}▼ client
public class Client {
public static void main(String[] args) {
FileProcessor fileProcessor = new Plus("number.txt");
System.out.println(fileProcessor.process());
}
}
템플릿 콜백 패턴
Plus 클래스는 FileProcessor를 상속받았다. 상속을 사용하지 않고도 확장할 수 있다.
public class FileProcessor {
private String path;
public FileProcessor(String path) {
this.path = path;
}
public final int process(BiFunction<Integer, Integer, Integer> operator) {
try(BufferedReader reader = new BufferedReader(new FileReader(path))) {
int result = 0;
String line = null;
while((line = reader.readLine()) != null) {
result = operator.apply(result, Integer.parseInt(line));
}
return result;
} catch (IOException e) {
throw new IllegalArgumentException(path + "에 해당하는 파일이 없습니다.", e);
}
}
// protected abstract int getResult(int result, int number);
}BiFunction은 두 개의 인자를 받아서 하나의 인자값을 돌려주는 오퍼레이션을 정의할 수 있는 함수형 인터페이스이다. BiFunction을 인자로 받으면서 FileProcessor를 추상클래스가 아닌 클래스로 정의한다.
public class Client {
public static void main(String[] args) {
FileProcessor fileProcessor = new FileProcessor("number.txt");
System.out.println(fileProcessor.process((a, b) -> a + b));
System.out.println(fileProcessor.process(Integer::sum)); // method reference
}
}Client에서 FileProcessor의 processor를 호출하며 (a, b) -> a + b를 넘겨주면 된다. 이것을 method reference로 간추릴 수도 있다.
default 메서드는 equals, hashCode, toString과 같은 Object 메서드를 재정의할 수 없다.
Object 클래스를 오버라이딩하려고 하면 "Default method 'toString' overrides a memeber of 'java.lang.Object'" 컴파일 에러가 발생한다.
왜 자바 개발자들은 오버라이딩을 막았을까?
1) The key goal of adding default methods to Java was "interface evolution", not "poor man's traits."
default 메서드의 용도가 아니다.
2) Adds complexity.
복잡도를 증가시킨다.
Rule #1. Classes win over interfaces.
=> 클래스가 인터페이스를 이긴다.
Rule #2. More specific interfaces win over less specific ones (where specificity means "subtyping").
=> 더 구체적인 인터페이스가 덜 구체적인 인터페이스를 이긴다.
만약 interface의 default메서드에서 Object 메서드를 오버라이딩하게되면 이 두가지 규칙 중 무엇을 따라야할 지 복잡해진다.
3) Really only makes sense in toy examples.
사실상 toy project에서나 필요한 기능이다. toString, hashCode, equals 기능은 데이터가 있어야 유의미한 기능이라 인터페이스에서 재정의했을 때 의미가 없다.
4) It's brittle.
깨지기 쉽다. 갑자기 구현하고 있는 Interface에서 Object 메서드들을 오버라이딩했을 때, 클래스의 동작이 바뀌게 된다.