Interface

최완식·2022년 11월 8일

Function Pointer Prototype abstract class deep copy interface multiple inheritance shallow copy

Object Oriented Programming & Design

목록 보기

14/28

인터페이스는 왜 필요할까? 그리고 무엇일까?

Interface의 사전적 의미

inter-(상호간의) + -face(면) = interface
접해있는 두 물체나 공간 사이의 경계
사용자는 스위치를 키는 버튼에 집중
- 이걸 누르면 어떤 일이 일어날지를 앎 (what)
- 어떻게 그런일이 일어나는지는 모름 (how)
실제 동작은 구현 공간에서 일어남
- 배선의 연결
- 사용자는 잘 알지 못하는 공간
- 구현자만 알고 있음
이미 알고 있는 개념 = 함수
- 함수는 블랙박스임: 호출자는 내부가 어떻게 도는지 이해하려 하지 않는다.
- 함수명과 반환형: 어떤 동작을 하는지 알려줌
- 함수 매개변수: 어떤 데이터를 전달해야 함수가 동작하는지 알려줌
- 그래서 함수 signature를 interface라 부르기도 함
  - 컴퓨터 분야에서 인터페이스란 매우 다양한 것을 의미함

함수 선언 vs 함수 구현

함수 선언 == 함수 signature == interface
c와 같은 언어에서는 이해하기 쉬울 것
- 선언과 구현이 분리되어 있으므로
그런데 함수 signature, interface만 존재하는 경우도 있었다.
함수 포인터 매개변수는 signature만 지정

void register error handler (void (*handler) (const char* msg));
void log error(const char* msg);

static void (*s_handler) (const char*) = NULL;

void register error_handler (void (*handler) (const char* msg)) // 여기
{
    s handler = handler;
}

void log error(const char* msg)
{
    if (s_handler != NULL) {
        s_handler (msg) ;
    }
}

void (*handler) (const char* msg) 부분은 함수 signature만 있고 구현이 없다.
OO에서 다형성도 이와 같이 동작한다.
결국 다형성은 구현체에 있는 함수를 호출하는 것이기 때문에, 거의 같은 방식이라 생각할 수 있다.

함수 포인터 매개 변수 vs. 클래스 매개변수

그러면 이러한 의문이 들 수 있다.
"내가 필요한 건 실제로 구현한 메서드 함수만 알면되는데, 다형성을 사용하면서 다른 메서드들까지 딸려오게 되네..?"
"함수 포인터가 더 나은 것 아닌가?"

함수 포인터 매개변수	클래스 매개변수
- 어떤 함수 구현도 signature만 맞다면 다 받아줌	- 부모 클래스를 상속한 클래스면 다 받아줌 - 그 중 다형성 메서드 하나를 호출 - 실질적으로 C의 함수 포인터처럼 작동 - 근데 배보다 배꼽이 더 큰..?

아니 그러면 추상 클래스에서 메서드를 싹다 abstract로 만들면 되지 않을까?
일단 함수포인터와 완전히 같게 하기 위해서는 추상클래스의 메서드를 한개로 제한하고, 그 메서드를 abstract로 만들자.
그러면 상속하는 쪽에서 무조건 구현해야 하니까, 그런 추상클래스 자체를 인자로 넘기는 행위는 곧 함수 포인터와 완전히 같게 된다.
여기서 abstract 메서드의 개수를 늘리는 것은 결국 함수포인터 여러개를 한번에 주는 것과 같으니 사용할만 할 것

OO 개념과 인터페이스

구조체: 데이터만 모아놓았던 것
클래스: 데이터와 동작을 모아놓은 것
순수 추상 클래스: 구현은 빼고 동작만 모아놓은 것 == Interface
Interface
- 어떠한 상태도 없음
- 동작의 구현도 없음
- 동작의 signature만 있음

Interface

public abstract class LoggerBase {
    public abstract void log(String message);
}

public interface ILoggable {
    void log(String message);
}

