스팅의 불(火)로그

Interface 좀만 더 생각해보자.

개인적인 사견에 조금 과장을 곁들인다면 Interface가 OOP언어에서 가장 핵심적인 내용이 아닐까한다.

Interface의 이해정도에 따라 초급/중급 개발자로 나누어도 될듯하다.

특히나 J2EE쪽에서는 Interface를 알고있던 모르던 간에 필수적으로 사용되고 있다.

(당연히 알고 있을거라 생각합니다. 아 왠지 무시하는듯한 말투..그런 뜻 아닌거 아시죠..^^?)

J2EE기술중에 Interface를 쓰지않고 돌아가는것이 있을까?(본인의 얕은 지식으로는 없다고 생각합니다.)

/*

아이러니 하게도 필자는 C++ 프로젝트만 하고있는데도 설명은 자바로 하고 있네요..

뭔가 잘못된듯..솔직히 자바 잘 모릅니다..-.-;

Interface의 설명하는데 있어 역시 자바만한게 없다는 생각입니다.

Interface에 대해 논하기 가장 쉽습니다.(극히 개인적인 생각)

C++ 던 Java던 OOP언어에서 Interface의 이론은 대동소이합니다. 언어적으로 표현만 좀 다를뿐

*/

여기서 생각해 볼 것은 왜 껍데기 뿐인 Interface를 강조하는가!

필자가 공부할때(학교다닐때..아!! 벌써 약 10년전...-_-;), 당시엔 Java에서 Interface를 그리 중요하게 생각지 않았다.

물론 이러한 생각은 필자가 Interface를 제대로 이해하지 못했기 때문이었다.

"이런 껍데기를 왜 쓰는거지."

"왜 이런걸 써서 코드만 난잡하게..하는 거지.."

그러한 생각들로 인해..그리 중요하게 생각지 않고 넘어갔다.

그때는 단지 "음 언어적인 제약(반드시 구현해라)을 주기위해 그런것인 갑다"하고 넘어가곤했다.

(여러분은 어떤가요...? 저는 그랬습니다..^^)

Interface가 나온것은 여러 이유가 있겠지만...

여기서는 한가지 단면만을 토로하고자한다.

과거 C/S 기반에서는 클라이언트가 지금의 서버의 모든 기능을 가지고 있었다.

서버쪽은 단지 DB(주로...파워빌더가 그랬죠..? 아직도 많이 씁니다. 주로 사내용으로 사원관리, 급여관리 등등).

클라이언트가 직접 DB를 접속하였다.

이에 대한 문제점이 적지 않았는데..

일단 클라이언트가 모든 기능을 가지고 있는데서 문제가 있다라고 볼 수 있다.

1. DB의 접속 계정을 가지고 있다.

  => 보안에 취약.(이거 머 맘만 먹으면..-.-)

2. 모든 비지니스 로직을 가지고 있다.

  => 클라이언트의 비대화

  => 업데이트 비용이 많이 든다.

  => 비지니스 로직이 포함되어 있으므로 정책 변경에 유연하지 않다.

특히나 보안이나 정책 변경은 머리가 쥐가날 정도로 머리를 아프게 했다.

/*

정책 변경으로 인해 배포된 모든 클라이언트를 업데이트 해주자면..만만한 작업이 아니었습니다..

게다가 업데이트된 클라이언트, 아직 업데이트되지 않는 클라이언트를 모두 수용하자면..

생각만해도...머리가 지끈...

게다가 C/S가 유행하던 당시는 지금의 랜 환경과는 다르죠!!

*/

이러한 이유들로 인해

후에 나온 개념이 3-tier(지금은 환경이 다양해서 n-tier라는 말도 나오는데)라는것인데..

이 개념과 더불어 Thin Client라는 용어가 한때 유행하였다.

지금은 3-tier가 너무 당연스러운 것이라서 Thin Client용어는 근자에는 잘 쓰이지 않는 용어가 되어버린듯 하다.

하지만 Thin Client는 늘 강조해도 지나치지 않는 용어라 생각한다.

물론 프로젝트 성격에 따라 다르긴하겠지만(오해없으시길)..

3-tier의 목적은

서버쪽 정책(비지니스 로직)이 변경된다하여도 클라이언트는 정책에 영향(업데이트없이)받지않고 종전과 동일하게 사용가능하다.

