인터페이스의 사전적 의미는 다음과 같다.
하나의 시스템을 구성하는 2개의 구성 요소(하드웨어, 소프트웨어) 또는 2개의 시스템이 상호작용할 수 있도록 접속되는 경계(boundary), 이 경계에서 상호 접속하기 위한 하드웨어, 소프트웨어, 조건, 규약 등을 포괄적으로 가리키는 말
자바에서 인터페이스는 여러가지 역할로 사용한다.
먼저 자바에서 인터페이스의 기본 개념을 알아보자.
자바 인터페이스는 기본적으로 추상메서드의 모음이다. 추상메서드는 아래와 같이 구현부가 없는 메서드를 말한다.
public interface Walkable {
void walk();
}
구현부가 없으므로 인터페이스를 만든다면 반드시 구현하는 클래스를 만들어야 하며, 인터페이스를 구현하기로 한 클래스는 반드시 인터페이스에 명시되어 있는 추상메서드들을 모두 구현해야 한다. 만약 이를 구현하지 않으면 컴파일 에러가 발생한다.
public class Dog implements Walkable {
// ...
@Override
public void walk() {
// ...
}
}
인터페이스는 구현과 상속을 모두 할 수 있다.
인터페이스를 사용하면 다중 상속이 가능하다. 인터페이스 사이에서도, 구체 클래스에서도 여러 인터페이스를 구현 및 상속할 수 있다.
public interface Walkable {
void walk();
}
public interface Flyable {
void fly();
}
public interface Moveable extends Walkable, Flyable {
}
이를 구현한다면 다음과 같이 할 수 있다.
public class Bat implements Moveable {
@Override
public void walk() {
// ...
}
@Override
public void fly() {
// ...
}
}
인터페이스를 만들면서 접근제어자를 생략했는데 인터페이스는 클래스와 달리 기본 접근제어자는 public
이다. 인터페이스에 필드 변수를 선언하면 public static final
로 선언해야 하며 이 역시 생략하면 기본으로 설정되어 있다. 메서드를 private
로 설정하면 실제 구현체를 인터페이스 내에 구현해야 한다.(물론 이를 밖에서 사용할 수 없으므로 직접적으로 사용하는 곳은 적을 것으로 생각된다.)
자바8 버전 이상부터는 인터페이스에서 default
접근 제어자를 사용할 수 있게 되었다.
이는 인터페이스 내에서 직접 메서드를 구현한다는 의미의 접근 제어자이다. 이를 구현한 구체 클래스는 오버라이딩없이 이 default 메서드를 사용할 수 있고, 오버라이딩 역시 할 수 있다.
이로 인해 다중 상속일 때 고려해야할 사항이 많아지는 등 복잡했다. 하지만 이를 만든 주된 이유는 라이브러리 업데이트 때문이다. 인터페이스는 라이브러리나 프레임워크에서 매우 자주 사용된다. 라이브러리를 업데이트할 때 인터페이스에 추가된 기능이 있다면 이를 구현한 클래스 역시 추가해주어야 한다. 하지만 이 라이브러리를 사용하는 사용자가 해당 인터페이스를 구현한 클래스가 있다면 이를 구현하지 않아 컴파일 에러가 발생할 것이다. 이러한 심각한 불편함을 해소하기 위해 default
라는 키워드를 만들었다고 한다.
인터페이스를 사용하는 주된 이유는 다형성을 위해서라고 생각한다. 다형성은 상속받은 클래스 또는 인터페이스의 메서드를 재정의하여 서로 다른 행동을 만들 수 있다. 상속을 통해 상위 클래스의 타입으로 통일한 후 하위 클래스들을 하나의 타입으로 관리할 수 있다. 이를 사용해서 변경에 유연한 코드를 만들 수 있다.
인터페이스는 구현체가 없다. 이를 구현한 클래스에서 모든 구현체를 만들어야 한다.(default
접근 제어자 제외) 예를 들어 한 인터페이스를 구현한 A, B 클래스가 있다고 하자. 현재는 A 클래스를 사용하고 있지만, 인터페이스를 잘 설계했다면 다른 기존 코드의 변경이 거의 없이 B 클래스로 쉽게 변경할 수 있다. 자바의 JDBC가 이렇게 구현되어 있으며, 스프링에서도 대부분 이러한 인터페이스 장점을 잘 활용하고 있다.
다형성을 활용하기 위해서는 기본적으로 자바를 기준으로 클래스 상속과 인터페이스 구현으로 나뉜다. 이를 선택하는 것은 전적으로 개발자의 몫이다. 물론 이 판단을 도와주는 기준은 존재한다. 상속에 대해서는 일반적으로 다음과 같이 추천한다.
위를 보면 대부분 상속을 추천하지 않는다. 그만큼 비용이 큰 작업이기 때문이다. 변하지 않는 구조에서 상속을 사용하면 중복 코드를 제거하고 깔끔하게 코드를 작성할 수 있지만, 변화가 발생하는 순간 상속 구조는 깨지기 쉽다.
예를 들어 상속 관계에서 부모 클래스에 기능이 추가되었는데, 자식 클래스 중 하나에서 이를 사용할 수 없도록 해야 한다면 상속 구조가 깨질 수 있다. 따라서 상속은 기본적으로 Is-A 관계가 확실하고, 설계 이후에 변화가 없는 곳에서 사용해야 한다. 하지만 현실은 설계 이후에도 기능 변화가 비일비재 하다. 그래서 대부분 인터페이스를 사용한다.
인터페이스의 구현은 Can-Do 관계라고 말할 수 있다. 어떤 기능을 할 수 있다고 명세를 해주는 것이다. 위 상속 문제에서 일부 자식 클래스에서는 필요하고, 일부에서는 필요하지 않는 기능이 있다고 했다. 이러한 기능들은 설계 이후에 생기는 경우가 빈번하다. 이와 같은 구조를 쉽게 만들 수 있는 것이 인터페이스이다.