Interfaces - 인터페이스

hyperskill - Interfaces 영어 원문

우리는 매일 일하러 가거나, 대학 혹은 학교를 가기 위해 지하철이나 버스를 탑니다.

점심시간에 우리는 카페나 레스토랑을 들릅니다.

우리는 우리의 하루를 정리하는데 도움을 주는 다른 서비스나,

카페, 레스토랑과 같은 곳에서는 문제가 거의 없습니다.

이러한 협약 및 계약이 존재하는 것은 사람들의 기본적인 니즈를 용이하는데 도움을 주거나,

삶을 좋은 방향으로 예측하게 만들어 줍니다.

이제 우리가 프로그래밍 객체 사이에서 비슷한 협약을 만들어 낼 수 있는지 봅시다.

Basic definitions - 기본 정의

---

스킬은 당신이 작업할 수 있는 것을 정의합니다.

만약 당신이 몇 가지 작업에 능숙하다면, 당신은 계약에 사인하고 가져갈 수 있습니다!

우리는 계약이 사람들이 가지고 있는 합법적인 협약이라고 말할 수 있습니다.

이러한 합법적인 협약에 대한 이름은 프로그래밍에서 interface (인터페이스) 라고 부릅니다.

interface 는 객체의 행동 양식을 묘사한 메서드들의 모음입니다.

인터페이스를 구현하기 위해서, 객체는 인터페이스의 모든 메서드를 구현해야 합니다.

객체의 행동 양식은 고정되어서, 프로그램을 실행하는 동안 변경 할 수 없습니다.

이것이 사람과 객체 간의 차이점입니다.

interface의 구현과 함께, 당신은 인터페이스가 허용하는 작업을 객체가 수행 할 수 있게 만들 수 있습니다.

또한 당신은 어떤 객체가 작업을 수행 할 것인지 선택 할 수 있습니다.

왜냐면 이들은 약간씩 다르기 때문입니다.

One-method interface - 한 개의 메서드만 가진 인터페이스

---

예를 들어,

우리는 확성기와 헤드폰이 MAKE_SOUND 인터페이스 메서드를 구현하고 있다고 말할 수 있습니다.

확성기와 헤드폰 둘 다 소리를 내는 기능이 있기 때문.

우리의 인터페이스들에 대해 알맞는 이름을 골라주는 것은 현명합니다.

이 경우, SOUNDMAKER 이란 이름이 걸맞습니다.

언어마다 이름을 짓는 관습은 다릅니다.

하지만 보통은, 메서드 이름에 동사를 사용하고,

명사나 형용사를 인터페이스 이름에 사용합니다.

만약 당신이 READ 인터페이스 메서드를 구현하고 싶다면,

READER 혹은 READABLE 로 부를 수 있습니다.

동사 transform (변형하다) 로부터,

당신은 TRANSFORMER 혹은 TRANSFORMABLE 라는 이름을 생성 할 수 있습니다.

이러한 간단한 방식은 언제나 작동하지는 않으므로,

가끔은 다른 이름으로 상식에 맞게 만들어야 합니다.

하나의 메서드는 객체에 단지 하나의 스킬만 있다는 것을 지칭합니다.

하지만 많은 상황에서, 이는 인터페이스를 효과적으로 만들기에 충분합니다.

Complex interface - 복잡한 인터페이스

---

음악을 틀기 위해서, 당신은 오디오 파일을 저장하고 관리하는 기기가 필요합니다.

스피커와 헤드폰은 오직 소리만 출력하기 때문입니다.

당신은 랩탑, 스마트폰 혹은 플레이어를 사용 할 수 있습니다 :

이 모든 것들은 인터페이스 AUDIOPLAYER 를 구현했습니다.

이 인터페이스가 가져야 할 메서드들은 무엇이라고 생각하나요?

우리는 음악을 재생하기 위해 필요한 최소한의 메서드를 선택했습니다 :

classDiagram

    AudioPlayer: + PLAY()
    AudioPlayer: + STOP()
    AudioPlayer: + NEXT()
    AudioPlayer: + VOLUME_UP()
    AudioPlayer: + VOLUME_DOWN()

우리의 메서드들은 실제 재생기기의 제어 엘리먼트를 재구성 했다는 것을 참고하세요.

위의 인터페이스를 살펴보며 우리의 코드를 깔끔하게 만듭니다.

우리는 인터페이스를 구현 한 객체가 무엇을 하는지 이해했습니다.

하나의 메서드를 가지거나, 복잡한 인터페이스 간의 특혜적인 차이점은 없습니다.

하지만 만약 당신이 복잡한 인터페이스를 구현한다면, 이런 생각이 들 겁니다 :

이건 얼마나 커질 수 있지?

Responsibility of an interface - 인터페이스의 책임

---

크기에 대한 답변을 하기 위해,

이건 메서드의 숫자에 대한 것이 아니라, 객체가 가지는 책임에 대한 것 입니다.

당신이 하나의 메서드를 가진 인터페이스를 사용 할 때,

당신의 코드에 작업을 수행 할 수 있는 풍부한 객체가 있을 확률이 큽니다.

당신의 인터페이스가 자라남으로서,

당신의 객체는 더 많고 많은 스킬을 가집니다.

우리의 객체가 그렇게나 많은 책임들을 대처 할 수 있을까요?

잠깐만 상상 해 보자면,

한 유형의 기기만 음악을 재생 할 수 있으며,

하나의 방식으로만 음악을 재생하며,

그리고 특별한 장소에서만 음악을 들을 수 있는데,

그 이유는 누군가 음악을 듣는데 어마한 책임을 가진 인터페이스를 제작했기 때문이라고

상상 해 봅시다.

우리의 코드 안에서도 이런 세상을 만들고 싶나요?

우리는 인터페이스가 정말 많은 메서드들을 가지고 있더라도,

간단한 인터페이스들을 통해 객체들이 소통하기를 원합니다.

이러한 모든 메서드들은 올바른 작업을 하는데 중요할 수 밖에 없습니다.

만약 몇 가지 메서드들이 더 이상 필요하지 않다면,

이러한 메서드들을 새로운 인터페이스로 옮기거나, 심지어 완벽하게 제거 할 수도 있습니다.

우예를 들어, 리는 AUDIOPLAYER 에 REWIND 메서드를 추가할 수 있습니다.

하지만 RECORD 메서드는 더 이상 필요하지 않은데, 음악을 재생하는 것과는 연관이 없기 때문입니다.

Conclusion - 결론

---

이번 주제에서는 interface (인터페이스) 에 대해 다뤘습니다.

우리는 인터페이스에 대해 하나 혹은 그 이상의 메서드를 정의 할 수 있지만,

이러한 모든 메서드들은 상식에 맞아야 합니다.

하나의 장소에 모든 메서드들을 모아 둘 필요는 없습니다 :

실제적으로 여러 개의 인터페이스로 대체하는 것이 더 낫습니다.

words to remember

---

daytime : 낮, 주간, 하루

agreements : 협약, 계약, 일치, 약정

stiff : 뻣뻣한, 딱딱한, 거센, 빡빡한, 터무니없이

sensible : 현명한, 분별 있는, 느낄 수 있는

practices : 관행, 연습, 업무, 실시, 행하다, 꾸미다, 속이다

vary : 달라지다, 다르다, 바꾸다, 변주 하다

preferential : 우대, 우선의, 선택적인, 특혜의