본문 바로가기
연구하기/Computer Engineering

MS 의 C# 코딩이 익숙해지면서 - 2

by 썰렁황제 2005. 3. 7.

  C# 의 인터페이스는 자바와 상당히 다른 점이 많다. 정적 필드값이 들어갈 수도 없고, 접근 한정자도 지정하는 것이 불가능하다. 때문에 처음에는 이모저모 불편이 느껴졌다.


  사실 자바의 인터페이스같은 경우, 정적 필드값을 일종의 통신을 위한 메시지 개념으로 만들어 두었으며, 이것은 고전적인 모듈간의 통신 형태가 가지고 있는 편의성과 퍼포먼스 향상을 남겨둔 것으로 보인다. 그리고 이런 자바의 인터페이스는 개체가 이러한 형식으로 통신이 가능하다는 형태를 보여주는 것 보다는 그 자체가 일종의 메시지 개체로 사용될 수 있는 형식에 가깝다. 즉 메시지와 구조체를 활용한 고전적인 통신방식을 OOP 의 개념으로 변형시켰다고 할까...


  C# 의 인터페이스는 아주 철저하게 개체의 형태를 나타내는 형식으로만 제약되어 있다. 인터페이스를 통한 통신은 오직 메소드 형식을 통해서만 가능하며, 상수필드가 존재하지 않기 때문에 상수값을 통한 메시지 전송 및 처리를 인터페이스 단에서 형식화할 수 없다. 모든 형식은 메소드 형으로만 존재해야만 한다.

  하지만 C# 은 자바의 인터페이스 개념과는 상당히 다른 개념으로 인터페이스를 인식할 수 있는 도구를 준비해두었다. 인터페이스를 구현하는 개체의 메소드 선언 시, 메소드 선언을 해당 인터페이스의 이름 안으로 구속시키면 ( 인터페이스명.메소드명(인자) 형식 ) 자바와는 달리 이 메소드는 오직 해당 인터페이스로 캐스팅 되었을 떄에만 외부에서 접근 가능한 메소드가 된다. 이는 형식상으로 굉장히 중요한데, 자바의 개념으로는 만약 특정 개체를 알고 있다면, 그 개체가 가진 인터페이스가 아닌 해당 개체로도 직접 통신을 할 수 있지만, C# 에서는 저렇게 선언할 경우 해당 개체가 어떤 것인지 알고 있더라도 오직 통신은 해당 인터페이스로만 가능하게 되기 때문이다. 즉 자바에서는 인터페이스가 단지 개체의 통신수단을 정의하는 형식이었지만, 이제는 인터페이스 자체가 이 개체의 형태를 나타내 주는 존재로서 의미를 가지게 된다는 것이다. 이는 해당 개체에 대한 접근 안정성을 증대시키며, 자바의 형식에서 인터페이스를 구현하게 됨으로써 비정상적으로 메소드가 노출되어야만 하는 문제점을 (물론 이를 해결하기 위한 방법으로 Nested Class 를 통한 Composite 를 사용하면 되지만 OOP 상으로 좋은 개념이라 보기는 어렵다) 해결할 수 있다. 또한 자바에서는 해당초 불가능했던, 두 인터페이스가 동일한 형식의 메소드를 가지고 있을 경우 두 형식을 나누어 구현할 수 없었던 문제를 C# 에서는 저렇게 인터페이스명을 통하여 메소드를 선언함으로써 피할 수 있다. (자바의 경우는 두 인터페이스가 접근하는 동일한 형식의 메소드를 나누어 만들어 줄 방법이 없다. 물론 이 역시 Nested 클래스와 Composite 패턴을 혼용하면 어느 정도 해결되지만 접근성이 매우 떨어진다.)

반응형