서버쪽 변경으로 인한 클라이언트 변경(업데이트)이 없는 이유는 다름 아닌 Interface만 가지고 있고 구현은 서버단이 책임지고 있기때문이다.

예를 들어

웹서버에서 웹 어플리케이션의 내용(비지니스 로직)이 변경되었다고 웹브라우저를 업데이트하지 않는것과 같은 것이다.

현재에는 어플리케이션의 설계 패러다임이 바뀌었다.

어플리케이션 웹화 되면서 자연스레 저러한 패러다임이 있는지 조차 느낄 수 없을 정도로 당연한듯 설계되지만...

(웹프로젝트는 기본적으로 3-tier입니다. 일반 응용프로그램은 얘기가 다릅니다. 고려되어야겠지요..)

어찌되었던 저러한 C/S 방법론 각광받던 시기가 있었고, 그리 오래전 얘기는 아니다.

이렇듯 Interface의 개념(3-tier의 개념) 필요하게되는 시점에 오기에 이르렀는데..

클라이언트는 Interface만, 서버(혹은 미들웨어라고도 부르는)는 비지니스 로직을..(*중요 별표)

담당(?)하게 된 것이다.

/*

네트웍 환경을 예로 들었지만..작게는 로컬 환경에서도 마찬가지입니다.

윈도우 어플리케이션 제작시.

UI에서 모든 기능을 구현해 놓으면 나중에 버그 잡으려고 할때..

UI 코드와 비지니스 로직과 겹쳐서 무진 애먹습니다.

처음엔 누구나 격는 진통이라 생각합니다..^^

다른쪽 코드 수정으로 인해 이쪽 코드가 영향받지 않도록...하라...

"느슨한 결합" 많이 들어 보셨죠..^^?

*/

RMI(Romote Method Invocation, 원격 메소드 호출)에서는

클라이언트에게 Interface 즉 껍데기만 줘서 어떠한 서비스가 있는지 알려주어(일전에 말하였던 공개)..

서버의 비지니스 로직을 호출하게 되어있다.

굳이 RMI 뿐만 아니라 분산객체라 불리는 것들이 이러한 방법으로 interface를 사용하게되는데...

Interface의 프로토타입이 변경되지 않는한 클라이언트가 변경되어야할 일은 없다.

그러므로 서버의 로직 변경에 클라이언트는 영향받지 않게된 것이다.

그렇다면 Interface가 변경이 되어 버린다면 어떻게 될까?

이전 글에서 Interface는 약속이라 하였다.

서버에서 이 약속을 깨버리면..

음..

Interface가 변경되었다는것은 '클라이언트 변경이 불가피하다'라는것이다.

그래서 한번 배포된 Interface는 함부로 변경(수정, 삭제, 확장을 포함해서)이 되어선 안된다는것이다.

일대 혼란(업데이트 이슈)이 발생..

(첫 배포가 그래서 중요합니다.)

MS쪽에서는 Interface 변경해야할때..

최초에 배포된 Interface는 변경하지 않고 확장만한다.

예를 들어

IXMLDOMDocument

IXMLDOMDocument2(IXMLDOMDocument을 상속하여 좀더 확장된 버전)

이런식으로 Interface를 넘버링으로 구별하여 변경하고 있다.

관심 분야가 아니라도 간혹 이러한 네이밍 룰을 보았을것으로 생각한다.

이는 종전에 배포된(IXMLDOMDocument) Interface는 이미 배포되었으니 그냥 쓰고 ..

새로 App작성시 혹은 업데이트시 IXMLDOMDocument2를 사용하라는 MS의 의도이다.

물론 최초에 IXMLDOMDocument2가 지원하는것을 고려해서 Interface를 작성하는것이 최선안이 되겠지만..

모든것을 예측하기에는 인간은 너무나 부족하다.

결국 이 글의 하고자하는 말은

Interface는 상호간 약속이므로 함부로 변경되어선 안된다는것

(이 한줄까지 오기위한 서론이 너무 길었습니다.^^)

이는 Interface를 설계시 고려해야할 기본 덕목이라 할 수 있다.

여기서 말하고자하는것은

Interface 자체가 중요한게 아니라..

Interface를 사용하는 의미가 중요하다라는것..

이러한 컨셉으로 클라이언트를 더욱 가볍게 하는 것은

