[이펙티브 자바] Item20 완벽공략. 디폴트 메서드와 Object 메서드

 

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

" p.135 디폴트 메서드는 equals, hashCode, toString 같은 Object 메서드를 재정의할 수 없기 때문이다."

 

 

public interface MyInterface
{
   default String toString()
   {
      return "myString";
   }

   default int hashCode()
   {
      return 10;
   }

   default boolean equals(Object o)
   {
      return true;
   }
}

이렇게 인터페이스에 Object 메서드를 재정의하려고 하면 

Default method 'toString' overrides a member of 'java.lang.Object'

라고 컴파일 에러가 발생한다. 

 

사실 인터페이스는 인스턴스 필드를 가질 수도 없고, public 아닌 정적 멤버도 가질 수 없기 때문에 굳이 인터페이스에 equals와 같은 메서드를 재정의하는 경우는 거의 없을 것 같다..! 

 

https://mail.openjdk.org/pipermail/lambda-dev/2013-March/008435.html

Allow default methods to override Object's methods

The key goal of adding default methods to Java was 
"interface evolution", not "poor man's traits." 

-> 인터페이스에서 디폴트 메서드를 추가한 핵심적인 목적은 "인터페이스의 진화" 라고 한다. 

 

 

2.  Adds complexity.  Supporting this behavior had the cost of making 
the inheritance model more complicated.  This is definitely a negative; 
there is already a lot of fear that "multiple inheritance" (as if Java 
didn't already have multiple inheritance (of types) from day 1) will 
make Java a lot more complicated.  A great deal of effort went into 
coming up with the simplest possible rules for how implementation 
inheritance will work, which are:

Rule #1: Classes win over interfaces.  If a class in the superclass 
chain has a declaration for the method (concrete or abstract), you're 
done, and defaults are irrelevant.

Rule #2: More specific interfaces win over less specific ones (where 
specificity means "subtyping").  A default from List wins over a default 
from Collection, regardless of where or how or how many times List and 
Collection enter the inheritance graph.

그리고 두 가지 규칙이 존재한다고 설명하고 있는데 

- 클래스가 인터페이스를 이긴다. 
- 더 구체적인 인터페이스가 이긴다. 

로 원래 객체는 Object를 상속하고 있는데 인터페이스에서 만약 디폴트 메서드를 재정의하고 있다면.. 어디를 따라야 하는가? 

이런 문제도 있고.. 

 

 

3.  Really only makes sense in toy examples.  When designing default 
methods, I talked to a number of folks like yourself who asked for this 
feature.  And I asked them to give me an example.  Invariably, the 
example was a type like List.  And invariably, after some digging, it 
would become clear that this feature only makes sense in situations 
where the type in question was exclusively single-inherited.  Giving 
people a feature that is essentially multiple inheritance of behavior, 
but which breaks if you actually *use* multiple inheritance, does not 
seem smart.

인터페이스에 Object 메서드를 재정의하려고 하는 건 사실 실용적이지도 않고 토이 예제에서나 가능하고 어울리는 기능이라고 한다.. 

 

 

4.  It's brittle.  Methods like equals are really fundamental; you don't 
want a classes equals() behavior changing out from under you when a 
library is rev'ed and someone adds an equals() implementation to some 
interface that you indirectly inherit from nine levels away.  But this 
is exactly what would happen if someone added an equals() method to an 
existing interface, if its subtypes didn't provide their own equals().

마지막으로는 인터페이스에 Object 메서드를 재정의하는 건 불안정하다. 

 

 

📚 정리 

https://mail.openjdk.org/pipermail/lambda-dev/2013-March/008435.html

Allow default methods to override Object's methods

4가지 정도의 이유를 들며 인터페이스의 디폴트 메서드로 Object 메서드를 재정의할 수 없는 이유에 대해서 얘기하고 있다. 

한번씩 읽어보는걸 추천!!