class -> interface
abstract 지우기
- interface는 자체가 추상적
method는 항상 public
- 함수 포인터와 같은 개념인데 막아둔다는 것은 이상함
- 그런데 요즘 언어에서는 다른 ACL도 들어갈 수 있어짐
- 절대적인 것은 아니고, 이러한 흐름이 있었다 정도로 이해하는 것이 좋을듯
extends를 implements로 바꿈
- :만을 사용하는 경우도 있음
interface 구현하지 않으면 컴파일 오류

Override의 문제

오타났을 때, 동작은 하나 의도대로 동작하지 않을 수 있음
shout를 shuot로 썼는데 이걸 확인못하고 넘어가면 삽질하게 되는 거임
그럼 이런 오타를 방지하기 위해 추상 클래스를 인터페이스로 바꾸어야 하는가?
그건 아니다.
override를 하는 경우 명확하게 이를 수행한다는 keyword를 추가하면 된다.
즉, override하는 경우 override와 같은 키워드를 통해서만 가능하도록 제약을 걸어버린다.
이렇게 되면, 코드 작성자는 override 없이 수행할 수 없으므로 보다 안전한 코딩이 가능해진다.
자바에서는 annotation이라는 것을 사용한다. 이는 언어의 일부로 존재하는 것이 아니다. (@Override)

Java Annotation

프로그램에 대한 metadata를 제공
- 프로그램의 일부가 아니어서 코드 실행에는 아무 영향을 안 미침
용도
- 컴파일러에게 정보를 제공 (@Deprecated, @Override)
- 컴파일, 혹은 배포 중에 어떤 처리를 할 수 있음

Interface의 접근 제어자

추상 메서드는 protected를 붙일 수 있다.
그 때문에 외부에서 호출은 못해도 자식 클래스가 구현하도록 강제할 수 있다.
왜 인터페이스는 안되게 해두었을까?

왜 인터페이스는 public method만 가능할까?

개념상으로 인터페이스는 두면이 맞닿는 면을 말한다.
그렇기에 그 사이에서 필요한 모든 것들을 정의하는 것이 옳다.
여기서 특정 메서드는 연결점으로 사용하지 않겠다는 것이 의미적으로 이상하다.
이게 일반적인 얘기다.
주류 언어에서는 public으로 강제하니 동의하지 않아도 방법은 없다.
C의 헤더파일과 비슷하다고 보면 이해가 쉽다.
- header file을 include한 어느곳에서든 사용할 수 있다.

Interface의 이름

앞에 붙은 I는 무엇인가? (ILoggable)
- Interface의 약자
-able과 같은 형태로 붙일 수도 있음
- 인터페이스는 "무언가를 할 수 있다"의 표현이기 때문에

Interface는 다중 상속의 위험이 없다

다중 상속의 문제는 구현이 각각 존재하기 때문에 어떤 것을 선택할지 모른다에 있다.
- 죽음의 다이아몬드
- A가 이름이 같은 메서드의 B, C를 다중상속한다면 구현이 두개라 어떤걸 선택할지 모른다.
이런 문제에서 인터페이스는 자유롭다.
인터페이스는 구현이 없기 때문에, A에서 구현을 해야하고 이 때 이름이 같다면 하나로 퉁칠 수 있게 된다.

어떻게 상속해도 Interface의 구현은 하나뿐

Interface에서 선언한 메서드의 구현은 Class에서 생김
Class 다중 상속은 불가능
따라서 한 클래스안에서 Interface의 구현은 딱 하나만 존재
그래서 다중 상속의 해결법으로 많이 사용함
- 단, 단순히 그 용도는 아님

깊은 복사 & 얕은 복사

java에서는 clone()을 사용함
- Prototype 패턴
이 방법이 어렵다 생각하여 복사 생성자 방법도 사용함
- public init(other point: Point)
- 자기 자신의 자료형을 받아 자신을 리턴함
- 내부적으로 복사하는 코드를 만들어 사용
- swift의 경우에는 기본 자료형이 struct로 되어있어 이 문제에서 약간더 자유롭긴함