초보적인 질문 드리겟습니다 ㅠ

[야구쟁이]

오늘 친구랑 이야기 하다가 생긴 궁금증입니다...

하나의 인터페이스와 그걸 구현한 클래스 하나가 있습니다...

그럴땐 굳이 인터페이스가 필요가 있을까요? 확장될 여지가 없다면 필요가 없지않을까요?

그런데 책에서도 대개 인터페이스당 하나의 빈이 등록되는 경우가 많다고 예를들어놓는경우를 많이 보았습니다.

인터페이스가 굳이 필요한 이유가 궁금합니다...

[Sungchul Park]

결론이 쉽지 않은 질문입니다.
쉽지 않은 이유는 경험이 필요하기 때문입니다.
 
지난 토스3 토론에서 어떤 방식의 설계가 좋을지 다루면서 지금은 필요 없지만 앞으로 필요할지도 모르니 유연성을 주는 쪽이 좋지 않냐는 식의 의견이 많았습니다.
그렇다면 지금 말씀하신 "확장될 여지가 없다" 는 결정은 누가 한 걸까요?

켄트백이 구현패턴에서 이런 말을 했습니다.

소프트웨어 개발에 관한 오랜 격언 중 하나로, 구현이 아니라 인터페이스에 맞춰 코딩하라는 말이 있다. 이는 설계상의 결정을 필요 이상으로 노출하지 말라는 뜻이다.
<중략>
인터페이스 추가에는 비용이 발생한다. 인터페이스를 사용하게 되면 우리는 인터페이스를 배우고 이해하며 문서화하고 디버깅하고 정리하고 조회해서 적당한 이름을 지어야 한다. 인터페이스 수를 최대한 늘린다고 해서 소프트웨어 비용이 최소화되는 것은 아니다. 따라서 인터페이스를 통해 유연성을 얻을 수 있는 경우에만 인터페이스에 비용을 지불해야 한다.
<중략>
인터페이스를 사용하게 된 경제적 이유로는 소프트웨어는 예측하기 어렵다는 점을 들 수 있다.
<중략>
이제 지금까지의 내용을 종합해보자. 소프트웨어는 유연해야 하지만 유연성에는 비용이 들고, 어떤 부분에서 유연성이 필요할지 예측하기란 쉽지 않다. 따라서 실제 필요해지는 경우에만 시스템의 유연성을 부여하자는 결론에 이른다. 유연성을 부여하려면 기존 코드를 수정해야 하기 때문에 비용이 발생한다. 만약 소프트웨어 수정을 혼자 감당할 수 없다면, 비용은 더욱 커진다.

결국 지금 당장 인터페이스를 도입해서 드는 비용과 나중에 유연성을 부여하려고 변경하는 비용간의 저울질이 필요하다는 뜻 같습니다.

지금 만들려는 인터페이스를 개인적으로만 사용할 거라면 나중에 만들어도 무방할 가능성이 높겠습니다.
팀이 사용하는 거라면 가능한 만드는게 충돌을 줄일 수 있겠죠.
누가 쓸지 모른다면 반드시 만드는 편이 좋겠습니다.
테스트 자동화를 하실거라면 만드는 게 좋습니다. (아니! 요즘도 테스트 자동화를 안 하겠다고 하는 사람이 있습니까? ㅋㅋ 농담입니다)

그런데 인터페이스를 써야하나 고민하기 전에 우리가 OOP기법을 이해하고 활용하고 있는지 먼저 점검해봐야 할 듯 합니다. 개편작업을 할 때마다 왜 우리는 매번 인프라와 찰떡처럼 붙어 있고 잘못된 설계 때문에 스파게티처럼 꼬인 코드를 버리고 다시 작성해야 하는 걸까요?

[Kesarr]

광의적 의미에서 인터페이스라는 추상화 개념은 비단 객체지향 프로그래밍에서 뿐만 아니라 프로그래밍 전반, 나아가 모든 공학적 접근에서 매우 중요합니다.

컴퓨터, 스마트폰, 외장메모리, 태블릿, 마우스, 프린터, ... 수많은 장치들이 USB라는 표준화된 인터페이스를 제공하고 있으며, 만약 이런 인터페이스 추상화가 없었다면 지금 우리의 노트북에는 수십가지 종류의 포트들이 달려있어야 했을지도 모르겠습니다. 또한 우리는 (마치 아이폰 앱과 안드로이드 앱을 따로 만들듯) PC에서도 모든 종류의 그래픽카드, 모든 종류의 사운드 카드, 모든 종류의 랜카드, 모든 종류의 디스크 별로 서로 다르게 구현된 프로그램을 만들어야 했을지도 모릅니다.

