아이템 22. 인터페이스는 타입을 정의하는 용도로만 사용하라

[coalong]

아이템22. 인터페이스는 타입을 정의하는 용도로만 사용하라

TL;DR

인터페이스는 타입을 정의하는 용도로만 사용하자.
상수 공개용 수단으로 사용하지 말자.

인터페이스의 용도

• 인터페이스는 자신을 구현한 클래스의 인스턴스를 참조할 수 있는 타입 역할을 한다.
• 클래스가 인터페이스를 구현하는 것은 자신의 인스턴스로 무엇을 할 수 있을지(HAS - a)를 클라이언트에 알려주는 것이다.
• 인터페이스는 오직 이 용도로만 사용해야 한다.

❌  위의 지침에 맞지 않는 예시 (안티패턴)

• 상수 인터페이스: 메서드 없이 상수를 뜻하는 static final 필드로만 가득 찬 인터페이스.

// 상수 인터페이스 안티패턴 - 사용금지!!!
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;
}

• final이 아닌 클래스 A가 상수 인터페이스를 구현한다면 A를 구현한 하위 클래스에서는 인터페이스가 정의한 상수들로 오염된다.
  • 사용하지 않을 수도 있는 상수를 포함하여 모두 가져온다.
• 상수 인터페이스를 구현하는 것은 내부 구현을 API로 노출하는 행위
  • 사용자는 클래스가 어떤 상속 인터페이스를 사용하든 사용자에게는 의미가 없고, 혼란만 가중시킨다.
  • 내부구현임에도 불구하고 클라이언트 코드가 이 상수들에 종속된다.
  • 따라서, 이 상수들이 더이상 쓰이지 않더라도 바이너리 호환성을 위해 이 상수 인터페이스를 구현하고 있어야 한다.
• 자바 플랫폼 라이브러리에도 인터페이스를 잘못 활용한 상수 인터페이스 몇 개가 있다.
  • java.io.ObjectStreamConstants 등

그렇다면 상수를 공개할 목적이라면?

몇가지 선택지가 있다.

1. 특정 클래스나 인터페이스와 강하게 연관된 상수라면 그 클래스나 인터페이스 자체에 추가해야 한다.
   • 대표적으로, Integer와 Double에 선언된 MIN_VALUE와 MAX_VALUE 상수가 이런 예시다.
2. 열거(Enum) 타입으로 나타내기 적합한 상수라면 열거 타입으로 만들어 공개하자. (아이템 34)
3. 인스턴스화할 수 없는 유틸리티 클래스에 담아 공개하자.
   • (아이템 4: 인스턴스화를 막으려거든 private 생성자를 사용하라)

유틸리티 클래스란?
인스턴스 메서드와 인스턴스 변수를 일절 제공하지 않고 정적 메서드와 변수만을 제공하는 클래스

상수 유틸리티 클래스

public class PhysicalConstants{
    private PhysicalConstants{} //인스턴스화 방지

    // 아보가드로 수(1/몰)
    public static final double AVOGADROS_NUMBER = 6.022_140_857e23;
    
    // 볼츠만 상수(J/K)
    public static final double BOLYZMANN_COUNT = 1.380.648_52