Interface를 사용하는 또 하나의 보이지 않는 역할이라고도 할 수 있다.

/*

에필로그

Interface 이야기는 여기까지하고자 합니다..

성원을 보내주신 분들이 계셔서 탄력받아 계획에도 없던 글을 하나 더 올렸습니다.

적고 보니 요즘에는 너무 당연하고 철지난 얘기라..

좀 그렇습니다..^^;

여기서 더 나가면 세부적인 기술 강좌로 가야할것 같습니다...그래서 여기까지만...^^

부담없이 가볍게 읽어 내려갔으면하는 것이 바램입니다만, 그랬는지요..^^?

저는 한때 작가의 길을 걷고자 했던적이 있었습니다. 고등학교때 문학이 너무 좋아서..

나름 문학 소년이었답니다.(이글 작문한걸 보면 안 믿어지실테지만..-_-;;)

그러나 다행히도 그당시에 재능이 없다는걸 빨리 깨닫고 포기를 했더랬습니다.

그때 꿈을 접지 않았다면 지금 굶어 죽었을것 같습니다...-.-;;

지금 생각해도 다행이라 생각합니다..-.-

우스게 소리였습니다...ㅎ..

수고하셨습니다.

워낙 문장력이 없다보니 탈고해주신 분이 있습니다.

special thanx. 꼼

*/

너무나 많은 곳에 쓰이는 단어 인터페이스(Interface)..

UI(User Interface), 프로그래밍 언어에서 부르는 Interface, API, CGI 등..

우리는 가끔 여러 사람 혹은 다른 회사와 공동 프로젝트 진행시

"인터페이스를 맞추자"

"인터페이스를 열어 달라"

"인터페이스 만들어 주세요"

"이렇게 하기로 인터페이스 정해 놓게 왜 인터페이스대로 하지 않습니까?"

이말을 두루뭉술하게 여러곳에 적용해서 아주 빈번히 사용하고 있다.

용어를 설명하는데 있어서 일반 사전적인 의미와 컴퓨터 사전적인 의미는 많이 다르다.

주로 컴퓨터의 용어가 더 많은 의미를 내포하고 있는데..

여러 방면에서 사용하고 있는 말이지만..

프로그래밍 언어에서의 인터페이스의 역할에 대해 그리고

이말을 사용하고 있는 공통적인 의미는 '약속'라는 뜻이 아닐까.?

라는데서 이글을 써내려 가려고한다.

프로그래밍 언어에서 Interface는 무엇으로 사용하는가..

Interface

하면 떠오르는 것들.

폴리모피즘, 상속, 오버라이드, 동적 바인딩

(저는 이런것들이 떠오르네요^^)

본인은 C++을 주력 언어로 사용하고 있지만..

java로 Interface라는 것으로 풀어 보려고한다.

개인적으로는 java가 더 후대 언어라서 인지 C++ 보다는 좀더 언어가 명확하다라고 해야할까? 좀더 과학적이랄까.

(java의 문법자체는 C에서 나온것에 이라는것에는 이견이 없습니다. 따라서 C 문법의 단점 또한 계승하고 있지요..-.-)

암튼 java를 해본지 너무 오래 되긴했지만(달갑진 않지만 지금도 언어 자체가 진화하고 있더군요..), java로 부터 나름대로 느낌점은 그렇다.

(뭐가 더 우수한 언어이고, 뭐가 좋은지에 대한 논쟁은 이 글에서 논하고자 하는 쟁점은 아니므로 있는 그대로만 받아들여 주시기 바랍니다.)

일단 문법적으로 Interface를 파악해 볼까!

java에서 Interface라는 키워드를 적었을때 문법적인 제약이 발생한다.

1. prototype만 기술

2. 자체 객체생성(instance) 할 수 없음.

3. 반드시 sub class에서 구현.

4. 그리고 접근자는 public !!

1~3번 은 문법적인 제약 조건이지만..

4번은 Interface를 사용하는것에 대한 아주 큰 의미를 내포하고 있다.

혹은 Interface를 사용하는 의미의 전부라고도 할 수 있다.

4번으로 인해 1~3이 왜 저러한 제약 조건이 붙은것인지에 대한 이유가 되기도 한다.

java쪽 기술에서 보면 J2EE라는 기술이 있고, API에서는 javax로 따로 분류하고 있는데..

