인터페이스에 대한 단상.

다양하게 해석되는 인터페이스

 객체지향 프로그래밍에서 가장 핵심을 이루는 것은 클래스이다. 그리고그 옆에 인터페이스가 있다. 이 인터페이스라는 것에 대해서 다양한 해석이 존재한다. 처음에는 계약, 약속의 관점에서 이해를 하고 또 공부를 하였다. 어느 날은 다중상속이 불가능한 상황에서 인터페이스가 그 대안이라고 한다. 함수포인트가 없는 자바에서는 인터페이스가 그 대안이라고 말하기도 한다. 어디서인가는 추상화에 대해서 이야기를 한다. 추상화를 떠올리면 추상클래스도 있는데 이 추상클래스와 인터페이스를 비교하기도 한다. 인터페이스는 정말 다양하게 설명되고 다양하게 이해되고 있다.

 하지만 마지막에 귀결되는 점은 인터페이스는 결국 클래스로 구현이 되어야 된다는 것이다. 추상클래스와 다른 점이라면 상속이라는 행위 없이 구현되다는 표현으로 실제 코드로 구현이 된다. 때로는 이부분을 상속으로 대체를 할수도 있겠지만 상속은 상당히 비용이 많이 드는 구조이다. 상속이 어떤 반복적인 문제를 상위클래스에서 위임으로 해줌으로서 해결이 되는 부분도 있지만 대신에 상속은 그 속성이 하위클래스로 전파가 되기 때문에 계획 없는 상속은 나중에 상위 클래스를 바꿔야 되는 상황에 왔을 때 엄청난 리스크를 부담해야되는 방식이다.

 더불어 상속은 다중상속이 불가능하기 때문에 다른 인터페이스 여러가지를 구현할 수없는 상황에 마주치게 되기도 한다. 인터페이스를 대신하여 상속을 쓰는 것은 위험한 행위인데 굳이 그렇게 얻어지는 이점은 IDE에서 소스가 추적이 가능하다 정도 일 것이다.

 대부분의 IDE에서 인터페이스 메서드를 추적하면 실제 인터페이스를 구현한 클래스의 메서드 진입을 찾아주지 않고 인터페이스 자체에 찾아가서 커서를 깜빡인다. 이부분이 불편하여 인터페이스가 안 좋다고 생각하게 되면 인터페이스가 주는 이점을 많이 버려야 하는 낭비가 발생한다.

 인터페이스는 실제 선언한 사람과 구현하는 사람이 다를 수도 있다. 아니 사람은 같을 수 있으나 구현이 시점이 상이하게 다를 가능성이 높다. 인터페이스를 선언한 사람이 선언된 인터페이스를 자신이 만든 어떤 구체 클래스에서 사용을 하게 될 것이다. 그리고 나중에 그 인터페이스를 구현하는 상황은 뒤에 일어나게 된다. 즉 두개의 구현시점이 상이하게 다를 수도 있다는 것이다. 하지만 먼저 선언한 입장에서는 구체적인 구현이 작성되지 않았지만 자신이 만든 코드에서 에러 없이 잘 작동을 한다.

 즉, 구현을 미루는 것이다. 구현을 미루는 대신 인터페이스라는 방식을 통하여 약속을 하는 것이다. 이런 파라메터를 이용해서 호출을 하겠다고 말이다.

 이렇게 구현을 미룸으로서 가지는 이점으로는 라이브러리소스일 경우 모듈단위를 넘어지만 프로그램의 작동에 아무 문제 없이 라이브러리 소스가 컴파일되고 작동이 된다. TEST를 작성할떄는 더미클래스 등을 만들어 테스트시에 작동하는 코드로서 실제 구체클래스가 대체되어 테스트도 될 수 있다.

 

내가 생각 하는 인터페이스

 객체지향의 핵심은 관심사의 분리라고 생각한다. 관련있는 데이터와 메서드가 클래스라는 덩어리로 묶이고 그 인스턴스가 다른 클래스에서 사용되면 관계를 맺고 역활을 해나가는 것이 핵심이다. 규모가 커질수록 복잡해지는 코드를 간략하게 하나의 일만을 집중할 수 있도록 묶고 나누어 모듈화를 하는 것이다.

 관심사의 분리에서 인터페이스는 약간의 마술을 더 해주는데, 책임을 미루는 것이다. 구현을 미루는 것이다. 실제 어떤 구현이 일어날지는 모르지만 그 진입점만을 만들어 두고 실제 구현을 해야되는 다른 개발자나 다른 시스템에서 실제 구현을 하는 것이다.