이팩티브 자바-인터페이스

🤦‍♂️

1. 추상 클래스보다는 인터페이스를 우선하라

• 설명

  • 자바가 제공하는 다중 구현 메커니즘

  추상 클래스	인터페이스
  추상 클래스가 정의한 타입을 구현하는 클래스는 반드시 추상 클래스의 하위 클래스가 되어야 한다. 자바는 단일 상속만 지원하기 때문에 추상 클래스 방식은 새로운 타입을 정의하는데 큰 제약이 된다.	인터페이스가 선언한 메서드를 모두 정의하고 그 일반 규약을 잘 지킨 클래스는 다른 어떤 클래스를 상속했든 같은 타입으로 취급된다.
  기존 클래스 위에 새로운 추상 클래스를 끼워넣기는 어렵다. (하위 클래스들이 공동 상속을 해야하기 때문에)	기존 클래스에도 손쉽게 새로운 인터페이스를 구현할 수 있다.
  Mixin 정의에 맞지않다 클래스는 두 부모를 섬길 수 없고, 클래스 계층구조에는 믹스인을 삽입하기에 합리적인 위치가 없다.	Mixin 정의에 알맞다 (Mixin : 클래스가 구현할 수 있는 타입으로 이를 구현한 클래스에 원래의 주된 기능 외에도 특정 선택적 행위를 제공한다고 선언하는 효과를 제공) Ex) Comparable은 자신을 구현한 클래스의 인스턴스끼리는 순서를 정할 수 있다고 선언하는 믹스인 인터페이스
  가능한 조합 전부를 각각의 클래스로 정의한 고도비만 계층구조가 만들어진다. 속성이 N개라면, 지원해야할 조합의 수는 2^n개나 된다. (combinational explosion | 조합 폭발) 거대한 클래스 계층구조에는 공통 기능을 정의해놓은 타입이 없으니, 매개변수 타입만 다른 메서드들을 수없이 많이 가진 거대한 클래스가 생성될 수 있다.	계층구조가 없는 타입 프레임워크를 만들 수 있다. Ex) 작곡도하는 가수를 표현할때, 간단하게 인터페이스 두개를 implements 하거나 SingerSongwriter이라는 새로운 인터페이스를 만들 수도 있다. public interface Singer { AudioClip sing(Song s); } public interface Songwriter { Song compose(int chartPosition); } public interface SingerSongwriter extends Singer, Songwriter { AudioClip strumO; void actSensitiveO; }
  타입을 추상클래스로 정의하면, 그 타입에 기능을 추가하는 방법은 상속뿐이다. 상속으로 만든 클래스는 래퍼 클래스보다 활용도가 떨어지고 깨지기는 더 쉽다.	래퍼 클래스 관용구와 함께 사용하면 인터페이스는 기능을 향상시키는 안전하고 강력한 수단이 된다.

  • 자바 8부터 인터페이스도 default method를 제공할 수 있게 되어 두 메커니즘 모두 인스턴스 메서드를 구현형태로 제공할 수 있다.
    • 인터페이스의 메서드중 구현 방법이 명백한 것이 있다면, 그 구현을 디폴트 메서드로 제공해 일을 덜어줄 수 있다.

    default boolean removelf(Predicate<? super E> filter) {
    	Objects. requireNonNulK filter);
    	boolean result = false;
    	for (Iterator<E> it = iteratorO; it.hasNext();) {
    		if (filter.test(it.next())) {
    			it.removeO;
    			result = true;
    		}
    	}
    	return result;
    }

    • 디폴트 메서드를 제공할 때는 상속하려는 사람을 위한 설명을 @implSpec JavaDoc 태그를 붙여 문서화해야한다.
    • 디폴트 메서드의 제약 :
      • equals, hashCode 같은 Object의 메서드를 디폴트 메서드로 제공해서는 안된다.
      • 인스턴스 필드를 가질 수 없다
      • public이 아닌 정적 맴버도 가질 수 없다. (단 private 정적 메서드는 예외)
      • 자신이 만들지 않은 인터페이스에는 디폴트 메서드를 추가할 수 없다.
    • 템플릿 메서드 패턴 : 인터페이스와 추상 골격 구현(Skeletal implementation) 클래스를 함께 제공하는 식으로 인터페이스와 추상 클래스의 장점을 모두 취하는 방법
      • 인터페이스 :
        • 타입 정의
        • (필요하면)디폴트 메서드 몇 개도 함께 제공
      • 골격 구현 클래스 :
        • 나머지 메서드들까지 구현
      • 이렇게 구성하면, 골격 구현을 확장하는 것 만으로 이 인터페이스를 구현하는데 필요한 일이 완료된다. (템플릿 메서드 패턴)
      • 관례상 인터페이스 이름이 Interface라면 그 골격 구현 클래스의 이름은 AbstractInterface로 짓는다.
        • Ex) AbstractCollection, AbstractSet, AbstractList, AbstractMap이 핵심 컬렉션 인터페이스의 골격 구현이다.

      public abstract class AbstractList<E> extends AbstractCollection<E> implements
       List<E> {
      
      	protected AbstractList(){
          }
      }

      /*
      AbstractList에서 List 인터페이스를 대부분 구현하고 구현하지 않은 메서드는
      추상 메서드로 남겨놨다. 
      set(int index , E element) 메서드는 기본 구현체를 만들었고 구현 내용은 늘
      Exception이 던져지도록 만들었다. 
      이를 통해 list에 addAll() 을 하며 클라이언트가 set을 구현해야하는 수고를 덜수 있다.
      AbstractList 골격 구현으로 활용 */
      static List<Integer> intArrayAsList(int[] a) {
      	Objects.requireNonNulK a);
      
      	// 다이아몬드 연산자룔 이렇게 사용하는 건 자바 9부터 가능하다.
      	// 더 낮은 버전을 사용한다면 <Integer>로 수정하자.
      	return new AbstractList() {
      		@Override public Integer get(int i) {
      			return a[i]; // 오토박싱(아이템 6)
      		}
      		@Override public Integer set(int i, Integer val) {
      			int oldVal = a[i];
      			a[i] = val; // 오토언박싱
      			return oldVal; // 오토박상
      		}
      		@Override public int sizeO {
      			return a.length;
      		}
      	};
      }

      • 골격 구현 클래스의 장점 :
        • 추상 클래스처럼 구현을 도와준다
        • 추상 클래스로 타입을 정의할 때 따라오는 제약에서는 자유롭다
      • 구조상 골격 구현을 확장하지 못한다면, 인터페이스를 직접 구현해야한다.
      • 골격 구현 클래스를 우회적으로 이용할 수 있다
        • 인터페이스를 구현한 클래스에서 해당 골격 구현을 확장한 private 내부 클래스를 정의하고, 각 메서드 호출을 내부 클래스의 인스턴스에 전달하는 것 (Simulated multiple inheritance | 시뮬레이트한 다중 상속)
      • 골격 구현 작성 방법 :
        1. 인터페이스를 잘 살펴 다른 메서드들의 구현에 사용되는 기반 메서드들을 선정
           1. 이 기반 메서드들은 골격 구현에서는 추상 메서드가 된다.
        2. 기반 메서드들을 사용해 직접 구현할 수 있는 메서드를 모두 디폴트 메서드로 제공
           1. 단, equals와 hashCode 같은 Object의 메서드는 디폴트 메서드로 제공하면 안된다.
           2. 만약, 인터페이스의 메서드 모두가 기반 메서드와 디폴트 메서드가 된다면, 골격 구현 클래스를 별도로 만들 이유는 없다.
        3. 기반 메서드나 디폴트 메서드로 만들지 못한 메서드가 남아있다면, 이 인터페이스를 구현하는 골격 구현 클래스를 하나 만들어 남은 메서드들을 작성해 넣는다.
           1. 골격 구현 클래스에는 필요하면 public 이 아닌 필드와 메서드를 추가해도 된다.

        /*
        Map.Entry 인터페이스
        
        getKey, getValue는 확실히 기반 메서드이며, 선택적으로 setvalue도 포함할 수
        있다. 이 인터페이스는 equals와 hashCode의 동작 방식도 정의해놨다.
        Object 메서드들은 디폴트 메서드로 제공해서는 안 되므로,
        해당 메서드들은 모두 골격 구현 클래스에 구현한다.
        toString도 기반 메서드를 사용해 구현해놨다.
        
        Map.Entry 인터페이스나 그 하위 인터페이스로는 이 골격 구현을 제공할 수 없다. 
        디폴트 메서드는 equals, hashCode, toString 같은 Object 메서드를 재정의할 수
        없기 때
        */
        public abstract class AbstractMapEntry<K,V> implements Map.Entry<K,V> {
        	// 변경 가능한 엔트리는 이 메서드를 반드시 재정의해야 한다.
        	@Override public V setValue(V value) {
        		throw new UnsupportedOperationException();
        	}
        	// Map.Entry.equals의 일반 규약을 구현한다.
        	@Override public boolean equals(Object o) {
        		if (o = this)
        			return true;
        		if (!(o instanceof Map.Entry))
        			return false;
        		Map.Entry<?,?> e = (Map.Entry) o;
        		return Obj ects. equa Is (e. getKey (), getKeyO)
        			&& Objects.equals(e.getValue(), getValue());
        	}
        	// Map.Entry.hashCode의 일반 규약을 구현한다.
        	@Override public int hashCodeO {
        	return Objects.hashCode(getKey()) ^ Objects.hashCode(getValue());
        	}
        	@0verride public String toStringO {
        		return getKey() + "=" + getValueO;
        	}
        }

        • 골격 구현은 기본적으로 상속해서 사용하는 걸 가정하므로 설계 및 문서화 지침을 모두 따라야 한다.
          • 인터페이스에 정의한 디폴트 메서드든 별도의 추상 클래스든, 골격 구현은 반드시 그 동작 방식을 잘 정의해 문서화 주석으로 남겨야한다
        • 핵심 정리 :
          • 일반적으로 다중 구현용 타입으로는 인터페이스가 가장 적합하다.
          • 복잡한 인터페이스라면 구현하는 수고를 덜어주는 골격 구현을 함께 제공하는 방법을 꼭 고려해보자.
          • 골격 구현은 ‘가능한 한’ 인터페이스의 디폴트 메서드로 제공하여 그 인터페이스를 구현한 모든 곳에서 활용하도록 하는 것이 좋다.
          • ‘가능한 한’이라고 한 이유는, 인터페이스에 걸려 있는 구현상의 제약 때문에 골격 구현을 추상 클래스로 제공하는 경우가 더 흔하기 때문이다.

          // 인터페이스 정의
          interface MyInterface {
              void myMethod();
          }
          
          // 골격 구현 클래스
          public abstract class MyAbstractClass implements MyInterface {
              // 기본 동작을 제공하는 메서드
              public void myMethod() {
                  System.out.println("Default implementation of myMethod");
              }
          
              // 다른 메서드나 추가적인 동작을 제공할 수 있음
              public void anotherMethod() {
                  System.out.println("Some additional method");
              }
          }
          
          // 실제 사용할 클래스
          public class MyClass extends MyAbstractClass {
              // 필요에 따라 메서드를 오버라이드하여 수정 또는 확장 가능
              public void myMethod() {
                  System.out.println("Custom implementation of myMethod");
              }
          
              public static void main(String[] args) {
                  MyClass myObject = new MyClass();
                  myObject.myMethod(); // 커스텀 구현이 호출됨
                  myObject.anotherMethod(); // 기본 구현에서 상속된 메서드 호출
              }
          }