Database관련하여 JDBC라는것이 있다.

Interface를 설명하는데 아주 좋은 예라 할 수 있다.

ODBC도 동일하지만 JDBC만을 예로 들자면

JDBC를 이용하여 개발시 우선 3가지 요소가 존재한다.

1. SUN :  Interface 만 제공

2. DB 벤더 : Interface 구현

3. 개발자 : Interface 활용

우선 SUN사에는 sql을 이용할 수 있는 interface만 만든다(정확히 표현하자면 '명세한다', '공개한다').

DB 벤더는 SUN서 공개한 Interface를 보고 구현을 한다(이것이 드라이버가 되겠지요).

개발자는 드라이버에서 구현된 Interface를 호출해서 쿼리를 던진다.

그럼 가정을 해보자.

SUN에서 Interface를 제공하지 않았다면 어떻게 될까.

A라는 DB 벤더는 독자적인 인터페이스를 만들어서 함수를 제공할것이다.

B라는 DB 벤더 또한 독자적인 인터페이스를 만들어서 함수를 제공할것이다.

C 벤더 또한 마찬가지로 독자적인 구현...

(아...우울해지겠죠...그쵸..?)

예를 들어 각 회사에서 쿼리를 실행하는 함수 다음과 같이 정의 했다.

A: runExec(string str)

B: RunQuery(String str)

C: ExcuteQuery(String str)

이와 같이 각 벤더가 정의 했다면 개발자는 각 벤더의 API문서를 봐야 할것이다.

왜 냐하면 Interface가 모두 다르기 때문에..

(이런것들을 native driver라 부르지요..)

좀더 들어가서 개발자는 위 세가지 DB를 모두 지원하는 어플리케이션을 만든다고 가정한다면..

if문의 분기 처리로 호출할것인지.. 이때부터 난잡해지는 코드에 고민에 빠지게 된다.

하지만 JDBC를 이용하면 SUN에서 Interface를 공개(혹은 제약) 했기때문에...

각 DB 벤더는 그 Interface 명으로 Interface를 자사의 DB에 맞게 각기 구현해야만한다.

따라서 개발자는 각 벤더가 어떻게 구현했는지 알 필요가 없다.

개발자는 각 DB 벤더가 어떻게 구현했는지는 몰라도 "나는 이 Interface만 호출하면 원하는 결과를 얻을 수 있다"라는 것을 알고있다.

각 벤더의 API문서를 볼 필요도 없고(아주 가끔은 필요할 수 도..) 개발자는 SUN에서 제공한 Interface에대한 명세만 보면 되니까.

'SUN에서 Interface라는 제약을 뒀기 때문에 각 벤더가 자사의 DB에 맞게 구현됐다'라고 보장을 받을 수 있기 때문이다.

언어의 문법상 Interface는 상속하여 반듯이 구현해야 하기 때문에 각 DB 벤더는 알아서 구현했을 것이다.

그럼 여기서 초반부에 Interface는 '약속'이다라고 무작정 정의해버린 문장에 부합된다고 볼 수 있지 않을까.

여기서 Interface를 다른 말로 바꾸어 보면..

Interface는

약속이다.

공개이다.

명세이다.

규약이다.

프로토콜이다.

모두 맞는 말이 아닐까..

위에서 나열한 1~4에 대한 내용이 4이기 때문에 1~3이 그렇게 될 수 밖에 없다는것에 대한 이유가 된다고 볼 수 있다.

아주 간단하게 정리해보자

Interface는 어떻게 구현됐는지는 모르지만, Interface만 호출하면 원하는것을 얻을 수 있다.

그러므로 인터페이스 공개(public)가 아닌것이 의미가 있을까!!

("공개가 아닌 인터페이스는 의미가 없다"라고 정의 해도 되겠지요?)

Interface를 활용한기술이 또 무엇이 있을까?

RMI

CORBA

COM

EJB

...

...

위 기술중 한가지는 반듯이 써봤을것을 믿어 의심치 않는다.

COM을 사용하면서 우리는 COM에서 제공한 Interface만 보고 작성한다.

어떻게 작성되어 있는지 우리는 알지 못하지만, Interface를 호출하면 된다는것 만큼은 알고있기 때문에..

왜냐하면 그렇게 약속했으니까, 규약했으니까, 공개했으니까.



출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=70&MAEULNO=4&no=128&page=3