이렇게 우리가 WinAPI 혹은 POSIX와 같은 단일 인터페이스를 통해 다양한 플랫폼과 장치의 동작 방식, 드라이버의 내부 구현에 의존하지 않고도 추상화된 프로그램을 만들 수 있다는 것은 실로 축복입니다.

객체지향 설계의 범주로 한정짓자면 인터페이스는 특히 DIP(Dependency Inversion Principle)를 실현케 합니다.

고수준(high-level) 컴포넌트가 저수준(low-level) 컴포넌트들을 직접 의존해 구성하는 전통적인 프로그래밍 방식과 다르게, 저수준 컴포넌트들이 고수준 컴포넌트에서 정의한 인터페이스를 구현함으로써 의존관계를 뒤집는 것이죠.

이렇게 함으로써 고수준 컴포넌트를 저수준 컴포넌트로부터 독립할 수 있으며 언제든지 고수준 컴포넌트를 재사용하고, 저수준 컴포넌트를 교체할 수 있게 됩니다.

위에서 언급한 USB나 API들도 결국 철저하게 DIP에 따라 만들어지는 사례인 것이며, 스프링 프레임워크의 근간을 이루는 IoC/DI(Inversion of Control/Dependency Injection)도 DIP를 바탕으로 합니다.

그래서 IoC/DI의 대상인 스프링 빈은 인터페이스에 의존해 구현하고, 인터페이스를 통해 주입하는 것이 바람직합니다.

일반적으로 인터페이스에 의존하지 않고 직접 구현 클래스를 사용한 경우에, IoC/DI의 설계 의도를 정확히 실현하지 못했을 가능성이 크며 심지어 직접 필요한 곳에서 new 연산자를 이용해 객체를 할당했을 때와 큰 차이가 없을 정도로 스프링 빈 흉내만 내게 되기가 쉽습니다.

하지만 그렇다고 해서 인터페이스를 사용하는 것 자체가 중요한 것은 아닙니다.

그런 원리에 대한 충분한 이해와 고민없이, 다들 필요하다고 하니까 문법적으로 인터페이스를 만들어 넣거나, 예제에 인터페이스가 있으니까  따라서 인터페이스를 만드는 것만으로는 결코 그 혜택을 누릴 수 없으며, 자연스럽게 '인터페이스는 불필요하다'는 결론으로 흘러갈 것입니다.

전동 드릴은 분명 나사를 조이는데 있어 수동 드라이버보다 훨씬 편리합니다!

하지만 전동 드릴을 나사에 대고 수동 드라이버를 돌리듯 뺑글뺑글 돌려봤자 나오는 결론은 하나입니다.

"드릴은 오히려 무거워서 돌리기 힘들잖아! 이걸 굳이 써야 해?"

마지막으로, 이상의 서술에서 인터페이스라 함은 Java에서 언어적으로 제공되는 interface라는 특정 문법 요소에 한정된 것이 아님을 밝혀둡니다.

2011년 2월 24일 오후 11:24, 야구쟁이 <jich...@gmail.com>님의 말:

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

[원상호]

와우. 정말 잘 풀어서 설명해 주셨네요.

마지막에 드릴로 예를 든 것은 멋지군요.

2011/2/25 Kesarr <kes...@playxp.com>

--
-----------~~-----------------~~-----------------~~------------------~~--------------------~~--------------------~~------
* 원상호 (Won, Shawn), BPNR
* E-Mail (sh...@bpnr.co.kr, shaw...@gmail.com), Jabber ID : shaw...@gmail.com
* --- "The best way to predict the future is to invent it" - Alan Kay
-----------~~-----------------~~-----------------~~------------------~~--------------------~~--------------------~~------

[야구쟁이]

감사합니다 OOP에 대한 공부에 대한 필요성이 절실히 느껴지네요...

[야구쟁이]

감사합니다 인터페이스에 대해서 다시금 생각하게 되네요... 아직도 갈길이 멀지만 열심히 노력하겟습니다

답변해주셔서 감사합니다

> 2011년 2월 24일 오후 11:24, 야구쟁이 <jichol...@gmail.com>님의 말: