Egloos | Log-in
결론에 가보기
결론에 가보기
[잡생각] 자바가 불편해요..


부제 : 최고수준의 인터페이스는 형태를 초월한 것이다!

얼마전에 자바를 잘 못하는 회사동료에게 이거 저것을 알려주다가
인터페이스라는것이 참 어렵다라는 생각이 든다. 

인터페이스의 개념은 무엇인지 아는데 잘 쓰기가 너무나도 힘들다.
그리고  JDK5.0이 되면서부터 더 까다롭다..

동료가 원하는 것은 key/value 로 3개정도를 넣고 이런 데이터를 여러개가 있다.
이런 구조라면 key/value는 Map에 넣고 이것을 List에 넣으면 될것이다. 

보통 쓰는 방식이 
List alist = new ArrayList();
for ( 루프돌기)
  Map bmap = new HashMap();
  bmap.put("x", "1");
  ...
  alist.add(bmap);

선언은 List로 하고 생성은 왜 ArrayList로 하는지, Map으로 선언하고 HashMap으로 쓰는지
한창 설명을 하고 있었는데 이클립스님하께서 warning을 뿜어주신다.. 

정확하게 5.0 이상에 맞는 스펙으로는 아래와 같이 해야 한다
List<Map<String,String>> alist = new ArrayList<Map<String,String>>();
for ( 루프돌기)
  Map<String,String> bmap = new HashMap<String,String>();
  bmap.put("x", "1");
  ...
  alist.add(bmap);

실제로 사용되는 list의 클래스가 어떤것이던지 상관없이 List의 interface로 선언을 해서
기본적인 method들은 그 안에 있는 것으로 공통적으로 쓰기 위함이다. 

하지만 List<Map<String,String>> 와 같이 안에 어떤 것이 있는지 정확히 알아야 하니깐
List라는 인터페이스를 쓰는 의미가 많이 퇴색된것 같다. 
사실 뽑아쓰기 위해서 형변환을 하는 것 자체가 이미 인터페이스 의미의 절반을 날려먹는듯하다.


루비코드로 표현해보자

alist = Array.new
루프.each do |x|
  bmap = Hash.new
  bmap["x"] = "1"
  .. 
  alist << bmap
end

뽑아서 쓸때는
alist.each do |y| 
  pp y["x"]
end

루비는 까다롭게 형을 강요하지 않는다.  Array나 Hash의 경우는 예외이지만
따라서 Array이건 디비에서 뽑아온것이건 each 라는 것으로 거의 모든것이 해결된다.
뽑을때도 거의 대부분 . 으로 해결이 된다. 

이것을 인터페이스라는 개념으로 보면 
내부적으로 어떤 형태로 선언해서 사용하였건 each라는 기본형(?)에 있는 메서드로 해결이 된다.

어떻게 보면 이것이 최고수준의 인터페이스가 아닐까?
기본형에 있는 메서드로만 표현이 모두 가능하다. 그 내부에 무엇을 사용하였건!!!

ps. 루비가 만능이 아니라 형을 까다롭게 체크하지 않는 언어중에서 루비를 선택한것 뿐이다 ^^
by 제우스 | 2009/05/13 12:32 | 컴퓨터 | 트랙백 | 핑백(1) | 덧글(17)
트랙백 주소 : http://zeous.egloos.com/tb/2316392
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Linked at 결론에 가보기 : 2009년 .. at 2010/01/04 15:25

... vs 불꽃처럼 나비처럼게임 (9회) / [잡생각] wow 근황가장 많이 읽힌 글은 [영화] 쌍화점 입니다.가장 대화가 활발했던 글은 [잡생각] 자바가 불편해요.. 입니다. ( 덧글 17개 ) 작년에 비해서 좀 떨어졌네요..왠지 블로그에 자신감이 좀 떨어져가고 있네요 ㅠㅜ ... more

Commented by 승네군 at 2009/05/13 13:11
호... 템플릿...

