인터페이스(Interface) vs 추상 클래스(Abstract class)

✅ 인터페이스(Interface) 특징

서브 클래스는 인터페이스를 상속받았다는 의미는 이를 '구현'하는 것입니다.

어떤 클래스에게 특정 책임을 부여하고 싶을 때 사용합니다.

 

• 인터페이스는 구현할 메서드의 집합을 선언한 것이다.
• 인터페이스 내부 함수에 명시적으로 abstract을 표시하지 않아도 항상 abstract이다.
• 인터페이스를 상속받은 클래스는 abstract 메서드를 반드시 구현해야 한다.
• 인터페이스끼리 상속이 가능하다.
• 인터페이스 접근자는 Public 만 가능하다.
• 인터페이스 내부 함수의 접근자도 Public만 가능하다.
• 인터페이스는 내부 변수 선언이 불가능하다. (static final 상수만 가능하다)
• 인터페이스는 다중 구현이 가능하다.
• 인터페이스 내부 함수는 abstract 함수만 가능하다.
  (그런데 Java 8부터는 default 키워드를 통해 함수 구현이 가능하다고 한다)
• 인터페이스는 생성자 정의가 불가능하다.
• 인터페이스는 인스턴스화할 수 없다.

 

---

 

✅ 추상 클래스(Abstract class) 특징

서브 클래스가 추상 클래스를 상속받았다는 의미는 부모 클래스의 구현을 재사용함으로써 이를 '확장'하는 것입니다.

따라서 계층적인 관계에서 사용됩니다.

 

• 추상 클래스를 상속받으면 추상 클래스 내부 변수와 메서드를 모두 상속받는 것이다. 만약 abstract 메서드가 있다면 이를 반드시 구현해야 한다.
• 추상 클래스의 접근자는 public, private, protected 모두 가능하다.
• 추상 클래스 내부 함수의 접근자도 public, private, protected 모두 가능하다.
• 추상 클래스 내부에 변수 선언이 가능하다.
• 추상 클래스는 다중 상속이 불가능하다.
• 추상 클래스의 내부 함수는 abstract가 아니어도 된다. 즉, 구현 코드를 포함한 함수 정의가 가능하다.
• 추상 클래스 내부에 생성자 정의가 가능하다.
• 추상 클래스는 인스턴스화할 수 없다.

 

---

 

✅ 인터페이스와 추상 클래스 비교

🏷 공통점

둘의 공통점을 살펴봅시다.

인스턴스화할 수 없고, abstract 메서드를 가지고, 상속이라는 키워드를 사용합니다.

결국 둘 다 추상적인 무언가인 것입니다.

 

🏷 차이점

하지만 가장 큰 차이점은 인터페이스는 상속 키워드로 'implements'를 사용하고, 추상 클래스는 상속 키워드로 'extends'를 사용합니다.

키워드 그대로 추상 클래스의 상속은 '내가 만들어 놓은 것들은 그대로 물려받으면서 나머지는 너에게 맞게 구현해서 확장해!'이고

인터페이스의 상속은 '내가 너에게 필요한 기능이 무엇인지 틀만 만들어놨으니까 너에게 맞게 구현해서 써!"인 느낌입니다.

 

주요 특징에 대해 표로 정리하면 아래와 같습니다.

특징	인터페이스	추상 클래스
상속 의미	구현	확장
메소드 구현 여부	모든 추상 메소드 구현 필요	모든 추상 메소드 구현 필요
메소드 abstract 여부	항상 abstract	abstract가 아니어도 됨
접근자	Public만 가능	Public, Private, Protected 모두 가능
내부 변수 선언	불가능 (static final 상수만 가능)	가능
다중 상속 여부	다중 구현 가능	다중 상속 불가능
내부 함수 구현	abstract 함수만 가능 (default 메소드 제외)	구현 함수 정의 가능
생성자 정의 여부	불가능	가능
인스턴스화 여부	불가능	불가능

 

---

✅ 왜 추상 클래스는 다중 상속이 불가능한가?

추상 클래스A와 추상 클래스 B가 있다고 합시다.

A에서 play()라는 메서드를 구현했습니다. 또한, B에서도 play()라는 메서드를 구현했습니다.

 

클래스 C가 추상 클래스 A와 B를 다중 상속받는다고 했을 때, 이름이 겹치는 play() 메서드는 어느 구현부를 상속받아야 할까요?

이러한 모호함 때문에 메서드 구현이 가능한 추상 클래스는 다중 상속이 불가능합니다.

abstract class A{
	public void play(){
    	System.out.println("A와 놀자");
    }
}

abstract class B{
	public void play(){
    	System.out.println("B와 놀자");
    }
}

class C extends A, B{
}

static public void main() {
	C c = new C();
	c.play(); // 어떤 실행 결과가 나와야 하는가?
}

 

---

 

✅ 디자인 패턴에서의 인터페이스와 추상 클래스

디자인 패턴을 공부하다 보면, 추상적인 부분에 대해 인터페이스를 써야 할지 추상 클래스를 써야 할지 고민이 되는 경우가 많습니다.

다양한 예제들에 대해 디자인 패턴을 적용하면서 개인적으로 느낀 건, 예제마다 다르다는 것입니다..

 

🏷 예제: Composite 패턴

가령, Composite 패턴 구조를 생각해 봅시다.

출처: 위키백과

 

여기서 Component는 Composite와 Leaf를 추상화한 개념입니다.

그리고 흔히들 Component를 인터페이스라고 말하는 것을 찾을 수 있습니다.

 

그럼 코드에 Composite 패턴을 적용하고 싶을 때 Component 역할을 하는 클래스는 당연하게 인터페이스로 선언해야 하는 것일까요?

 

Component 역할의 Node 클래스, Leaf 역할의 File 클래스, Composite 역할의 Directory 클래스가 있다고 해봅시다.

그리고 File과 Directory는 모두 name 속성을 가집니다.

 

🏷 [Component 인터페이스 단점 1: 공통된 속성 선언]

만약, Node를 인터페이스로 정의한다면 File과 Directory 각각에 name 속성을 선언해야 할 것입니다. 사실 이렇게 하더라도 전혀 문제 될 것은 없습니다.

그렇지만 공통된 속성을 굳이 따로 선언할 이유는 없습니다!

 

Node를 추상 클래스로 정의하여 여기에 한 번만 공통된 name 속성을 선언하면 됩니다.

 

🏷 [Component 인터페이스 단점 2: 공통 메서드 수정]

여기에 name을 수정하는 메서드가 추가되었다고 합시다. 그리고 이 메서드의 구현 내용은 Leaf이든 Composite이든 상관없이 동일합니다.

Node가 인터페이스라면, Leaf와 Composite 각각에 동일한 구현 코드의 name 수정 메서드를 추가해야 합니다.

Node가 추상 클래스라면, Node에 선언된 name 속성에 따라 name 수정 메서드도 Node에 한 번만 구현하면 됩니다.

 

🏷 [결론]

결론적으로, 공통된 속성이나 메서드가 있는 경우에는 추상적인 부분을 추상 클래스로 선언하여 중복을 최소화할 수 있습니다.

 

자신이 현재 디자인 패턴을 적용하려는 상황에 맞게 추상적인 부분을 인터페이스로 할지, 추상 클래스로 할지 결정하면 될 것 같습니다.

다만 주의할 점은 다중 상속이 필요한 경우에는 추상 클래스를 사용하면 안 된다는 것이다.