Java 8 기본 메소드가 사용자 코드를 손상시키나요?

처음에는 기본 메소드가 Java 가상 머신의 명령어 세트에 많은 새로운 기능을 제공하는 것처럼 보입니다. 궁극적으로 라이브러리 개발자는 클라이언트 코드와의 호환성 문제 없이 API를 업그레이드할 수 있습니다. 기본 메서드를 사용하면 라이브러리 인터페이스를 구현하는 모든 클래스가 인터페이스에서 도입된 기본 메서드에 자동으로 적응합니다. 사용자가 구현한 클래스를 업데이트하면 원래 기본 메서드를 보다 의미 있는 메서드로 쉽게 재정의할 수 있습니다. 더 좋은 점은 사용자가 인터페이스의 기본 구현을 호출하고 메서드를 재정의할 때 비즈니스 논리를 추가할 수 있다는 것입니다.

지금까지는 너무 좋았습니다. 그러나 인터페이스를 생성할 때 기본 메서드를 추가하면 Java 코드가 호환되지 않을 수 있습니다. 이는 아래 예를 통해 쉽게 이해할 수 있습니다. 라이브러리에 인터페이스 중 하나가 입력으로 필요하다고 가정해 보겠습니다.

interface SimpleInput {   void foo();   void bar(); }  abstract class SimpleInputAdapter implements SimpleInput {   @Override   public void bar() {     // some default behavior ...   } }

Java 8 이전에는 인터페이스와 어댑터 클래스를 결합하는 위의 방법과 유사하며 이는 Java 프로그래밍 언어에서 매우 일반적인 디자인 패턴이었습니다. 이 어댑터는 일반적으로 라이브러리 사용자가 특정 작업을 저장하기 위해 라이브러리 공급자가 제공합니다. 하지만 인터페이스 형태로 제공된다면 다중상속을 허용하는 것과 유사하다.

또한 사용자가 다음 어댑터를 사용한다고 가정합니다.

class MyInput extends SimpleInputAdapter {   @Override   public void foo() {     // do something ...   }   @Override   public void bar() {     super.bar();     // do something additionally ...   } }

이 구현을 통해 마침내 라이브러리와 상호 작용할 수 있습니다. bar 메서드를 재정의하고 기본 구현에 추가 기능을 추가하는 방법에 주목하세요.

이 라이브러리를 Java 8로 포팅하면 어떻게 되나요? 첫째, 라이브러리는 어댑터 클래스를 더 이상 사용하지 않고 기본 메서드를 사용하여 이 기능을 제공할 가능성이 높습니다. 마지막으로 인터페이스는 다음과 같습니다.

interface SimpleInput {   void foo();   default void bar() {     // some default behavior   } }

이 새로운 인터페이스를 사용하면 사용자는 원래 어댑터 클래스 대신 기본 메서드를 사용하도록 코드를 업데이트할 수 있습니다. 어댑터 클래스 대신 인터페이스를 사용하는 궁극적인 결과는 클래스가 특정 어댑터가 아닌 다른 클래스를 확장할 수 있다는 것입니다. 이제 기본 메서드를 사용하도록 MyInput 클래스를 연습하고 이식해 보겠습니다. 이제 다른 클래스를 확장할 수 있으므로 타사 기본 클래스를 확장합니다. 여기서는 이 기본 클래스의 역할에 신경 쓸 필요가 없습니다. 이것이 우리 기능에 의미가 있다고 가정할 수 있습니다.

class MyInput extends ThirdPartyBaseClass implements SimpleInput {   @Override   public void foo() {     // do something ...   }   @Override   public void bar() {     SimpleInput.super.bar();     // do something additionally ...   } }

원래 클래스와 유사한 기능을 달성하기 위해 Java 8의 새로운 구문을 사용하여 지정된 인터페이스의 기본 메서드를 호출합니다. 동시에 메서드의 일부 논리를 기본 클래스로 이동합니다. 이 시점에서 여러분은 내 어깨를 두드리며 이렇게 말할 수도 있습니다. 이것은 매우 좋은 리팩토링입니다!

우리는 이 라이브러리를 매우 성공적으로 사용했습니다. 그러나 관리자는 더 많은 기능을 제공하기 위해 다른 인터페이스를 추가해야 합니다. 이 인터페이스는 SimpleInput 인터페이스에서 상속되고 새 메소드를 추가하는 ComplexInput 인터페이스로 대체됩니다. 기본 메소드는 일반적으로 추가해도 안전하므로 관리자는 더 나은 기본 메소드를 제공하기 위해 SimpleInput의 기본 메소드를 재정의했습니다. 결국 이것은 어댑터 클래스와 관련된 일반적인 일입니다.

interface ComplexInput extends SimpleInput {   void qux();   @Override   default void bar() {     SimpleInput.super.bar();     // so complex, we need to do more ...   } }

새로운 기능으로 인해 ThirdPartyBaseClass를 유지 관리하는 사람들도 이 라이브러리를 사용하기로 결정했을 정도로 좋은 결과를 얻었습니다. 이 작업을 수행하기 위해 ThirdPartyLibrary에 ComplexInput 인터페이스를 구현합니다.

그러나 이것이 MyInput 클래스에 무엇을 의미합니까? ComplexInput 인터페이스를 암시적으로 구현하기 위해 ThirdPartyBaseClass 클래스를 상속할 수 있지만 SimpleInput의 기본 메서드를 호출하는 것이 갑자기 불법이 됩니다. 결과적으로 사용자 코드가 컴파일되지 않습니다. Java에서는 직접적이지 않은 하위 클래스에서 상위 클래스의 메서드를 호출하는 것이 불법이라고 간주하므로 이러한 종류의 호출은 이제 금지됩니다. 이 기본 메소드는 ComplexInput에서만 호출할 수 있지만 이를 위해서는 MyInput에서 이 인터페이스를 명시적으로 구현해야 합니다. 도서관 사용자에게는 이러한 변화가 예상되지 않습니다!

더 이상한 점은 Java 런타임이 이러한 제한을 적용하지 않는다는 것입니다. JVM의 유효성 검사기를 사용하면 클래스가 업데이트된 ThirdPartyBaseClass를 상속하여 암시적으로 ComplexClass를 구현하는 경우에도 컴파일된 클래스가 SimpleInput::foo 메서드를 호출할 수 있습니다. 이 제한은 컴파일러에만 존재합니다.

위 내용은 Java 8 기본 메소드가 사용자 코드를 손상시키나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!