하나의 소스 파일에 톱레벨 클래스를 여러개 선언하는 건 작성 당시에는 문제가 발생하지 않지만 경우에 따라서 컴파일 오류가 발생할 수 있다. 또한 이는 단일 책임 원칙 (Single responsibility principle)원칙에 어긋난다.

톱레벨 클래스는 서로 다른 소스 파일로 분리 해야한다. 굳이 여러 톱레벨 클래스를 한 파일에 담고 싶다면 정적 멤버 클래스를 사용할 수도 있다. 

소스 파일 컴파일 순서에 따라 바이너리 파일이나 프로그램의 동작이 달라지는 일이 생기는 걸 예방할 수 있다.

• final이 아닌 클래스가 상수 인터페이스를 구현한다면 모든 하위 클래스의 이름공간이 그 인터페이스가 정의한 상수들로 오염되어 버린다.
• 특정 클래스, 인터페이스와 강하게 연관된 상수라면 그 클래스나 인터페이스 자체에 추가해야한다. Integer.MIN_VALUE, Double.MAX_VALUE의 경우
• 열거 타입, 인스턴스화할 수 없는 유틸리티 클래스로 담아서 공개
• 유틸리티 클래스의 상수를 빈번히 사용한다면 정적 임포트(static import)하여 클래스 이름은 생략할 수 있다.

• 자바 8부터 인터페이스도 디폴트 메서드(default method)를 제공할 수 있게 되었다.(https://docs.oracle.com/javase/specs/jls/se17/html/jls-9.html#jls-9.4.3)
• 인터페이스는 믹스인(mixin)정의에 안성맞춤이다. - 믹스인 : 클래스의 주된 목적 외에 특정 선택적 기능을 제공(Comparable 자신을 구현한 클래스의 인스턴스들끼리 순서를 정할 수 있다.)
• 인터페이스로는 계층구조가 없는 타입 프레임워크를 만들 수 있다. 거대한 클래스 계층구조에는 공통 기능을 정의해놓은 타입이 없으니, 자칫 매개변수 타입만 다른 메서드들을 수없이 많이 가진 거대한 클래스를 낳을 수 있다.
• 래퍼 클래스 컴포지션(아이템 18)과 함께 사용하면 인터페이스는 기능을 향상시키는 안전하고 강력한 수단이 된다. 
• 인터페이스 + 추상 골격 구현 클래스 함께 제공하는 템플릿 메서드 패턴은 골격 구현을 확장하는 것으로 인터페이스를 구현하는데 필요한 일을 모두 할 수 있다.

static List<Integer> intArrayAsList(int[] a) {
        Objects.requireNonNull(a);
        
        //다이아몬드 연산자를 이렇게 사용하는 건 자바 9부터 가능하다.
        // 더 낮은 버전을 사용한다면 <Integer>로 수정하자.
        return new AbstractList<Integer>() {
            @Override
            public Integer get(int index) {
                return a[i];
            }
            
            @Override public Integer set(int i, Integer val) {
                int oldVal = a[i];
                a[i] = val;
                return oldVal;
            }

            @Override
            public int size() {
                return a.length;
            }
        };
    }

위 코드는 골격 구현의 적합한 예시

골격 구현 작성 방법

1. 인터페이스에서 다른 메서드 구현에 사용되는 기반 메서드(->추상메서드)를 선정 
2. 기반 메서드를 사용해 직접 구현할 수 있는 메서드를 디폴트 메서드로 제공
3. 기반, 디폴트 메서드가 아닌 대상을 골격 구현 클래스에 작성

인터페이스의 속성

• 인스턴스 필드를 가질 수 없다.
• public이 아닌 정적 멤버도 가질 수 없다.
• * private 정적 메서드는 예외로 가질 수 있다.
• 작성하지 않은 인터페이스에는 디폴트 메서드를 추가할 수 없다.