2. 인터페이스는 구현하는 쪽을 생각해 설계하라

• 설명

  • 자바 8 전 : 기존 구현체를 깨지 않고는 인터페이스에 메서드를 추가할 방법이 X
    • 인터페이스에 메서드를 추가하면 보통은 컴파일 오류가 나는데, 추가된 메서드가 우연히 기존 구현체에 이미 존재할 가능성은 아주 낮기 때문

  • 자바 8 : 디폴트 메서드가 정의된 인터페이스를 구현하면, 구현한 후 디폴트 메서드를 재정의하지 않은 모든 클래스에 디폴트 구현이 쓰인다.
    • 기존 인터페이스에 메서드를 추가할 수 있도록 디폴트 메서드를 소개했지만, 모든 기존 구현체들과 매끄럽게 연동되리라는 보장은 없다.
      • 자바 7 까지는 모든 클래스가 현재의 인터페이스에 새로운 메서드가 추가될 일은 영원이 없다고 가정하고 작성되었기 때문

  • 생각할 수 있는 모든 상황에서 불변식을 해치지 않는 디폴트 메서드를 작성하기는 어렵다
    • 자바 8의 Collection 인터페이스에 추가된 removeIf 메서드

      /*
      주어진 불리언 함수（predicate；）가 true를 반환하는 모든 원소를 제거.
      디폴트 구현은 반복자를 이용해 순회하면서 각 원소를 인수로 넣어 predicate를
      호출하고, predicate가 true를 반환하면 반복자의 remove 메서드를 호출해 
      그 원소를 제거한다.
      */
      default boolean removelf(Predicate<? super E> filter) {
      	Objects. requireNonNulK filter);
      	boolean result = false;
      	for (Iterator<E> it = iteratorO; it.hasNext(); ) {
      		if (filter.test(it.next())) {
      			it. removeO;
      			result = true;
      		}
      	}
      	return result;
      }

    • 이 코드는 범용적으로 구성되었지만, 현존하는 모든 Collection 구현체와 잘 어우러지는 것은 아니다
    • Ex) org.apache.commons.collections4.collection.SynchronizedCollection
      • java.util의 Collections.synchronizedCollection 정적 팩터리 메서드가 반환하는 클래스와 비슷하다.
      • 하지만 아파치 버전은 removeIf 메서드를 재정의하지 않고있기 때문에 메서드 호출을 알아서 동기화해주지 못한다.
    • 이런 문제를 예방하기위해 자바 플랫폼 라이브러리가 취한 조치
      • 구현한 인터페이스의 디폴트 메서드를 재정의하고, 다른 메서드에서는 디폴트 메서드를 호출하기 전에 필요한 작업을 수행하도록 한다
        • Collections.synchronizedCollection이 반환하는 package-private 클래스들은 removeIf를 재정의하고, 이를 호출하는 다른 메서드들은 디폴트 구현을 호출하기 전에 동기화를 하도록 한다
    • 하지만, 자바 플랫폼에 속하지 않은 제3의 기존 컬렉션 구현체들은 이런 언어 차원의 인터페이스 변화에 발맞춰 수정될 기회가 없었고, 일부는 여전히 수정되지 않은 상태
    • 디폴트 메서드는 (컴파일에 성공하더라도) 기존 구현체에 런타임 오류를 일으킬 수 있다.
      • 따라서 기존 인터페이스에 디폴트 메서드로 새 메서드를 추가하는 일은 꼭 필요한 경우가 아니면 피해야 한다.
      • 추가하려는 디폴트 메서드가 기존 구현체들과 충돌하지 않을지 심사숙고해야한다.
    • 반면, 새로운 인터페이스를 만드는 경우라면 표준적인 메서드 구현을 제공하는 데 아주 유용한 수단이며, 그 인터페이스를 더 쉽게 구현해 활용할 수 있게끔 해준다.
    • 디폴트 메서드는 인터페이스로부터 메서드를 제거하거나 기존 메서드의 시그니처를 수정하는 용도가 아님을 명심해야한다
      • 이런 형태로 인터페이스를 변경하면 반드시 기존 클라이언트를 망가뜨리게 된다
    • 디폴트 메서드라는 도구가 생겼더라도 인터페이스를 설계할 때는 여전히 세심한 주의를 기울여야 한다.
      • 새로운 인터페이스라면 릴리스 전에 반드시 테스트를 거쳐야한다.
      • 각 인터페이스의 인스턴스를 다양한 작업에 활용하는 클라이언트도 여러개 만들어봐야한다.
      • 인터페이스를 릴리스 한 후라도 결함을 수정하는게 가능한 경우도 있겠지만, 절대 그 가능성에 기대서는 안된다.

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