자바는 안써서 모르겠지만.. 템플릿은 지옥이라는 느낌을 받았습니다.

더불어, 인터페이스는... 태아... 정도라고 보면 될려나요?
Commented by 최종욱 at 2009/05/13 14:00
Groovy를 써보세요. ^^
Commented by 제우스 at 2009/05/13 16:02
groovy, grails 쓸줄 압니다. 아주 매력적이죠 ^^
아주 초창기에 싸이트에 적용해본적이 있어서요..
나름 꽤 발전할것이라 생각했는데 의외로 속도가 느리네요..
groovy,jruby가 JDK안에 포함이 된다고도 들었는데 어떨지 모르겠네요..
Commented by 가이우스 at 2009/05/13 14:14
c++이나 c 그리고 어셈블리어를 써보세요... 자바가 편해질겁니다...(먼산...)
생각해보니 자바를 쓸 일이 요즘 전혀없네요.
Commented by 제우스 at 2009/05/13 16:04
저도 자바만을 사용하였다면 이런 생각이 많이 안들었을듯한데
확실히 이런 저런 다른 언어를 사용하다가 보니깐 장단점이 더 잘보이는듯해요..
C보다 자바가 편하게 느껴졌던 것이 메모리 문제라고 하면
자바보다 다른 언어가 더 편하게 느껴진다면 제가 포스팅한것도 포함이 되지 않을까요? ^^
Commented by fooo at 2009/05/13 15:07
타입을 강요하지 않는 대신
테스트를 제대로 안 하면 나중에 버그의 근원이 되니...
코딩할 때 신경쓰느냐 테스팅을 더 충실히 하느냐..

개인적으로는 후자를 선호합니다.
내가 대충 짜 놓아도, 테스터들이 알아서 고쳐놓으니 얼마나 편합니까.

Commented by 제우스 at 2009/05/13 16:14
타입으로 나중에 버그가 생긴다.. 흠.. 가능성은 있지만 그게 낮지 않을까요?
메모리릭 같은 내포되어 있지만 찾기 힘든것이 아니라 챙겨야할 케이스를 놓친정도가 될듯하네요.

그리고 한가지
테스터중에 정말 꼼꼼하고, 깔끔하게 테스트를 잘 해주는 사람, 소위말하는 A급이라는 사람들이 있죠.
반대로 테스트가 볼때 에러 케이스가 적은 개발자들도 있죠. 저 사람의 프로그램은 테스트할것이 거의 없단말이야..

테스터가 테스트하는 것은 개발자가 놓친 부분을 하는것 아닌가요?
개발자가 느끼기에 대충(에러가 듬뿍담긴)짠 것을 테스터에게 넘긴다면 이미 테스터사이에서는 유명할것입니다.
허접개발자라고요.. ^^
Commented by 써니 at 2009/05/13 19:11
덧글들을 읽어 보니.. .한 줄 요약하면, 결론은 trade-off 수준 문제(?)

자바를 구상하던 초창기에는 엄격한 규칙을 도입해야 한다는 주장이 강력히 어필되었다고 하더군요. (출처는 못 찾겠고... ^^;)
그게 또 자바의 매력 혹은 특징으로 자리매김 했고, 그에 대한 거부감이 또 groovy 같은 대체재가 나오게 된 계기가 되고...

세상은 돌고 도는 거죠 뭐...
엄격한 거 싫다고 해서 편한게 나오면, 그러면 잠재적인 문제는 어찌할꺼냐?
하면서 또 엄격한게 나오고...

애매한 얘기를 쓴 거 같기는 한데, 제 입장은 '인터페이스'는 굳이 필요하지 않으면 쓰지 마라입니다.
제대로 알고, 꼭 써야할 상황을 상정할 수 없다면 누구 말마따나, over-specification이 되는거죠.

