Intro::
이펙티브 자바 정리본입니다.
클래스가 어떤 인터페이스를 구현한다는 것은 자신의 인스턴스로 무엇을 할 수 있는지를 클라이언트에 얘기해주는 것입니다. 인터페이스는 오직 이 용도로만 사용해야 합니다.
// 코드 22-1 상수 인터페이스 안티패턴 - 사용금지! (139쪽)
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;
}
Java
복사
•
클래스 내부에서 사용하는 상수는 외부 인터페이스가 아니라 내부 구현에 해당합니다.
•
따라서 위와 같이 상수 인터페이스를 구현하는 것은 내부 구현을 클래스의 API로 노출하는 행위입니다.
•
이는 사용자에게 혼란을 주며, 클라이언트 코드가 내부 구현에 해당하는 이 상수들에 종속되도록 합니다.
•
다음 릴리즈에서 이 상수들을 더는 쓰지 않게 되더라도 바이너리 호환성을 위해 여전히 상수 인터페이스를 구현하고 있어야 합니다.
그러면 어떻게 해야하는 하는가?
•
특정 클래스나 인터페이스와 강하게 연관된 상수라면 그 클래스나 인터페이스 자체에 추가해야 합니다. 모든 숫자 기본 타입의 박싱 클래스가 대표적으로, Integer와 Double에 선언된 MIN_VALUE와 MAX_VALUE 상수가 이런 예입니다.
•
열거 타입으로 나타내기 적합한 상수라면 열거 타입으로 만들어 공개하면 됩니다.
•
인스턴스화 할 수 없는 유틸리티 클래스에 담아 공개하면 됩니다.
◦
클래스의 상수를 빈번히 사용한다면 정적 임포트를 하여 클래스 이름을 생략할 수도 있습니다.
// 코드 22-2 상수 유틸리티 클래스 (140쪽)
public class PhysicalConstants {
private PhysicalConstants() { } // 인스턴스화 방지
// 아보가드로 수 (1/몰)
public static final double AVOGADROS_NUMBER = 6.022_140_857e23;
// 볼츠만 상수 (J/K)
public static final double BOLTZMANN_CONST = 1.380_648_52e-23;
// 전자 질량 (kg)
public static final double ELECTRON_MASS = 9.109_383_56e-31;
}
Java
복사
질문
“다음 릴리즈에서 이 상수들을 더는 쓰지 않게 되더라도 바이너리 호환성을 위해 여전히 상수 인터페이스를 구현하고 있어야 합니다.”가 무슨말인가?
// 초기 상태
public interface PhysicalConstants {
static final double AVOGADROS_NUMBER = 6.022_140_857e23;
}
public class MyClass implements PhysicalConstants {
public void printConstant() {
System.out.println(AVOGADROS_NUMBER);
}
}
Java
복사
// MyClass 를 사용하는 다른 클래스
public class AnotherClass {
public void doSomething() {
MyClass myClass = new MyClass();
myClass.printConstant();
}
}
Java
복사
// 변경
public class MyClass {
public void printConstant() {
System.out.println(PhysicalConstants.AVOGADROS_NUMBER);
}
}
Java
복사
•
만약 AnotherClass가 기존의 MyClass를 사용하던 상태로 컴파일되어 있었다면, AnotherClass는 MyClass가 PhysicalConstants 인터페이스를 여전히 구현하고 있다고 "기대"합니다.
•
그런데, 새로운 버전에서 MyClass가 더 이상 PhysicalConstants를 구현하지 않게 되면, 컴파일된 바이트코드가 변경되었기 때문에, 이 두 파일이 서로 맞지 않게 됩니다. 이로 인해 AnotherClass가 제대로 동작하지 않거나, 예상치 못한 에러가 발생할 수 있습니다.
그럼 다시 컴파일 하면 되는거 아닌가???
맞습니다. 인터페이스를 구현하지 않도록 변경된 코드를 사용하려면 해당 코드와 그것을 사용하는 모든 코드들을 다시 컴파일하는 것이 일반적으로 필요한 작업입니다. 하지만 이 문제는 항상 쉽게 해결되지 않을 수 있습니다.
1.
외부 라이브러리를 사용하는 경우 해당 라이브러리를 직접 다시 컴파일 할 수 없습니다.
2.
이미 배포된 소프트웨어의 경우, 최종 사용자에게 다시 컴파일 된 버전을 제공해야 하는데, 이 과정은 번거롭고 불편한 과정입니다.
References::
이펙티브 자바 / 조슈아 블로크 지음 (프로그래밍 인사이트)