• 설명

  • 인터페이스 : 자신을 구현한 클래스의 인스턴스를 참조할 수 있는 타입 역할
    • 클래스가 어떤 인터페이스를 구현한다 == 자신의 인스턴스로 무엇을 할 수 있는지를 클라이언트에 얘기해주는것 (오직 이 용도로만 사용해야 한다)

  • 지침에 맞지않는 Ex) 상수 인터페이스
    • 메서드 없이, 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이 아닌 클래스가 상수 인터페이스를 구현한다면 모든 하위 클래스의 이름 공간이 그 인터페이스가 정의한 상수들로 오염되어 버린다.

  • 상수를 공개하는 합당한 방법들
    1. 특정 클래스나 인터페이스와 강하게 연관된 상수를 그 클래스나 인터페이스 자체에 추가
       1. Ex) 모든 숫자 기본 타입의 박싱 클래스 (Integer과 Double에 선언된 MIN_VALUE와 MAX_VALUE)
    2. 열거 타입으로 나타내기 적합한 상수라면 열거 타입으로 만들어 공개

       public enum Day{ MON, TUE, WED, THU, FRI, SAT, SUN};

    3. 둘다 아니라면, 인스턴스화 할 수 없는 유틸리티 클래스에 담아 공개

       // 상수 유틸리티 클래스
       /*
       숫자 리터럴에 사용한 밑줄(_)에 주목해보자. 자바 7부터 허용되는 이 밑줄은 숫자 리터
       럴의 값에는 아무런 영향을 주지 않으면서, 읽기는 훨씬 편하게 해준다. 고정소수점 수
       든 부동소수점 수든 5자리 이상이라면 밑줄을 사용하는 걸 고려해보자. 십진수 리터럴도
       (정수든 부동소수점 수든) 밑줄을 사용해 세 자릿씩 묶어주는 것이 좋다.
       */
       package effectivejava.chapter4.item22.constantutilityclass;
       
       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;
       }

       1. 유틸리티 클래스에 정의된 상수를 클라이언트에서 사용하려면 클래스 이름까지 함께 명시해야 한다. (PhysicalConstants.AVOGADROS_NUMBER)
       2. 유틸리티 클래스의 상수를 빈번히 사용한다면 정적 임포트(static import)하여 클래스 이름은 생략할 수 있다.

          import static effectivejava.chapter4.item22.constantutilityclass.Physical
          Constants. *;
          
          public class Test {
          	double atoms(double mols) {
          		return AVOGADROS_NUMBER * mols;
          	}
          // PhysicalConstants를 빈번히 사용한다면 정적 임포트가 값어치를 한다.
          }

4. 참조

• 골격 구현 클래스 : https://xonmin.tistory.com/18

• 이펙티브 자바 : 아이템 20,21,22