마티즈에 날개 달아둔다고 해서 스포츠카가 되는 건 아니니까요~
Commented by 제우스 at 2009/05/14 17:58
JDK에 포함되어 있는 소스이외에 interface를 제대로 썼다라는 코드는 만나본적이 없는듯해요..
특히나 요즘처럼 디자인패턴이 나오면서는 더욱더..

오래전에 한번 잘 썼다라는 느낌을 받은적이 있었는데
지금 그코드를 다시보게 되면 어떨지 모르겠네요 ^^

제가 하는 일이 interface의 기능을 제대로 쓰는 정도가 아니라서 그런것 같기도 하고요 ^^
써니님은 제대로 쓰신적이 있으신가요?
Commented by 써니 at 2009/05/14 18:10
저는 interface를 쓰면서 황홀경(?)에 빠진 사람입니다. ^^;

몇몇 설계에서 interface의 유용성을 체험해본 적도 있기는 하지만,
JDK에 포함된 인터페이스 만큼 멋진 케이스를 자주 찾아보기는 어렵죠.

저는 인터페이스를 자유자재로 사용하는 수준은 아닙니다.
인터페이스의 최대 효용성은 '범용성'을 극대화 할 수 있다는 점인데,
범용성이 필요한 프로젝트, 솔루션, 혹은 컴포넌트라는 것이 몇 가지나 될까요?
1000개의 클래스를 작성하다 보면 몇 개 나오지 않습니다.

그럼에도 불구하고, 실전에서 만나게 될 가능성이 낮은, 혹은 '희소성'이 높은 기술이지만
가장 아름다운 - 혹은 가장 단순한 설계 -를 적용할 수 있는 기회를 만난다는 것.
프로그래머들이 아주 가끔 '프로그래밍의 미학'을 탐닉할 수 있는 순간이 아닐런지요.

인터페이스를 제대로 써먹어야 할 만한 상황을 만났을 때,
저는 '심봤다'라고 외칩니다... ^^
Commented by Corund at 2009/05/13 20:28
본문의 예시는 인터페이스의 적절한 사용 예는 아닌 듯 싶네요. 메서드 또는 클래스 수준까지는 가야 인터페이스의 의의를 좀 더 알릴 수 있지 않을까요?

어셈블리, C/C++에서 넘어오면 자바가 편한 걸 알 수 있을 거라 하신 분도 있는데 php, python 등의 동적 타입 언어를 쓰다가 자바와 같은 엄격한 타입 시스템 언어를 쓰면 아주 마음이 편하던데요. 가능한 한 에러를 컴파일러가 잡아준다는 것은 큰 장점 아닐까요? 루비 같은 언어의 장점은 여러가지 강력한 기능 때문이지 동적 타입 때문은 아니지 않나 생각합니다.
Commented by 제우스 at 2009/05/14 18:01
개발자 스스로가 만든 interface들은 다들 자신의 상황에 특화가 된것이라서
일부러 JDK에 포함되고 많이 쓰는 List와 Map을 선택하였는데..
제대로된 소스가 있다면 알려주시면 열심히 공부해볼께요~

동적타입... 좋냐 싫으냐는.. 결국 개인의 취향이겠지만 제 느낌상 동적타입이 큰 흐름이 되지 않을까 생각이 됩니다 ^^
Commented by Corund at 2009/05/14 21:52
spring framework도 인터페이스를 잘 사용한 예가 되겠죠. spring framework는 인터페이스를 사용하여 설계할 것을 권장하기도 합니다. :)
Commented by 오리대마왕 at 2009/05/15 13:06
List<Map<String,String>> 를 쓴다고 하여 List interface 를 쓰는 의미가 퇴색한다는 말씀엔 선뜻 동의하기가 어렵네요. generic 이 문제가 되신다면 @SuppressWarning 을 쓰시면 될 것 같구요.
interface 언급을 하시면서 generic 이 껴들어가서 의도를 파악하기가 어려워졌어용 ㅎㅎ

