[Item 20] Default method의 제약

[zpqmdh]

책 132쪽에서는 Default method 의 제약에 대해 설명하고 있습니다.

디폴트 메서드에도 제약은 있다. 많은 인터페이스가 equals 와 hashCode 같은 Object 의 메서드를 정의하고 있지만, 이들은 default method로 제공해서는 안 된다. 또한 인터페이스는 인스턴스 필드를 가질 수 없고 public이 아닌 정적 멤버도 가질 수 없다(단, private 정적 메서드는 예외다). 마지막으로, 여러분이 만들지 않은 인터페이스에는 default method를 추가할 수 없다.

총 3가지 제약에 대해 구체적으로 왜 안 되는지 설명해주실 수 있나요?

[ForteEscape]

Q.

Default method의 제약에 대해 설명하고 있습니다. 이때 3가지 제약에 대해 구체적으로 왜 안 되는지 설명해주실 수 있나요?

A.

• 먼저 인터페이스의 규칙을 알아보겠습니다. 인터페이스의 내부 규칙은 다음과 같습니다.
  • 인터페이스는 abstract이기 때문에 자기 자신이 객체 인스턴스로 생길 수 없습니다. 따라서 생성자를 만드는 것 자체가 불가능합니다.
  • 인터페이스의 모든 필드는 반드시 public static final로 선언되어야 합니다. 만약 이런 제한자가 붙지 않을 경우, 컴파일 타임에 자동으로 public static final이 붙습니다.
  • 인터페이스에서 default method를 제외한 모든 메서드는 public abstract 수식어가 붙어야 합니다. 필드와 마찬가지로 이런 제한자가 붙지 않을 경우 컴파일 타임에 자동으로 public abstract 수식어가 붙습니다.

1. 인터페이스가 인스턴스 필드를 가질 수 없는 이유

• 먼저 인터페이스가 인스턴스 필드를 가질 수 없는 이유에 대해 답변하겠습니다.
• 인스턴스 필드는 객체 인스턴스가 자신을 표현하기 위한 속성값입니다. 즉 인스턴스 필드는 객체 인스턴스가 존재할 때 성립합니다.
• 하지만 인터페이스의 규칙 1번에서 인터페이스 자신이 abstract하기 때문에(abstract 메서드를 가지므로) 객체 인스턴스를 생성하는 것이 불가능합니다. 따라서 인스턴스 필드를 가질 수 없습니다.

---

2. 인터페이스가 public이 아닌 static 멤버를 가질 수 없는 이유

• 두 번째로 public이 아닌 정적 멤버를 가질 수 없는 이유에 대해 설명하겠습니다.
• 먼저 인터페이스의 규칙 2에 의해 이런 상황이 발생하는 것이기 때문에 규칙 정의 그 자체에 대한 의문을 답할 수 없다고 생각하며 다만 왜 이렇게 설계했는지에 대한 제 생각을 말씀드리겠습니다.
• 인터페이스는 그 자체로는 아무것도 할 수 없으며 자신을 구현(implements)하는 클래스가 존재해야 비로소 그 역할을 다 할 수 있는 요소입니다.
• 문제는 이 구현(implements)는 상속과 같이 인터페이스의 모든 요소를 자신을 구현하는 하위 클래스에 물려준다는 것입니다. 이때 private 키워드가 붙은 메서드 및 변수들은 모두 상속 대상에서 제외됩니다. 따라서 만약 존재한다 해도 아무런 의미를 가지지 못하게 됩니다.
  • 단 private static method는 예외인데 default method와 같은 곳에서 해당 메서드를 사용하지만 이를 외부에 공개하고 싶지는 않을 때 사용하는 경우가 존재하기 때문입니다.
  • 인터페이스에서의 private method는 원래는 필요하지 않았으나, JDK 1.8에서 default method가 추가되면서 필요성이 생겼고, 그 다음 릴리즈인 JDK 1.9에서 추가되었습니다.

---

3. 우리가 만들지 않은 인터페이스에서는 default method를 추가할 수 없다.

• 사실 이것은 절대적으로 불가능하진 않은 규칙입니다. 다만 추가할 경우에 많은 문제가 발생할 수 있습니다.
• 먼저 default method에 대해 간략히 서술하자면 어떤 메서드의 구현에 대해 미리 구현을 정의해 놓은 메서드를 default method라고 정의합니다.
  • 이 default method는 자신을 구현하는 하위 클래스에 대해 default method를 재정의(Overriding)하는 경우가 아니라면 default method에서 정의한 동작을 수행하도록 하고 있습니다.
  • 만약 저희가 만들지 않은 인터페이스에 default method를 추가하게 된다면 다음과 같은 상황이 발생할 수 있습니다.
    • 인터페이스에 default method를 추가한 순간 그 인터페이스를 구현하는 모든 하위 클래스에 default method가 들어갑니다.
    • 문제는 만약 어떤 클래스가 다른 인터페이스도 구현하고 있고(인터페이스는 다중 상속을 허용하기 때문에 충분히 가능한 일입니다.) 다른 인터페이스에 동일한 default method signiture를 가지고 있다면 컴파일 단계에서 에러가 발생하게 되고, 시스템이 망가지게 될 수 있습니다.
    • 이는 둘 중 하나의 default method를 재정의하여 해결할 수 있지만 다른 인터페이스에서 구현한 default method와 우리가 추가한 default method가 동일한 동작을 정의하고 있을 확률은 매우 적습니다. 그런데 재정의를 해버린다면 둘 중 하나의 default method가 무시되고, 무시된 인터페이스 메서드를 호출할 시 잘못된 동작을 수행할 것입니다.
• 이런 이유로 만들지 않은 인터페이스에 default method를 추가하는 것은 좋지 않은 선택임을 확인할 수 있습니다.

---

4. equals(), hashCode() 메서드는 default method로 제공하면 안된다.

• default method는 인터페이스의 기본적인 구현을 제공하는 메서드라고 설명했습니다. 문제는 모든 객체들이 equals(), hashCode()를 재정의 하지는 않는다는 것입니다.
• default method는 자신을 재정의하지 않는다면 그대로 하위 클래스에 자신의 코드를 물려줍니다. hashCode()는 물론이고 equals()에 대해서도 큰 문제가 발생할 수 있습니다.
  • 하위 클래스가 equals()를 재정의하지 않는다면 상위 인터페이스에 적힌 규약대로 equals()가 구현되게 되어 equals()의 일반 규약(item 10)이 깨어질 위험성이 매우 커질 수 있습니다.
  • hashCode() 역시 객체가 표현하는 값들을 hashCode()에 모두 담지 못할 수 있으므로 문제가 발생할 수 있습니다. 또한 equals()와 마찬가지로 규약이 깨어질 위험성이 매우 커질 수 있습니다.
  • 이는 clone()도 마찬가지입니다.
  • 이런 문제를 피하기 위해서는 해당 인터페이스를 구현하는 하위 클래스들은 반드시 equals()와 hashCode()를 재정의해야하며 이는 재정의할 필요가 없는 클래스까지도 구현이 강제되어 이를 개발하는 개발자에게 부담을 줄 수 있습니다.
• 따라서 이런 메서드들은 default method로 물려주기 보다는 선택(Option)에 따라 재정의하여 구현하도록 해야 할 것입니다.