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. 꼼
*/
출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=70&MAEULNO=4&no=130&page=3