근데 저도 interface 좋은 것은 알겠는데, 정말 유용한 적이 있었니? 라는 의문에는 글쎄요 라는 대답밖에 못하겠어요.
framework 을 만들거나 뭔가 strategy pattern 이라도 쓴다면 "야 interface 써서 참 좋았어!" 라고 하겠지만 대부분 interface 에 concrete class 가 1:1 매칭되는 상황이라 이거 뭐...

generic 측면에선 전 generic 광팬입니다. List 에 뭐 들어가는지 남이 짜 놓은 코드 안까보고도 충분히 믿음을 가질 수 있어서 아주 좋아합니다. String 인지 Integer 인지 몰라도 되니. generic 없는 Map, LIst 는 이제 불안해서 못 쓸 지경. 단, java와 같은 strong type 이라서 애시당초 이런 걱정을 하고 있는게 아니냐고 말씀하시면 "그렇다" 라고 말씀드리고 싶어요.
Commented by 제우스 at 2009/05/15 16:10
초고수 오리대마왕 등장하셨군요 ^^

warning을 무시하겠다는 것보다는 지금 warning이면 앞으로는 그것이 기본 문법에 들어갈것 같아서 걱정이 되는것뿐입니다..
노란색 라인은 무시하면 되죠..머

글에서도 언급한것처럼 interface의 최고수준은 동적타입이라는 것이죠
안에 무엇이 있건말건 이 메서드 한개로 모든것을 처리할수 있어!!! 라는 거죠

generic처럼 안에 이런것이 들어 있을꺼야!! 라고 명시해주는 것, 명시를 해야만 하는것은
안에 무엇이 있건 이것으로 해결해주겠다.. 라는 interface의 역할을 깍어먹게 된다고 생각이 되어요..
그래서 interface에서 generic을 언급한것입니다.

참.. 메신저로 물어볼려고 하던것!!!

spring framework에서 service inteface - service class, dao interface - dao class 를 구조를 꼭 따라야 하는것인가요?
실제로 제가 쓸때는 80%정도는 위의 구조를 따르고 나머지는 안따르고 있어서 위의 구조가 강제가 아니라 권장정도인듯한데
사실 1:1로 매칭이 되는 지금 프로젝트에서는 interface만 걷어내도 파일 1/3은 줄일수 있을것 같아요..

이 대답이 ^^ corund 님의 댓글에 대한 대답도 되는데 ^^
spring framework 자체적으로는 interface를 잘 활용하였지만 spring framework을 쓰는 우리들은 interface를 꼭 써야 하는지 잘 모르겠어요.
거의 대부분 interface-class가 1:1 매칭인데.. 써야 하나?
Commented by 오리대마왕 at 2009/05/15 16:52
많은 사람들이 고민하는 것 같은데요, 결국 개발비용 vs. 확장성 (유연성 포함) 의 문제가 아닐까 해요.

원칙만 있다면 무엇을 어떻게 하든 프로젝트 자체엔 큰 문제가 없지 않을까 생각해요. 단, 원칙은 아주 중요하다고 생각합니다. interface 쓸라면 다 쓰고, 말라면 다 말고.

그리고 요즘 들어 생각하고 있는게, interface 를 걷어버리고 concrete class로 바로 가고자 할 때 하나 더 고민을 해 보시면 좋지 않을까 하는게 java package 간 순환 참조(cyclic reference)가 발생하기 쉬운데 이것이 발생하지 않도록 유지할 자신이 있는가 하는 것 입니다. 만약 interface 쓴다면 interface 와 concrete class 조정하기가 쉬울 텐데 그렇지않고 concrete class 쓴다면 욜라리 어려울 것 같아요. 저는 패키지 간 순환 참조는 절대 안된다고 생각합니다. :)
Commented at 2009/05/15 16:53
비공개 덧글입니다.

:         :

:

비공개 덧글

◀ 이전 페이지 다음 페이지 ▶

