티스토리 뷰
인터페이스는 자신을 구현한 클래스의 인스턴스를 참조할 수 있는 타입 역할을 합니다.
달리 말해, 클래스가 어떤 인터페이스를 구현한다는 것은 자신의 인스턴스로 무엇을 할 수 있는지를 클라이언트에 얘기해주는 것입니다.
인터페이스는 오직 이 용도로만 사용해야 합니다.
이 지침에 맞지 않는 예로 소위 상수 인터페이스라는 것이 있습니다.
상수 인터페이스란 메서드 없이, 상수를 뜻하는 static final 필드로만 가득 찬 인터페이스를 말합니다.
그리고 이 상수들을 사용하려는 클래스에서는 정규화된 이름(qualified name)을 쓰는 걸 피하고자 그 인터페이스를 구현하곤 합니다.
다음의 예를 봅시다.
public interface PhysicalConstants {
// 아보가드로 수 (1/몰)
static final double AVOGADROS_NUMBER = 6.022_140_857e23;
// 볼츠만 상수 (J/K)
static final double BOLTZMANN_CONSTANT = 1.380_648_52e-23;
// 전자 질량 (kg)
static final double ELECTRON_MASS = 9.109_383_56e-31;
상수 인터페이스 안티패턴은 인터페이스를 잘못 사용한 예입니다.
클래스 내부에서 사용하는 상수는 외부 인터페이스가 아니라 내부 구현에 해당합니다.
따라서 상수 인터페이스를 구현하는 것은 이 내부 구현을 클래스의 API로 노출하는 행위입니다.
클래스가 어떤 상수 인터페이스를 사용하든 사용자에게는 아무런 의미가 없습니다.
오히려 사용자에게 혼란을 주기도 하며, 더 심하게는 클라이언트 코드가 내부 구현에 해당하는 이 상수들에 종속되게 합니다.
그래서 다음 릴리스에서 이 상수들을 더는 쓰지 않게 되더라도 바이너리 호환성을 위해 여전히 상수 인터페이스를 구현하고 있어야 합니다.
final이 아닌 클래스가 상수 인터페이스를 구현한다면 모든 하위 클래스의 namespace가 그 인터페이스가 정의한 상수들로 오염되어 버립니다.
java.io.ObjectStreamConstatns 등, 자바 플랫폼 라이브러리에도 상수 인터페이스가 몇 개 있으나, 인터페이스를 잘못 활용한 예이니 따라 해서는 안 됩니다.
상수를 공개할 목적이라면 더 합당한 선택지가 몇 가지 있습니다.
특정 클래스나 인터페이스와 강하게 연관된 상수라면 그 클래스나 인터페이스 자체에 추가해야 합니다.
모든 숫자 기본 타입의 박싱 클래스가 대표적으로, Integer, Double에 선언된 MIN_VALUE와 MAX_VALUE입니다.
열거 타입으로 나타내기 적합한 상수라면 열거 타입으로 만들어 공개하면 됩니다. (아이템 34)
그것도 아니라면, 인스턴스화할 수 없는 유틸리티 클래스(아이템 4)에 담아 공개합시다.
다음 코드는 앞서 보여준 PhysicalConstants 유틸리티 클래스 버전입니다.
public class PhysicalConstants {
private PhysicalConstants() {} // 인스턴스화 방지
// 아보가드로 수 (1/몰)
static final double AVOGADROS_NUMBER = 6.022_140_857e23;
// 볼츠만 상수 (J/K)
static final double BOLTZMANN_CONSTANT = 1.380_648_52e-23;
// 전자 질량 (kg)
static final double ELECTRON_MASS = 9.109_383_56e-31;
}
숫자 리터럴에 사용장 밑줄(_)에 주목해봅시다.
자바 7부터 허용되는 이 밑줄은 숫자 리터럴의 값에는 아무런 영향을 주지 않으면서, 읽기는 훨씬 편하게 해줍니다.
고정소수점 수든 부동소수점 수든 5자리 이상이라면 밑줄을 사용하는 걸 고려해봅시다.
십진수 리터럴도 밑줄을 사용해 세 자릿씩 묶어주는 것이 좋습니다.
유틸리티 클래스에 정의된 상수를 클라이언트에서 사용하려면 클래스 이름까지 함께 명시해야 합니다.
PhysicalConstants.AVOGADROS_NUMBER 처럼 말입니다.
유틸리티 클래스의 상수를 빈번히 사용한다면 정적 임포트(static import)하여 클래스 이름은 생략할 수 있습니다.
public class Test {
double atoms(double mols) {
return AVOGADROS_NUMBER * mols;
}
...
// PhysicalConstants를 빈번히 사용한다면 정적 임포트가 값어치를 톡톡히 한다.
}
정리
- 인터페이스는 타입을 정의하는 용도로만 사용해야 한다.
- 상수 공개용 수단으로 사용하지 말자.
'JAVA > 이펙티브 자바' 카테고리의 다른 글
아이템[24]. 멤버 클래스는 되도록 static으로 만들라 (0) | 2022.04.10 |
---|---|
아이템[23]. 태그 달린 클래스보다는 클래스 계층구조를 활용하라 (0) | 2022.04.06 |
아이템[21]. 인터페이스는 구현하는 쪽을 생각해 설계하라 (0) | 2022.04.03 |
아이템[20]. 추상 클래스보다는 인터페이스를 우선하라 (0) | 2022.04.03 |
아이템[19]. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라 (0) | 2022.04.02 |
- Total
- Today
- Yesterday
- 디자인패턴
- 이펙티브 자바
- kotest
- Algorithm
- 클린 아키텍처
- Olympiad
- 객체지향
- AWS
- 코테
- Java
- 이팩티브 자바
- MSA
- node.js
- Effective Java
- programmers
- 디자인 패턴
- 클린 코드
- kkoon9
- JPA
- 프로그래머스
- BAEKJOON
- 알고리즘
- Kotlin
- BOJ
- 테라폼
- Spring Boot
- 정규표현식
- Spring
- C++
- 백준
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |