- 상수를 정의하는 용도로 인터페이스를 사용하지 말 것!
- 클래스 내부에서 사용할 상수는 내부 구현에 해당한다.
- 내부 구현을 클래스의 API로 노출하는 행위가 된다.
- 클라이언트에 혼란을 준다.
- 상수를 정의하는 방법
- 특정 클래스나 인터페이스
- 열거형
- 인스턴스화 할 수 없는 유틸리티 클래스
네임 스페이스 없이 편리하게 필드값을 사용하고자 인터페이스에 상수를 정의한다면 안티 패턴으로 권장하지 않는 코드이다. 인터페이스의 원래 용도를 오염시키기 때문. 인터페이스를 만드는 의도는 타입을 정의하기 위해서이다.
인터페이스는 공통 사용기술서이자 타입정의서이지 실질적으로 상수를 사용하는 곳은 class 에서 사용하니 class 내부에 정의하는 것이 맞다.
만약 여러군데에서 사용하는 상수라면 상속할 수 없는 유틸리티 클래스에 정의하는 것이 좋다.
클래스의 상수를 빈번히 사용할 경우 정적 임포트를 사용하여 클래스 이름을 생략할 수 있다.
- 바이너리 호환성 : 뭔가를 바꾼 이후에도 에러 없이 기존 바이너리(클래스들)가 실행될 수 있는 상황. 인터페이스에서 상수를 선언했고 구현한 클래스에서 그 상수를 가져다 쓴다면? 추후 인터페이스에서 그 상수를 없앤다면 구현한 클래스에서 해당 상수를 찾을 수 없으니 코드 변경이 필요하고 다시 컴파일해야 시스템을 실행할 수 있다. 디폴트 메서드는 추가를 해도 구현한 클래스에서 별도 오버라이딩을 하지 않아도 되는데 이를 바이너리 호환성이라고 한다. 한마디로 클래스를 변경할 때, 그 클래스를 사용하는 클래스들에서 리컴파일 할 필요가 없어야된다.
'개인룸 > 도윤' 카테고리의 다른 글
Item24.멤버 클래스는 되도록 static으로 만들라 (0) | 2023.03.21 |
---|---|
Item.23 태그 달린 클래스보다는 클래스 계층구조를 활용하라 (0) | 2023.03.20 |
Item21. 인터페이스는 구현하는 쪽을 생각해 설계하라 (0) | 2023.03.13 |
Item 20. 추상 클래스보다 인터페이스를 우선하라. (0) | 2023.03.13 |
Item19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라 (0) | 2023.03.06 |