Java 8. Interface

 

인터페이스는 구현코드나 멤버변수를 가지지 않기 때문에 여러 개를 동시에 구현할 수 있습니다. 두 인터페이스에 이름이 같은 메소드가 선언되었다고 해도 구현은 클래스에서 이루어지므로, 어떤 메소드를 호출해야하는지 모호하지 않다. 

 

두 인터페이스를 구현한 Customer클래스는 Buy형 이기도하고, Sell형이기도 하다. 

인터페이스 형변환

“Buy형이자 Sell형이다” = Customer는 두 역할을 다 가진다

Customer 객체는 이런 느낌이야:

• **한 사람(객체)**이
• “구매자 역할(Buy)”도 할 수 있고
• “판매자 역할(Sell)”도 할 수 있음

그래서 아래가 가능해:

왜 Buy buyer = customer; 하면 buy만 호출 가능해?

여기가 화면의 핵심 문장이야:

“customer를 Buy 인터페이스 형 변수에 대입하면
형변환이 일어나 Buy 인터페이스에 선언한 메소드만 호출할 수 있습니다.”

즉, 객체는 그대로 Customer인데,
변수 타입을 Buy로 잡는 순간 “Buy 관점으로만” 보게 돼서,

✅ 중요한 포인트:

• “실행되는 메소드”는 실제 객체(Customer)가 가진 구현이 실행돼. (동적 바인딩)
• 하지만 “코드에서 호출 가능한 메소드 목록”은 **참조 변수 타입(Buy/Sell)**이 결정해.

 

 

[Java] 인터페이스(Interface) — 규약/다형성/default·static/다중구현 + 실습(Scheduler, Sort)

오늘 범위 핵심은 한 문장으로 끝나요.
“인터페이스는 ‘할 수 있는 기능(메소드)’의 규약이고, 구현 클래스가 바뀌어도 같은 타입으로 통일해서(다형성) 코드를 유연하게 만든다.”

---

목차

1. 인터페이스란?
2. implements로 구현하기 (MemberService 예시)
3. 인터페이스 타입으로 쓰는 이유 = 다형성
4. 인터페이스 멤버 특징(변수/메소드)
5. Calc 예제로 보는 구조(인터페이스 + 추상클래스 + 구현클래스)
6. 디폴트 메소드(default)
7. 정적 메소드(static)
8. 인터페이스 다중 구현 + 형변환(업캐스팅) 제한 (Buy/Sell 예시)
9. 인터페이스 상속 = 형 상속(type inheritance)
10. 실습 1) 고객센터 상담 배분 정책 (Scheduler)
11. 실습 1-추가 과제) AgentGetCall 정책 추가
12. 실습 2) Sort 인터페이스로 정렬 알고리즘 선택 프로그램 (너 코드 해설 포함)
13. 마무리 요약

---

1) 인터페이스란?

• 인터페이스는 **클래스의 규약(약속)**이에요.
• “이 기능들은 반드시 제공해야 한다”를 메소드로 제한해서,
  구현 클래스가 다양해져도 같은 방식으로 사용할 수 있게 해줍니다.

---

2) implements로 구현하기 (MemberService 예시)

(1) 인터페이스 선언

인터페이스는 메소드 “틀”을 만들고:

 

 

(2) 구현 클래스에서 implements

구현 클래스는 인터페이스에 선언된 메소드를 반드시 구현해야 합니다.

---

3) 인터페이스 타입으로 쓰는 이유 = 다형성(Polymorphism)

구현이 끝난 뒤에는 보통 이렇게 씁니다:

 

그리고 MemberServiceImpl2, MemberServiceImpl3처럼 같은 인터페이스를 구현한 클래스가 더 생겨도:

 

✅ 핵심 장점

• 코드가 **MemberService(규약)**만 바라보니까
• 구현체가 바뀌어도(Impl 교체) 호출 코드는 거의 안 바뀜
• 이게 “여러 클래스를 하나의 타입으로 처리”하는 다형성이에요.

---

4) 인터페이스 멤버 특징(변수/메소드)

(1) 인터페이스의 변수 = 자동으로 상수

인터페이스에 선언한 변수는 컴파일 과정에서 값이 변하지 않는 상수로 취급됩니다.
즉, 성격이 public static final에 가까워요.

(2) 인터페이스의 메소드 = 자동으로 추상 메소드

인터페이스에 선언한 메소드는 기본적으로 구현 코드가 없는 추상 메소드입니다.
public abstract를 안 써도 그렇게 처리됩니다.

---

5) Calc 예제로 보는 구조(인터페이스 + 추상클래스 + 구현클래스)

이 파트가 “인터페이스 설계” 감각을 잡기에 좋아요.

(1) Calc 인터페이스: 규약(상수 + 추상메소드)

 

(2) Calculator 추상 클래스: 일부만 구현하고 남겨두기

 

✅ 포인트

• Calculator는 추상 클래스라서 new 불가능
• Calc도 추상 메소드만 있으면 직접 new 불가능
• “완성된 구현 클래스”만 new 가능

(3) CompleteCalc 구현 클래스: 최종 완성(인스턴스 생성 가능)

 

 

---

6) 디폴트 메소드(default)

(1) 디폴트 메소드란?

• 인터페이스인데도 구현 코드가 들어있는 메소드
• 인터페이스를 구현한 클래스가 생기면 그 클래스의 기본 기능처럼 사용할 수 있어요.

예시(인터페이스 안에 기본 동작 제공):

 

