티스토리 뷰
추상클래스와 인터페이스의 차이점
- 추상 클래스가 정의한 타입을 구현하는 클래스는 반드시 추상 클래스의 하위 클래스가 되어야 한다는 점이다.
자바는 단일 상속만 지원하는데, 추상 클래스 방식을 사용한다면 새로운 타입을 정의하는 데 커다란 제약을 안게 된다. 반면 인터페이스가 선언한 메서드를 모두 정의하고 그 일반 규약을 잘 지킨 클래스라면 다른 어떤 클래스를 상속했든 같은 타입으로 취급된다.
믹스인
인터페이스는 믹스인
정의에 안성맞춤이다.
믹스인이란 클래스가 구현할 수 있는 타입으로, 믹스인을 구현한 클래스에 원래의 '주된 타입'외에도 특정 선택적 행위를 제공한다고 선언하는 효과를 준다.
ex. Comparable 은 자신을 구현한 클래스의 인스턴스들끼리는 순서를 정할 수 있다고 선언하는 믹스인 인터페이스이다.
이처럼 대상 타입의 주된 기능에 선택적 기능을 혼합(mixed in) 한다고 해서 믹스인이라고 부른다.
추상클래스는 이 믹스인을 정의할 수 없다.
왜냐면 기존 클래스에 덧씌우는게 불가능하기 때문이다. 한 클래스는 두 부모를 섬길 수 없고, 클래스 계층구조에는 믹스인을 삽입하기에 합리적인 위치가 없기 때문이다.
인터페이스 구현
인터페이스로는 계층구조가 없는 타입 프레임워크를 만들 수 있다.
타입을 계층적으로 정의하면 수많은 개념을 구조적으로 잘 표현할 수 잇지만, 실제로는 계층을 엄격히 구분하기 어려운 개념도 있다.
// 가수
public interface Singer {
AudioClip sing(Song s);
}
// 작곡가
public interface Songwriter {
Song compose(int chartPosition);
}
만약에 작곡도 하는 가수라면 Singer, Songwriter 모두를 구현해도 전혀 문제가 되지 않는다.
심지어 Singer, Songwriter 모두를 확장하고 새로운 메서드까지 추가한 제 3의 인터페이스를 정의할 수도 있다.
// 제 3의 인터페이스
public interface SingerSongwriter extends Singer, Songwriter {
AudioClip strum();
void actSensitive();
}
래퍼클래스 관용구(Item 18)과 함께 사용하면 인터페이스는 기능을 향상시키는 안전하고 강력한 수단이 된다.
타입을 추상 클래스로 정의하면 그 타입에 기능을 추가하는 방법은 상속뿐이다.
근데 상속해서 만든 클래스는 래퍼 클래스보다 활용도가 떨어지고 깨지기는 더 쉽다.
인터페이스의 default 메서드
default 메서드를 제공할 때는 상속하려는 사람을 위한 설명을 @implSpec 자바독 태그를 붙여 문서화해야 한다.
디폴트 메서드로 equals, hashCode와 같은 Obejct 메서드를 제공해서는 안된다.
또한 인터페이스는 인스턴스 필드를 가질 수 없고 public이 아닌 정적멤버도 가질 수 없다.
추상골격구현 (skeletal implementation)
- 인터페이스로는 타입을 정의하고, 필요하면 디포트 메서드도 함께 제공한다.
- 골격 구현 클래스는 나머지 메서드들까지 구현한다.
이렇게하면 단순히 골격 구현을 확장하는 것 만으로 이 인터페이스를 구현하는데 필요한 일이 대부분 완료된다. 이걸 템플릿 메서드 패턴
이라고 한다.
// 20-1. 골격 구현을 사용해 완성한 구체 클래스
static List<Integer> intArrayAsList(int[] a) {
Objects.requireNonNull(a);
return new AbstractList<> {
@Override
public Integer get(int i) {
return a[i];
}
@Override
public Integer set(int i, Integer val) {
int oldVal = a[i];
a[i] = val;
return oldVal;
}
@Override
public int size() {
return a.length;
}
};
}
골격 구현 클래스의 장점은 추상 클래스처럼 구현을 도와주는 동시에, 추상 클래스로 타입을 정의할 때 따라오는 심각한 제약에서는 자유롭다는 점에 있다.
골격 구현을 확장하는 것으로 인터페이스 구현이 거의 끝나지만, 꼭 이렇게 해야 하는 것은 아니다.
구조상 골격 구현을 확장하지 못하는 처지라면 인터페이스를 직접 구현해야 한다.
골격 구현 작성
- 먼저, 인터페이스를 잘 살펴 다른 메서드들의 구현에 사용되는 기반 메서드들을 선정한다. 이 기반 메서드들은 골격 구현에서는 추상 메서드가 될 것이다.
- 기반 메서드들을 사용해 직접 구현할 수 있는 메서드들을 모두 디폴트 메서드로 제공한다. 단 equals, hashCode같은 Object의 메서드는 디폴트 메서드로 제공해서는 안된다.
- 인터페이스의 메서드 모두가 기반 메서드와 디폴트 메서드가 된다면 골격 구현 클래스를 별도로 만들 이유는 없다.
- 기반 메서드나 디폴트 메서드로 만들지 못한 메서드가 남아 있다면, 인터페이스를 구현하는 골격 구현 클래스를 하나 만들어 남은 메서드들을 작성해 넣는다.
- 골격 구현은 기본적으로 상속해서 사용하는 걸 가종하므로 Item19 에서 말한 설계 및 문서화 지침을 모두 따라야 한다.
결론
- 일반적으로 다중 구현용 타입으로는 인터페이스가 가장 적합하다.
- 복잡한 인터페이스라면 구현하는 수고를 덜어주는 골격 구현을 함께 제공하는 방법을 꼭 고려해보자.
- 골격 구현은 '가능한 한' 인터페이스의 디폴트 메서드로 제공하여 그 인터페이스를 구현한 모든곳에서 활용하도록 하는 것이 좋다.
'책 > 이펙티브자바' 카테고리의 다른 글
아이템22. 인터페이스는 타입을 정의하는 용도로만 사용하라 (0) | 2021.08.24 |
---|---|
아이템21. 인터페이스는 구현하는 쪽을 생각해 설계하라 (0) | 2021.08.24 |
아이템19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라 (0) | 2021.08.17 |
아이템18. 상속보다는 컴포지션을 사용하라 (0) | 2021.08.15 |
아이템17. 변경 가능성을 최소화하라 (0) | 2021.07.27 |
- Total
- Today
- Yesterday
- GCP
- HTTP 완벽 가이드
- 이펙티브자바 아이템60
- 프로그래머스 SQL
- BOJ
- js api
- 김영한 http
- 드림코딩
- JS 딥다이브
- 프로그래머스
- 백준
- http
- 백기선 스터디
- 이펙티브자바
- dreamcoding
- 가상 면접 사례로 배우는 대규모 시스템 설계 기초
- js promise
- JPA 연관관계 매핑
- 킹수빈닷컴
- ㅇㄷㅇㅈ
- HTTP 완벽가이드
- js array
- 김영한 JPA
- Spring Security
- REST API
- java
- 패스트캠퍼스 컴퓨터공학 완주반
- 이펙티브자바 아이템59
- 이펙티브자바 스터디
- 모던자바스크립트
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 |