    // 전자 질량(kg)
    public static final double ELECTRON_MASS = 9.109.383-56e-31;
		

숫자 리터럴에 사용한 밑줄(_)를 보면 자바 7부터 허용하는 이 밑줄은 숫자 리터럴 값은 아무런 영향을 주지 않으면서, 읽기는 훨씬 편하게 해준다.

• 유틸래스 클래스를 사용할 때는 클래스 이름까지 함께 명시하거나 (eg.PhysicalConstants.AVOGADROS_NUMBER)
• 정적 임포트 하여 클래스 이름 생략 가능하다.

import static effectivejava.chapter4.item22.constantutilityclass.PhysicalConstants.*;

public class Test {
    double atoms(double mols) {
	return AVOGADROS_NUMBER * mols;
    // }
	...
    // PhysicalConstants 를 빈번히 사용햤다면 정적 임포트를 값어치를 한다.
}

[jinan159]

깔끔하게 요약해주셔서 넘 잘봤습니다👍
본문에 나온 ObjectStreamConstants 가 어디에 쓰이는지 궁금해서 알아봤는데요.
중요한 부분에 생각보다 많이 쓰이고있더라구요..!

대표적으로 ObjectInputStream, ObjectOUtputStream 이 사용하고 있는데, 이는 직렬화 역직렬화에 사용되는 클래스라고 합니다.
(자세한 내용 참고 : https://zeroco.tistory.com/17)

그리고 이 두 클래스들은 유명한 프레임워크나 라이브러리에서 참조하고 있더라구요.
(h2database, hibernate, spring-context, spring-core, logback, mockito 등등)

사소한 부분이라도 설계를 잘 해야겠구나... 라는걸 느꼈습니다.

[coalong]

그리고 이 두 클래스들은 유명한 프레임워크나 라이브러리에서 참조하고 있더라구요.
(h2database, hibernate, spring-context, spring-core, logback, mockito 등등)

ObjectStreamConstants 쓰임에 대해 자세히 적어주셔서 감사합니다!
ObjectInputStream, ObjectOUtputStream 관련하여 참고 블로그 글도 잘 읽었습니다! 👍

[JoisFe]

오호 해당 두 클래스를 객체를 파일로 직렬화 혹은 파일을 객체로 역직렬화 하는 경우 사용한 경험이 있는데
잘 못 활용한 인터페이스 였군요..

[JoisFe]

제가 이전에 정리한 #14 를 정리할 때 Utils 클래스는 객체 지향과는 거리가 먼 클래스 방식이라고 하였고 그러나 Util 클래스를 사용하는 경우가 있다고 하였는데

Utils 클래스 사용 경우

1. java.lang.Math, java.util.Arrays
   -> 기본 타입 값 or 배열 관련 메서드를 모아놓은 클래스
2. java.util.Collections
   -> 특정 인터페이스를 구현하는 객체를 생성해주는 정적 메서드(혹은 팩터리)를 모아놓은 클래스
3. final 클래스와 관련한 메서드를 모아놓는 경우
   -> final 클래스를 상속해서 하위 클래스에 메서드를 넣는 것이 불가능

위 3가지 경우 말고도 하나의 다른 경우도 존재함을 알게 되었습니다. ㅎㅎ

이 뿐만 아니라 #48 멤버 클래스는 되도록 static으로 만들라는 이유가 해당 주제

• final이 아닌 클래스 A가 상수 인터페이스를 구현한다면 A를 구현한 하위 클래스에서는 인터페이스가 정의한 상수들로 오염된다.
  --> 사용하지 않을 수도 있는 상수를 포함하여 모두 가져온다.
  와 비슷한 것 같습니다.

멤버 클래스가 바깥 인스턴스를 사용하지 않는 경우 static으로 선언해야만 쓸데 없이 객체가 만들어 질 때마다 해당 멤버 클래스의 메모리 공간이 사용되는 낭비를 하지 않듯 인터페이스 내 상수 또한 변하지 않을 값을 굳이 interface를 구현하는 객체를 만들때 마다 상수를 만들기에 메모리 공간 사용이 낭비 되는 것이기 떄문입니다.

두 경우 모두 변할 일이 없거나 특정한 객체에 연관이 없다면 굳이 여러개가 만들어질 낭비를 일으킬 필요가 없기에 이런 것 까지 고려하여 설계하는 것이 중요한 것 같습니다.!!

[coalong]

두 경우 모두 변할 일이 없거나 특정한 객체에 연관이 없다면 굳이 여러개가 만들어질 낭비를 일으킬 필요가 없기에 이런 것 까지 고려하여 설계하는 것이 중요한 것 같습니다.!!

이전 아이템 내용들과 함께 생각하니까 더 정리가 잘 되는 것 같아요 👍 감사합니다.!

[corock]

최근에 책에서 언급한 대로 상수용 인터페이스를 만들어서 사용한 적이 있어 얼굴이 홍당무가 됐습니다 😞
stackoverflow 등의 정보의 홍수 사이트 속에서 허우적대다 보면, 심심치 않게 final class 형태를 접할 수 있었습니다.
그 당시에는 final 키워드를 붙인 코드가 이질감이 느껴져 그냥 지나쳤는데, 적절한 이유를 상기하며 적재적소에 활용해야겠다는 성찰의 시간을 가졌네요 👍

P.S. 많은 사람들이(심지어 시니어 이상 급도 해당) 유틸리티 클래스를 만들 때 단/복수를 오용한다고 생각합니다.
이 자리를 통해 패키지명은 util (단수), 유틸리티 메서드를 제공하는 클래스 이름은 XXXs 처럼 복수형을 사용하자고 외쳐봅니다.

[Irisation23]

최근에 책에서 언급한 대로 상수용 인터페이스를 만들어서 사용한 적이 있어 얼굴이 홍당무가 됐습니다 😞

constant 라는 패키지를 두고 그 안에 enum 클래스로 정의 하는거는 어떻게 생각하시나요?

[JoisFe]

위 comment에서 Util 클래스라 언급한 것 Utils 클래스로 수정합니다 ^^

[JoisFe]

constant 라는 패키지를 두고 그 안에 enum 클래스로 정의 하는거는 어떻게 생각하시나요?

만약 default 메서드나, 추상 메서드가 없이 오로지 상수만 보관한다면 enum 또한 괜찮지 않을까요?
그런데 패키지명이 constant는 잘 모르겠습니다..

[corock]

constant 라는 패키지를 두고 그 안에 enum 클래스로 정의 하는거는 어떻게 생각하시나요?

만약 default 메서드나, 추상 메서드가 없이 오로지 상수만 보관한다면 enum 또한 괜찮지 않을까요? 그런데 패키지명이 constant는 잘 모르겠습니다..

해당 이야기로 아이템이 있지 않았나요~? 어떤 아이템이었는지는 기억이 잘 안 나네요.
consant 패키지는 필수는 아니라서 굳이 안 만들어도 될 것 같습니다.

[JoisFe]

바이너리 호환성이라는 개념을 잘 몰라 찾아보니

자바 프로그램을 바꾸는 것과 관련된 호환성 개념이 크게 3가지로 분류하더라구요

호환성

1. 바이너리 호환성 : 뭔가를 바꾼 이후에도 에러 없이 기존 바이너리가 실행될 수 있는 상황. (바이너리 실행에는 인증, 준비, 해석 등의 과정이 포함)

• ex) 인터페이스에 메서드를 추가했을 때 추가된 메서드를 호출하지 않는 한 문제가 일어나지 않는데 이를 바이너리 호환성이라 함

2. 소스 호환성 : 코드를 고쳐도 기존 프로그램을 성공적으로 재컴파일할 수 있음을 의미.

• ex) 인터페이스에 메서드를 추가하면 소스 호환성이 아님. 추가한 메서드를 구현하도록 클래스를 고쳐야 하기 때문

3. 동작 호환성 : 코드를 바꾼 다음에도 같은 입력값이 주어지면 프로그램이 같은 동작을 실행할 수 있음을 의미.

• ex) 인터페이스에 메서드를 추가하더라도 프로그램에서 추가된 메서드를 호출할 일은 없으므로 (또는 우연히 구현 클래스가 이를 재정의했을 수도 있음) 동작 호환성 유지

reference : 모던 자바 인 액션, 한빛미디어

[coalong]

이 부분 저도 찾아보기만 하고 정리를 따로 안 올렸었는데.. 올려주셔서 감사합니다~~! 👍 👍

[corock]

https://pamyferret.tistory.com/m/62