카테고리
영화나 책
말말말
컴퓨터
게임이야기
태그
서버개발 개발자 공연 ngrinder 웹개발자 제이슨프라이드 똑바로일하라 화성학 직업 vanish 디아블로3 기타코드 재태크 라이프사이클 하이코드 2nd밴드 원리 오픈세미나 보험 파워코드 마이너코드 게임 나꼽살 스테가노그래피 helloworld 슬럼프 개발 ror 메이저코드
전체보기
최근 등록된 덧글
엄지척 바짝 올립니다. 궁금했던..
by 초보 at 10/11
다자가이든 소작이든 닭이 천 마리..
by yada at 09/20
나는 팔라독 헬 깸.
by 남영찬 at 06/17
^안녕.하세요^;; 골드팟 생기개..
by 전설의레전드소설책 at 03/25
이왕이면---- A7 등등 '7' 이 붙는..
by papagoat at 04/12
매우 감사합니다 ! 아주 쉽게 키..
by papagoat at 04/12
자꾸 F를 라로 표기하시네요 ㅎㅎ
by 안녕하세요 at 12/21
시 클라식 기타 코드표 도 보여..
by 강초보 at 06/08
sp를 싫어하는 개발자들은 유지..
by 나도개발자 at 04/23
여자친구와의 금연약속을 어겨서..
by 구사일생 at 11/13
라이프로그
똑바로 일하라
똑바로 일하라

펜트하우스 코끼리
펜트하우스 코끼리

화폐전쟁
화폐전쟁

10억
10억

거북이 달린다
거북이 달린다

용의자 X의 헌신
용의자 X의 헌신

마더
마더

터미네이터 : 미래전쟁의 시작
터미네이터 : 미래전쟁의 시작

스타트렉 더 비기닝
스타트렉 더 비기닝

천사와 악마
천사와 악마

노잉
노잉

7급 공무원
7급 공무원

박쥐
박쥐

인사동 스캔들
인사동 스캔들

와이키키 브라더스
와이키키 브라더스

매란방
매란방

건투를 빈다
건투를 빈다

코끼리는 생각하지 마
코끼리는 생각하지 마

배려
배려

벤자민 버튼의 시간은 거꾸로 간다
벤자민 버튼의 시간은 거꾸로 간다

작전
작전

워낭소리
워낭소리

작전명 발키리
작전명 발키리

적벽대전 2 : 최후의 결전
적벽대전 2 : 최후의 결전

트랜스포터 - 라스트미션
트랜스포터 - 라스트미션

디파이언스
디파이언스

사랑하지 않으면 떠나라!
사랑하지 않으면 떠나라!

촐라체
촐라체

쌍화점
쌍화점

황후화
황후화

크리스마스 별장
크리스마스 별장

눈먼 자들의 도시
눈먼 자들의 도시

예스맨
예스맨

순정만화
순정만화

펀치 레이디
펀치 레이디

눈에는 눈 이에는 이
눈에는 눈 이에는 이

전략적 책읽기
전략적 책읽기

돈, 뜨겁게 사랑하고 차갑게 다루어라
돈, 뜨겁게 사랑하고 차갑게 다루어라

좋은 놈, 나쁜 놈, 이상한 놈
좋은 놈, 나쁜 놈, 이상한 놈

다크 나이트
다크 나이트

H2 1
H2 1

그림으로 읽는 생생 심리학
그림으로 읽는 생생 심리학

호모 코레아니쿠스
호모 코레아니쿠스

강철중: 공공의 적 1-1
강철중: 공공의 적 1-1

이채원의 가치투자
이채원의 가치투자

쿵푸 팬더
쿵푸 팬더

카불의 사진사
카불의 사진사

인디아나 존스 4 - 크리스탈 해골의 왕국
인디아나 존스 4 - 크리스탈 해골의 왕국

시골의사의 부자경제학
시골의사의 부자경제학

종자돈 700만 원으로 부동산 투자 200억 만들기
종자돈 700만 원으로 부동산 투자 200억 만들기

우리동네
우리동네

디지로그 digilog
디지로그 digilog

대하소설 주역 4
대하소설 주역 4

