#041_닷넷(.NET)_.Net Framework 기본 - 인터페이스 Intro

안녕하세요 삽잡이입니다.

이번 시간에는 인터페이스에 대해서 알아보려고 합니다.

이~전 시간에 인터페이스에 대해서 알아본 감이 있지만,

다시 한번 정리하는 겸 보다 꼼꼼하게(?) 알아보도록 하지요...

/*

글을 쓰다보니... interface는 못나갔습니다... 혹여나 이 글이 관심 없으신 분들은...

다음 글에서 interface를 다루겠으니... 그 글을 참고하시길 바랍니다...

*/

객체지향의 중심축을 생각해봅시다.

하나의 단위를 만들어내는 묶음의 기능과 보호의 기능(은닉)을 담당하는

'캡슐화'는 알고자하는 것은 알고 감추고자하는 것은 감추기 위한 객체지향의 핵심입니다.

캡슐화는 클라이언트에게 '최소한의 것'만을 알려줄 수 있도록 합니다.

많이 알면 알수록 신경써야할 일들이 많고, 복잡해지는 일도 비일비재하니 

이처럼 캡슐화를 제공해주는 것입니다.

이 캡슐화를 통해서 유연성과 객체지향에 맞는 프로그램을 만들 수 있습니다.

또한, '물려받기'의 핵심적인 개념을 가지고 있는 '상속' 역시 객체지향의 중심 축입니다.

코드 중복을 없앨 수 있으며 재사용을 통해 낭비를 줄일 수 있습니다.

하지만 가장 중요한 상속의 핵심은

바로, '하나의 타입으로 다룰 수 있다'는 것입니다.

이렇게 하나의 타입으로 다룰 수 있는 객체지향의 특성은

마지막 중심축인 '다형성'을 지원하는 기반이 됩니다.

즉, 하나의 타입으로 다룸으로써 다형성을 지원하는 기반이 다져진 것이지요.

하나의 타입으로 다루지 않는다면 다형성은 존재하지 않습니다.

사실, 다형성은 '상속을 사용하는 다형성'과 '상속을 사용하지 않는 다형성'으로 나뉩니다.

물론, 객체지향에서는 '상속을 사용하는 다형성'을 다룹니다.

여담으로 말씀드리자면,

Visual Basic 언어의 경우 다형성을 지원하지만,

'상속을 사용하지 않는' 다형성도 지원을 합니다.

아무튼... 그래서 다형성이 뭐냐?

바로, '하나의 메시지'를 던지는 것입니다.

이는 오직 하나의 메서드만을 호출한다는 뜻이 됩니다.

예로, Shape이라는 객체에 Draw()라는 명령을 하게된다면,

이는 Draw()라는 메서드를 Shape 객체에 보낸다고 할 수 있습니다.

객체지향 용어로 이를 '메시지를 보낸다.'라고 말합니다.

만약, 동일한 종류의 객체끼리 상속관계에 있다면...

즉, Shape, Rect, Ellipse 는 모두 동일한 종류의 객체로써

하나의 타입 객체입니다. 이를 '유사한 객체'라고도 부릅니다.

Shape은 Shape이지만 Rect나 Ellipse나 모두 Shape입니다.

그렇다면 Shape->Draw(); 명령을 날리면... 이는 누구에게 메시지를 날리는 것일까요?

물론 지금 상태에서는 '다형성'에 의해서 누구에게 메시지를 날린 것인지 확답할 수는 없습니다.

아무튼... 이처럼, 하나의 메시지에 대해서 동일한 타입... 

즉, 유사한 객체들이 움직이는 것이 다형적으로 객체들이 반응하는 사실을 입증합니다.

위의 구조를 보게 되면, 각 객체에 맞는 Draw()라는 메서드가 있을 것입니다.

이 메서드들이 다형적으로 반응하기 위해서는 각 객체에 맞는 Draw() 메서드가 호출이 되야합니다.

동일한 타입의 하나의 메시지를 던지게 되면 

실제 객체 즉, 진짜 타입(구체적인 타입)의 메서드가 호출되는 메커니즘을 

다형성이라고 부를 수 있습니다.

음... Shape은 Shape인데, 실제 타입이 Rect라면 

Rect에 해당되는 Draw() 메서드가 호출 된다 이겁니다.

C++부터 배워온 virtual을 포함한 abstract 그리고 이제부터 배울 interface는 

모두 다형적인 메서드들을 만들 수 있고, 다형성을 보장시켜줍니다.

물론, 다형성이나 상속, 캡슐화 이 모두는 뗼레야 뗄 수 없는 관계입니다.

이 셋이 맞물리게 되어 돌아갈 때에

비로소 진정한 객체지향을 추구하게 되는 것이지요.

심지어 하나 하나 따로 두면서 이해하기도 힘듭니다.

그러면 다형성을 왜 쓸까요? 멀리도 돌아왔습니다...

바로 확장성 즉, 기능 추가하기에 용이하기 때문입니다.

구체적인 타입을 가지고 놀 필요 없이, 

두리뭉실한 타입을 가지고 놀지 않았습니까? (Shape->Draw();)

구체적인 타입을 가지고 놀지 않았다는 뜻은 

또 다른 구체적인 타입을 만들더라도 추가할 것이 그리 많지 않게됩니다.

따라서 확장성이 좋아진다는 것이지요... 이것이 바로 핵심!입니다.

이 확장성이란,

여러 객체를 추가해도 모든 코드가 Shape을 대상으로 놀고 있기 때문에

별 수정할 것들이 많이 없다는 것입니다.

다형성은

확장성의 개념을 굉장히 일반화시키고 키우고 있다는 것을 알 수 있습니다.

또한, 하나의 타입인 추상화를 통해 추상적으로 다룰 수 있게 됨을 알 수 있습니다.

즉, 구체적인 타입을 가지고 노는 것이 아니라, 추상적인 타입을 가지고 논다는 소리입니다.

이는 곧 유연성을 의미하게 됩니다.

물론, 설계를 할 때에 복잡하고, 코드의 가독성이 힘들어진다는 단점도 가지고 있지요...

하지만, 단점보다 장점이 더 빛이 나기에 

다형성은 객체 지향의 중심이 되지 않은것인가 싶습니다.

확장성과 유연성이 좋아진다 이겁니다.

인터페이스를 알아보려다가 엄청 돌아서 왔습니다.

다음 시간에 인터페이스에 대해 알아보도록 하지요...

다음시간에 뵙겠습니다!

이상 삽잡이였습니다!