public interface Calc { // ... (상수/추상메소드) default void description() { System.out.println("정수 계산기를 구현합니다"); } }

(2) 왜 필요해?

• 인터페이스를 구현한 클래스가 이미 많을 때,
• 새 기능을 추가하고 싶지만 구현 클래스들을 전부 수정하기 싫으면
  → default로 기본 구현을 제공할 수 있어요.

---

7) 정적 메소드(static) — 인터페이스 유틸 기능

인터페이스에도 static 메소드를 추가할 수 있어요.
이건 보통 “도움 함수(유틸)”로 씁니다.

예: 배열 합 구하는 total() 같은 것.

public interface Calc { static int total(int[] arr) { int sum = 0; for (int x : arr) sum += x; return sum; } }

호출은 인터페이스 이름으로 직접:

 

int[] arr = {1,2,3,4,5}; System.out.println(Calc.total(arr));

---

8) 인터페이스 다중 구현 + 형변환(업캐스팅) 제한 (Buy/Sell 예시)

(1) 왜 인터페이스는 여러 개 구현 가능?

• “클래스 다중 상속”은 메소드 호출이 모호해질 수 있어서 제한이 많지만,
• 인터페이스는 보통 구현 코드/멤버변수가 없어서
  여러 개를 동시에 구현해도 충돌이 덜합니다.

(2) Buy, Sell을 동시에 구현한 Customer

 

public interface Buy { void buy(); } public interface Sell { void sell(); } public class Customer implements Buy, Sell { public void buy() { System.out.println("구매하기"); } public void sell() { System.out.println("판매하기"); } }

(3) “Customer는 Buy형이자 Sell형”

이게 진짜 핵심이에요:

Customer customer = new Customer(); Buy buyer = customer; // Buy 관점으로 봄(업캐스팅) buyer.buy(); // OK // buyer.sell(); // 컴파일 에러 (Buy 타입에는 sell이 없음) Sell seller = customer; // Sell 관점으로 봄(업캐스팅) seller.sell(); // OK // seller.buy(); // 컴파일 에러

✅ 정리

• 객체는 그대로 Customer인데
• 참조 변수 타입이 Buy냐 Sell이냐에 따라 “호출 가능한 메소드 목록”이 달라짐
• 이게 인터페이스 기반 설계의 “안전한 제한”이에요.

---

9) 인터페이스 상속 = 형 상속(type inheritance)

• 인터페이스끼리도 상속(extends)이 가능해요.
• 다만 클래스 상속처럼 “구현 코드를 물려받는 상속”이 아니라
  타입(규약)을 물려받는 상속이라서 **형 상속(type inheritance)**라고 부릅니다.
• 클래스는 상속을 1개만 가능하지만, 인터페이스는 여러 개 동시 상속도 가능해요.

---

10) 실습 1) 고객센터 상담 배분 정책 (Scheduler)

상황

• 고객센터로 전화가 오면 대기열에 저장되고,
• 상담원에게 배분하는 “정책”이 여러 가지일 수 있다.

정책 예시 3가지:

1. 순서대로 배분(모든 상담원이 동일하게 처리)
2. 가장 짧은 대기열/쉬는 상담원에게 배분
3. 고객 등급(우선순위) 기반 배분

Scheduler 인터페이스

 

public interface Scheduler { void getNextCall(); void sendCallToAgent(); }

구현체 예시 (RoundRobin / LeastJob / PriorityAllocation)

각 클래스는 정책에 맞게 메시지를 출력하도록 구현합니다.

테스트(SchedulerTest)

실행 시 입력:

• R → RoundRobin
• L → LeastJob
• P → PriorityAllocation
  선택된 구현체로 아래 두 메소드 호출:

 

scheduler.getNextCall(); scheduler.sendCallToAgent();

✅ 여기서 인터페이스의 맛

• Scheduler scheduler 하나로 통일해두고
• 입력에 따라 구현체만 갈아끼우는 구조 → 정책 추가/변경이 쉬움

---

11) 실습 1-추가 과제) AgentGetCall 정책 추가

책에서 추가로 요구하는 과제는 이거예요:

• “전화를 할당하는 방식”이 아니라
  상담원이 필요할 때 스스로 가져오는 방식을 추가한다.

요구 출력:

• getNextCall() 호출 → “상담원이 다음 전화 요청”
• sendCallToAgent() 호출 → “상담원이 전화 상담을 가져갔습니다”
• SchedulerTest에서 A 또는 a 입력하면 선택되도록

즉, AgentGetCall도 Scheduler를 구현하도록 만들면 됩니다.

---

12) 실습 2) Sort 인터페이스로 정렬 알고리즘 선택 프로그램 (너 코드 해설)

책 요구사항 정리:

• Sort 인터페이스에는
  • ascending(int[] arr) (오름차순)
  • descending(int[] arr) (내림차순)
• 알고리즘 설명은 description() 디폴트 메소드로 제공
• 구현 클래스 3개: QuickSort, HeapSort, BubbleSort
• 실제 정렬은 하지 않고 설명만 출력해도 됨
• 사용자 입력:
  • H → HeapSort
  • Q → QuickSort
  • B → BubbleSort

---

13) 네 코드가 왜 “인터페이스 교과서 구조”인지

네가 올린 코드 핵심은 딱 이 구조예요:

 

1. 인터페이스 타입으로 통일

 

2. 입력에 따라 구현체 선택

 

3. 그 이후는 구현체가 뭐든 동일 호출

 

✅ 이게 바로 다형성의 핵심

• “무슨 정렬이냐”는 바깥에서 선택하고
• “정렬 수행”은 Sort 규약대로만 호출한다
  → 구현체가 바뀌어도 호출부는 그대로