읽지 않은 책에 대해 말하는 법
읽지 않은 책에 대해 말하는 법

Stick 스틱!
Stick 스틱!

색즉시공 시즌 2
색즉시공 시즌 2

바르게 살자
바르게 살자

20대는 통장을, 40대는 인생을 채워라
20대는 통장을, 40대는 인생을 채워라

점퍼
점퍼

생로병사의 비밀
생로병사의 비밀

추격자
추격자

오늘의 거짓말
오늘의 거짓말

주식시장을 이기는 작은책
주식시장을 이기는 작은책

대한민국 진화론
대한민국 진화론

무방비 도시
무방비 도시

피라니아 이야기
피라니아 이야기

우아한 세계
우아한 세계

경제를 읽는 기술
경제를 읽는 기술

실용주의 프로그래머
실용주의 프로그래머

블로그 비즈니스
블로그 비즈니스

어거스트 러쉬
어거스트 러쉬

세븐데이즈
세븐데이즈

뷰티풀 선데이
뷰티풀 선데이

괴물 1
괴물 1

킹덤
킹덤

당신과 일하기 힘들어 죽겠어
당신과 일하기 힘들어 죽겠어

뉴욕의 프로그래머
뉴욕의 프로그래머

나를 바꾸는 데는 단 하루도 걸리지 않는다
나를 바꾸는 데는 단 하루도 걸리지 않는다

벽오 금학도
벽오 금학도

해바라기
해바라기

펀드투자가 미래의 부를 결정한다
펀드투자가 미래의 부를 결정한다

상식이 통하는 웹사이트가 성공한다
상식이 통하는 웹사이트가 성공한다

아버지의 가계부
아버지의 가계부

본 얼티메이텀
본 얼티메이텀

최강 로맨스
최강 로맨스

여자도 여자를 모른다
여자도 여자를 모른다

부동산 10년 대폭락 시나리오
부동산 10년 대폭락 시나리오

아키텍트 이야기
아키텍트 이야기

보물지도
보물지도

오션스 13
오션스 13

게임회사 이야기
게임회사 이야기

바람피기 좋은 날
바람피기 좋은 날

조폭 마누라 3
조폭 마누라 3

삼미 슈퍼스타즈의 마지막 팬클럽
삼미 슈퍼스타즈의 마지막 팬클럽

광기와 우연의 역사
광기와 우연의 역사

런어웨이
런어웨이

회사가 당신에게 알려주지 않는 50가지 비밀
회사가 당신에게 알려주지 않는 50가지 비밀

롱테일 법칙
롱테일 법칙

해리 포터와 불사조 기사단
해리 포터와 불사조 기사단

사소한 것에 목숨 걸지 마라 - 습관 바꾸기 편
사소한 것에 목숨 걸지 마라 - 습관 바꾸기 편

우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해
우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해

트랜스포머
트랜스포머

20대부터 시작하는 스트레스 제로기술
20대부터 시작하는 스트레스 제로기술

미운오리새끼의 출근
미운오리새끼의 출근

캐리비안의 해적 : 세상의 끝에서
캐리비안의 해적 : 세상의 끝에서

미녀는 괴로워
미녀는 괴로워

유태우 교수의 내몸개혁 6개월 프로젝트
유태우 교수의 내몸개혁 6개월 프로젝트

브레이크 업 : 이별후애(愛)
브레이크 업 : 이별후애(愛)

인사이드 맨
인사이드 맨

마키아벨리, 회사에 가다
마키아벨리, 회사에 가다

웹 2.0 경제학
웹 2.0 경제학

한반도
한반도

연애, 그 참을 수 없는...
연애, 그 참을 수 없는...

구미호 가족
구미호 가족

럭키 넘버 슬레븐
럭키 넘버 슬레븐

찰리와 초콜릿 공장
찰리와 초콜릿 공장

아파트
아파트

레전드 오브 조로
레전드 오브 조로

rss

skin by jiinny
X