Interface는 많이 들어보셨을 겁니다. 왜 쓰는 것일까요? 에 대한 질문에 대한 답은 어느 정도 하실 거라고 생각합니다. 그렇지만, 이게 쉽게 잘 와 닿는 개념은 아닐 거라 생각합니다. ps에서 많이 발생할 만한 상황을 예로 들어보겠습니다.

 


 Java에서 Comparable은 interface로 선언이 되어 있습니다.

 

 

 그리고 이 인터페이스 안에는 Target과 매개변수를 비교하는 compareTo가 정의되어 있습니다.

 

 

 이것은 실체는 없는 메소드로 정의가 되었습니다.

 

 

'비교 가능한 기능을' 구현한 Obj입니다. 그런데, 잘 보면, 그냥 Obj는 생성자만 있을 뿐, 그 어디에도, 눈을 씻고 찾아봐도 비교를 하는 메서드가 없음을 알 수 있어요. 비교 가능 함수를 구현해 보겠습니다.

 

 

 compare 가능한 함수인 isItflow 함수를 구현하였습니다. 이것은 무조건 0을 리턴하는 이상한 비교 함수입니다. 어찌 되었던 비교를 하는 메서드입니다. 그런데 오류라고 합니다. 이렇게 지으면 안 되나요?

 

 

 binarySort 함수를 보겠습니다. 그러면, pivot 값을 배열의 a[start]로 잡는다는 것을 알 수 있습니다. 쭉 내려보겠습니다.

 

 

 262번째 줄에 pivot.compareTo(a[mid])가 있습니다. a[mid]과 pivot을 비교하는 것입니다. 2개의 Key값을 비교하기 위한 함수가 compareTo입니다. 여기서, 정리를 해 보면, Collections.sort는 비교 기반 정렬입니다. 그렇기 때문에 두 개의 Key 값을 비교해서 선행 관계를 판단해야 할 건데요. 그것을 위한 메서드가 compareTo입니다. Collections 클래스에서, 눈을 씻고 찾아봐도 isItflow는 없음을 알 수 있어요.

 

 

 그런데, 어떠한 클래스의 비교 함수가 isItflow라고 하면 어떨까요? 그 클래스 하나를 위해서, 265번째 줄을 compareTo 대신에, 제가 마음대로 정의한 pivot.isItflow로 바꿔야 할까요?

 

 

 아니면, 여기서 compareTo를 ctrl+R키룰 눌러서 모두 isItflow로 바꿔야 할까요? 아니면 Collections 클래스를 모두 복사하고, 비교 메서드인 compareTo만 isItflow로 모두 바꿔버린 다음ps_Collections 클래스를 따로 생성해야 할까요?

 

 

 Collections.sort는 내부적으로 key 값을 비교하기 위해, compareTo를 씁니다. 그런데 isItflow를 쓴다니요. 어긋나고 있어요. 더 쉽게 비유하면, 어떤 기기가 usb 포트를 지원한다고 되어 있어요. 그런데, 꼽을 수 있는 잭이 삼각형 모양의 잭밖에 없으면 어떨까요?

 

 


 분명한 것은, 어떠한 클래스에서, 이러한 기능을 구현할 때에는 이런 이름을 쓰고, 어떤 매개변수를 받고, 어떤 값을 리턴해야 하는지까지 '강제' 해야 하는 경우가 있다는 것입니다. 예를 들어서, Object 하나를 받고, boolean을 리턴하는 compareTo를 Collections의 내부에서도, sort의 내부에서도 많이 쓴다고 한다면, 이것을 포기할 이유는 없습니다. 그것을 포기했다면, 그러한 역할을 하는 함수를 이미 구현된 Collections 클래스 안에다가, 혹은 sort를 하는 메소드 안에다가 넣어야 합니다.

 

 

문제의 unimplemented 함수를 Obj 안에 넣으면 어떤가요? 이미 sort 안에 비교 함수를 호출하는 로직을 바꾸지 않고서도, Obj가 들어있는 자료구조를 정렬하거나, TreeMap 같은 곳에 넣을 수 있게 됩니다. 그러면, Collections.sort는 Integer나, String을 정렬할 수 있을까요?

 

 

 String은 Comparable<String>를 구현하고 있습니다. 이 말인 즉슨, 자기 자신과 Target의 순위를 비교하는 compareTo 또한 있다는 의미입니다.

 

 

 Integer는 Comparable<Integer>를 구현하고 있습니다. 역시, 자기 자신과 Target의 rank를 비교하는 method가 있습니다. 이렇게 구현해 놓으면 어떻게 유용하게 쓰일 수 있을까요?

 

 

  sort 내에 compareTo가 있다고 해 봅시다. Key 값들이 모두 String인 상황이라면, String을 비교하는 메서드가 호출이 될 겁니다.

 

 

 Integer라면, Integer를 비교하는 것이 호출이 될 거고요. 단지, Interface는 매개자 역할을 했을 뿐입니다. 규격만 잘 맞춰 놓는다면, 내가 정의한 오브젝트도 '비교'를 하고, '정렬' 하고, 심지어 실시간으로 정렬이 되어 있으면서 삽입과 삭제가 가능하게끔 할 수도 있습니다. 이것이 인터페이스의 힘 중 하나입니다.