JDK의 Collection 소스 코드에는 이러한 작성 방법이 많이 있습니다. 사실 이런 글쓰기 방식은 부작용이 없다는 점을 인정해야 합니다. 그런데 이렇게 작성하면 LinkedHashMap의 소스코드를 따로 열어보면 어떤 클래스를 상속하고 어떤 인터페이스를 구현하는지 알 수 있다는 장점이 있습니다. 즉, HashMap가 LinkedHashMap을 구현한다는 것을 알기 위해 Map의 소스 코드를 클릭할 필요가 없습니다. 즉, 특히 클래스 간의 상속 관계가 복잡한 경우 상속 관계에 대해 걱정할 필요가 없습니다.
이 는 인도적인 고려에 기초합니다. 인터페이스가 인터페이스를 상속하지만 하위 인터페이스는 명시적으로 선언됩니다. 상위 인터페이스 모든 메소드에 @Override 주석을 명시적으로 추가하여 이 메소드가 상위 인터페이스에서 상속되며 내가 정의한 인터페이스와 아무 관련이 없음을 구체적으로 나타냅니다.
사실 이는 단지 Java 개발자의 관행일 수도 있습니다. 일반적으로 우리의 요구 사항은 특정 클래스가 어떤 인터페이스를 구현해야 하는지 명시하지만 실제로 이러한 인터페이스의 상호 종속성을 찾아 중복 프로젝트를 제거하는 데 어려움을 겪는다면 프로세스가 번거로워지고 이러한 중복은 또한 컴파일 타임에 자동으로 처리됩니다. 그래서 이 사람들은 구현해야 하는 클래스를 직접 작성해 수동으로 중복을 제거하는 수고를 덜었습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
JDK의 Collection 소스 코드에는 이러한 작성 방법이 많이 있습니다.
사실 이런 글쓰기 방식은 부작용이 없다는 점을 인정해야 합니다.
그런데 이렇게 작성하면
LinkedHashMap의 소스코드를 따로 열어보면 어떤 클래스를 상속하고 어떤 인터페이스를 구현하는지 알 수 있다는 장점이 있습니다. 즉,HashMap가LinkedHashMap을 구현한다는 것을 알기 위해Map의 소스 코드를 클릭할 필요가 없습니다. 즉, 특히 클래스 간의 상속 관계가 복잡한 경우 상속 관계에 대해 걱정할 필요가 없습니다.이 는 인도적인 고려에 기초합니다.
인터페이스가 인터페이스를 상속하지만 하위 인터페이스는 명시적으로 선언됩니다. 상위 인터페이스 모든 메소드에 @Override 주석을 명시적으로 추가하여 이 메소드가 상위 인터페이스에서 상속되며 내가 정의한 인터페이스와 아무 관련이 없음을 구체적으로 나타냅니다.
사실 이는 단지 Java 개발자의 관행일 수도 있습니다.
일반적으로 우리의 요구 사항은 특정 클래스가 어떤 인터페이스를 구현해야 하는지 명시하지만 실제로 이러한 인터페이스의 상호 종속성을 찾아 중복 프로젝트를 제거하는 데 어려움을 겪는다면 프로세스가 번거로워지고 이러한 중복은 또한 컴파일 타임에 자동으로 처리됩니다. 그래서 이 사람들은 구현해야 하는 클래스를 직접 작성해 수동으로 중복을 제거하는 수고를 덜었습니다.
소스코드를 보면 클래스의 정의만 보일 뿐, 이 이유에 대한 더 깊은 탐구는 없습니다. Java에서는 하나의 클래스만 상속할 수 있지만 여러 다른 인터페이스를 구현할 수 있다는 것을 알고 있습니다.
으아악