본문 바로가기

ETC Programmings

[C#] 인터페이스를 사용하는 이유가 뭘까?

336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
 인터페이스는 내가 배운 개념중에서 가장 이해가 안가고 왜 있어야되는지를 아직도 잘 모르겠는 것 중에 하나다. 사실 인터페이스에 대한 내용을 싣기에는 부족한 내공이지만 배우고 안 만큼만 블로그를 통해서 적어보려고 한다.

 인터페이스라는 녀석은 아주 간단한 형태를 띠고 있다. class 라는 선언문 대신에 interface 라고 선언을 하고.. 그 안에는 접근제어자(Access Modifier : public protected private) 가 없는 메소드만이 존재할 수 있게 된다.

<Interface 님의 심플한 자태>
  1. interface INoodle   
  2.   {   
  3.       void cookPasta();   
  4.       void cookRamen();   
  5.   }  
 아주 심플한 모습인데.. 왜 이런 뼈다귀 같은 구조를 짜놓으며 왜 이런 구조의 인터페이스가 필요한 걸까? 메소드를 선언하는 것 자체가 흡사 추상 클래스의 추상 메소드와 비슷하게 생겼는데.. 이렇게 되면 추상메소드 처럼 인스턴스를 직접 생성하지 못하지만 더 재미있는 것은 이를 상속(구현이지만)받게 되면 결국은 저 인터페이스에 맞게 메소드 이름을 짜줄것 같으면 그냥 클래스로 선언하는게 더 나을것 같다. 딱히 재사용 되는 자원들도 하나도 없으니깐 말이다.

그러면 왜 이런 인터페이스를 사용하는 것일까?

좀 이해가 안가는 내용이지만 인터페이스가 나오게 된 이유로 거슬러 올라가 보면 그 가운데는 '다중 상속' 이라는 것이 있다. 상속이라는 관계는 본디 일대다 로만 이루어 진다. 다시 말해 어떤 한개의 클래스를 상속받은 클래스는 다수가 존재할 수 있지만 상속을 받은 클래스의 부모 클래스가 여러개 일수는 없다. 정말 안좋은 결과를 초래하는 죽음의 다이아몬드가 그려질 수 있다는 것이다.


저런 다중 상속에서 생기는 문제는 위에 다이어그램에서 처럼 메소드 이름이 같다면 과연 어떤 것에서 호출해야 할지를 모른다는 것이다. 이처럼 다중 상속에서 생기는 문제점을 막으면서 여러 타입의 클래스의 형태를 띨 수 있는 방법은 무엇일까 해서 나온게 인터페이스이다. 인터페이스는 상속과는 다르게 여러가지 인터페이스를 구현(Implementation) 할 수 있다. 때문에 아래와 같은 선언이 가능해진다는 것이다.

  1. class SeoulRestaurant : INoodle, ISoup   
  2.     {   
  3.         public void cookPasta()   
  4.         {   
  5.         }   
  6.   
  7.         public void cookRamen()   
  8.         {   
  9.         }   
  10.   
  11.         public void cookBrocolliSoup()   
  12.         {   
  13.         }   
  14.   
  15.         public void cookChickenSoup()   
  16.         {   
  17.         }   
  18.     }  
두가지의 인터페이스에 정의되어있는 모든 메소드들을 사용할 수 있도록 클래스를 만들어야 한다. 이로서 SeoulRestaurant 라는 클래스는 두가지 인터페이스를 구현하므로서 INoodle 의 인스턴스이기도 하고 ISoup 의 인스턴스이기도 한 객체가 된다. 그렇다면 인터페이스는 문법을 어기지 않고 컴파일러에 혼란을 주지 않으며 다중 상속을 우회적으로 사용하는 그런 용도로 사용이 되는 것일까?

그 말도 맞지만 추상클래스를 사용하는 이유에서 처럼 인터페이스의 추상화된 메소드를 제공한다. 이 때문에 파생될 클래스들에 메소드 오버라이드를 통하여 문법을 지키도록 유도하고 다중상속이 가지는 강력함을 더하면서 동시에 발생할 수 있는 문제점들도 해결하게 되었다. 또한 디자인 패턴의 많은 예제 코드들이 이 인터페이스를 설계하는 것으로 부터 많이 시작한다. 단순히 뼈대를 제공하는 것 뿐만아니라 더 큰 의미에서 최소한의 수정을 통해서 변화에 대응 할 수 있도록 하기 위한 유연한 프로그래밍의 설계의 근간이 된다.

인터페이스에 대한 설명은 사실 말보다는 실제 소스를 이용하여 설명하는 것이 맞다... 때문에 디자인 패턴에 대한 추가적인 학습이나 패턴 지향 리팩토링을 통해서 더 공부할 필요가 있다.