<aside> 😅 인터페이스란 필자가 생각하기엔 객체를 바라보는 하나의 모양이라고 생각한다. 아래의 그림과 같은 형태를 보는 거다. 한 사람은 컵으로 볼 수 있고, 다른 사람은 사람의 형상 두가지를 볼 수 있다. 이렇듯 필자가 생각하기엔 인터페이스는 같은 형태를 다르게 볼 수 있도록 만들어주는 하나의 창이라고 생각한다. 물론, 백기선님은 규약이라고 이야기해주셨다. 근데 내가 설명하는 것은 인터페이스를 어떻게 바라볼까? 좀 더 쉽게 바라볼 수 없을까? class상속과 다르게 interface를 이야기 하려면 어떤 예제가 좋을까? 를 생각하며 이 그림과 설명을 만들었다.

</aside>

<aside> 📌 그렇다면 정확한 인터페이스의 정의는 뭘까? 대충 oracle java tutorial의 내용에서는 interface를 다음과 같이 정의하고 있다. “서로 모르는 프로그래머들도 다른 그룹의 코드가 어떻게 작성되는지 몰라도 코드를 작성할 수 있어야 한다. 이러기 위해서는 일종의 계약, 규약이 필요하며 이러한 계약 또는 규약을 interface라 정의한다.” 한 마디로 규약이 맞다.

</aside>

interface정의

<aside> 📌 interface를 정의할 때 아래와 같은 형태를 가질 수 있다.

• 만약 상속 구조가 있을 경우(인터페이스가 인터페이스를 상속 받거나 다중으로 상속받는 경우) 서브 인터페이스는 수퍼인터페이스의 메서드까지 모두 구현해야한다.
• 인터페이스 레퍼런스는 인터페이스를 구현한 클래스의 인스턴스를 가르킬 수 있고, 해당 인터페이스는 선언된 메서드만 호출할 수 있다.

</aside>

public interface 인터페이스 명{
	// 상수
	타입 상수명 = 값; // public static final이 기본 값이다.
	
	// 추상 메소드
	타입 메소드명(매개변수, ...); // public abstract가 기본이다.

	// 디폴트 메소드
	default 타입 메소드명(매개변수, ...){
		// 구현부
	}

	// 정적 메소드
	static 타입 메소드명(매개변수, ...){
		// 구현부
	}
}

interface구현

<aside> 📌 interface의 경우 단독으로 사용하는 목적이 아닌 구현 이후 같은 타입에 맞추어(아까 위의 개념에서 설명한 모양을 맞춰주어) 갈아 끼우며 사용하기 위하여 사용한다. 그렇기 때문에 interface 단독으로는 abstract class와 같이 인스턴스를 만들지 못하며 구현해야 한다. interface의 경우 다중 상속이 가능하다. 물론 일반적 상속 메커니즘을 따르고 있으며, default 접근제어자가 붙은 메서드는 조금 특별히 선택적으로 재정의가 가능하다. 물론 static이 붙은 메서드와 private가 붙은 메서드는 재정의가 불가능하다. 물론 익명객체의 형식으로 만들어 사용할 수도 있고, 특별한 상황에서는 람다를 이용하여 구현할 수 있다.

</aside>

public class 구현 클래스 명 implements 인터페이스 명 {
	// 인터페이스에 선언된 추상 메소드의 실체 메소드 선언
}

interface default method

인터페이스를 구현하는 클래스는 인터페이스에서 정의하는 모든 메서드 구현을 제공하거나 아니면 슈퍼클래스의 구현을 상속받아야한다. 이는 다시 말하면 인터페이스를 상속받는 구현해야하는 의무를 지닌 클래스는 인터페이스 내부에 정의된 모든 메서드를 구현해야한다. 이렇게 된다면 무슨일이 벌어질까? 예를 들어 내가 sort()라는 메서드를 인터페이스 내부에 정의하는 것을 까먹고 라이브러리를 출시했다. 차후 이를 알게 된 나는 모든 자료구조에 대한 sort를 다시 재정의해줘야한다. 이렇듯 나는 많이 당황스러울 것이다. 하지만 이를 해결하고자 새로운 기능이 자바 8에 추가 되었다. 기본 구현을 포함하는 인터페이스 정의방법을 두가지로 나누어 제공한다. 하나는 인터페이스 내부에 정적 메서드를 사용하는 것과 두번째로 인터페이스의 기본 구현을 제공할 수 있도록 디폴트 메서드 기능을 사용하는 것이다. 결과적으로 기존 인터페이스를 구현하는 클래스는 자동으로 인터페이스의 디폴트 메서드를 상속받게 되고 이를 구현해야하는 의무를 덜 수 있다.

<aside> 📌 위의 내용은 내가 이전에 default method에 대하여 공부하였을 때 기술한 내용이다. 꼭꼭 읽어주면 좋겠다. 포함하고 있는 내용은 다음과 같다

• default method의 탄생
• 개념
• 장점
• 인터페이스의 사용이 가져오는 효율성
• 디폴트 메서드를 활용한 예제
• 디폴트 메서드의 단점(다이아몬드 문제, 해결 규칙)

</aside>

‣

interface static method

<aside> 📌 처음엔 이걸 왜 만들었을까? 이런 생각을 조금 가졌다. 하지만 해당 기능은 유용한 코딩을 제공한다. 예를 들면 우리의 절친 Stream에서 조금의 해답을 찾을 수 있었다. Stream에서 제공하는 기능은 안다고 생각하고 static이 붙은 메서드와 구현하여 사용하는 메서드 두 종류가 존재한다. 근데 이게 API를 유심히 보다보니 특이점 하나를 발견할 수 있었다.

</aside>

abstract method

static method