fupfin님의 받은댓글

ㅋㅋㅋㅋㅋ 08.12.03 09:56

남은 필름 서너 컷 소진하러 정동길에 갔습니다. 아~ 역시 분위기 최고. 한 컷, 두 컷, 셋, 넷, 다섯, 여섯, - 오호 뽀나스! - 일곱, 여덟 - 응? - 와인더는 계속 돌아갔습니다. 힘없이 부드럽게… 한 달 전에 물린 필름인데… 필름도 못 물리는 초보. by fupfin

fupfin

이 녀석은 완전 기계식이라서 그런 것 모릅니다. -_-);;; 08.12.03 01:52

남은 필름 서너 컷 소진하러 정동길에 갔습니다. 아~ 역시 분위기 최고. 한 컷, 두 컷, 셋, 넷, 다섯, 여섯, - 오호 뽀나스! - 일곱, 여덟 - 응? - 와인더는 계속 돌아갔습니다. 힘없이 부드럽게… 한 달 전에 물린 필름인데… 필름도 못 물리는 초보. by fupfin

프쉬케

필름 제대로 안물리면 숫자 안돌아가지 않나요 ㄷㄷㄷㄷㄷ ㅠㅠ 08.12.03 01:47

남은 필름 서너 컷 소진하러 정동길에 갔습니다. 아~ 역시 분위기 최고. 한 컷, 두 컷, 셋, 넷, 다섯, 여섯, - 오호 뽀나스! - 일곱, 여덟 - 응? - 와인더는 계속 돌아갔습니다. 힘없이 부드럽게… 한 달 전에 물린 필름인데… 필름도 못 물리는 초보. by fupfin

알이즈웰

아 좋은 멸치를 넣어야 하는 군요 @@ 08.12.03 01:41

방금 아들과 제가 좋아하는 멸치 수육을 먹었습니다. (멸치 수육 = 다시 국물 내고 건져낸 멸치) by fupfin

Erica

아. 한때 써머셋 자주 갔는데. 하하하. 거기가면 만나는거 아니예요? ^^ 08.12.02 23:40

오늘의 커피，유콘 블렌드. 대중적인 라틴 커피와 내가 좋아하는 아시아 커피의 혼합. @ 써머셋 별다방 by fupfin

fupfin

제 아지트 같은 곳이에요. 주변이 상당히 고급스럽고 사람도 별로 없어서 얘기하거나 책 읽기 좋아요. ^^ 08.12.02 14:13

오늘의 커피，유콘 블렌드. 대중적인 라틴 커피와 내가 좋아하는 아시아 커피의 혼합. @ 써머셋 별다방 by fupfin

오리왕

써머셋 밖에서 볼 땐 뭔가 상당히 고급스러워보여서 별다방같은 “대중적인” 가게는 없을 줄 알았는데 딱히 그런 것은 아닌가봐요? 08.12.02 14:11

오늘의 커피，유콘 블렌드. 대중적인 라틴 커피와 내가 좋아하는 아시아 커피의 혼합. @ 써머셋 별다방 by fupfin

fupfin

왜 두개나...-_- 08.12.02 14:03

오늘의 커피，유콘 블렌드. 대중적인 라틴 커피와 내가 좋아하는 아시아 커피의 혼합. @ 써머셋 별다방 by fupfin

fupfin

사진찍는프로그래머 : 뭘 좀 아신다는..ㅎㅎ 08.12.02 01:07

방금 아들과 제가 좋아하는 멸치 수육을 먹었습니다. (멸치 수육 = 다시 국물 내고 건져낸 멸치) by fupfin

사진찍는프로그래머

아 입맛 당겨요. 08.12.01 22:18

방금 아들과 제가 좋아하는 멸치 수육을 먹었습니다. (멸치 수육 = 다시 국물 내고 건져낸 멸치) by fupfin

K-Dog

플래너는 그저 자세일 뿐.. 08.12.01 20:23

별다방 오늘의 커피，콜롬비아 나리뇨 수프리모. 낮게 깔린 오후 햇살이 내 마음 깊숙한 곳，진짜 내가 있는 음습한 그곳까지 따사로움을 전하려는 것 같다. by fupfin

fupfin

ㅋㅋ 전혀계획없이살고있다는… 08.12.01 19:22

별다방 오늘의 커피，콜롬비아 나리뇨 수프리모. 낮게 깔린 오후 햇살이 내 마음 깊숙한 곳，진짜 내가 있는 음습한 그곳까지 따사로움을 전하려는 것 같다. by fupfin

Erica

눈에 익은 플래너.ㅋㅋ 08.12.01 18:03

별다방 오늘의 커피，콜롬비아 나리뇨 수프리모. 낮게 깔린 오후 햇살이 내 마음 깊숙한 곳，진짜 내가 있는 음습한 그곳까지 따사로움을 전하려는 것 같다. by fupfin

fupfin

핵심은 좋은 멸치를 사야 한다는 거... 맛없는 멸치는 먹어도 아무 맛도 안나요. 08.12.01 12:14

방금 아들과 제가 좋아하는 멸치 수육을 먹었습니다. (멸치 수육 = 다시 국물 내고 건져낸 멸치) by fupfin

쑤짱

비리진 않았나용? ㅋㅋ 08.12.01 09:26

방금 아들과 제가 좋아하는 멸치 수육을 먹었습니다. (멸치 수육 = 다시 국물 내고 건져낸 멸치) by fupfin

권순선

음... 저는 어쩌다 들어가 있는 것도 건져내고 안먹는데... ==3=3 08.12.01 00:16

방금 아들과 제가 좋아하는 멸치 수육을 먹었습니다. (멸치 수육 = 다시 국물 내고 건져낸 멸치) by fupfin

fupfin

윤지원 님 : 어여 가정을 꾸리시...;;; 소내기 : 많이 컸어. ㅋㅋ 08.12.01 00:12

방금 아들과 제가 좋아하는 멸치 수육을 먹었습니다. (멸치 수육 = 다시 국물 내고 건져낸 멸치) by fupfin

fupfin

Erica 나는 왜 건져내는지 모르겠어. 그 맛있는 멸치 수육을... -_- 08.12.01 00:12

방금 아들과 제가 좋아하는 멸치 수육을 먹었습니다. (멸치 수육 = 다시 국물 내고 건져낸 멸치) by fupfin

소내기

한결이 본지 무지 오래됐네요~ 08.11.30 23:55

방금 아들과 제가 좋아하는 멸치 수육을 먹었습니다. (멸치 수육 = 다시 국물 내고 건져낸 멸치) by fupfin

지원

아, 부럽습니당. :) 08.11.30 23:28

방금 아들과 제가 좋아하는 멸치 수육을 먹었습니다. (멸치 수육 = 다시 국물 내고 건져낸 멸치) by fupfin

Erica

그건 보통 건져내지않나요? 08.11.30 19:10

방금 아들과 제가 좋아하는 멸치 수육을 먹었습니다. (멸치 수육 = 다시 국물 내고 건져낸 멸치) by fupfin

blue

gEEkInsIdE 그...그..게... 08.11.30 18:13

음 하! by 도트

fupfin

때로 내 내면의 변화가 그들의 음악을 따라 갔다는 느낌도 듭니다. 08.11.29 20:23

네이버 100대 명반 리뷰 : 시인과 촌장 [숲] - 젊은 시절, 시인과 촌장은 위로였고 쉼이었고 회복이었습니다. by fupfin

fupfin

맞습니다. 모든 것은 종합적이어야 하겠죠. 다만 수시로 변경되는 것과 성장하는 것은 구별이 되어야 한다고 생각합니다. 08.11.29 14:35

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

아시모프

^^; 링크하신 글에 대해 별다른 이견은 없고요. 재사용성에 관해서는 조금 이견이 있습니다. 논점을 나눠야할듯한데, 1.서서히 만들어지는 것이 더 낫다 2. 실무자가 만드는것이좋다. 에서 제가 애초 말하고자 했던 부분은 1에 관한 이야기였습니다. framework의 정책은 개발중 수시로 변경될수 있는 부분이 아니기 때문에, top down의 접근도 필요하다는 생각입니다. 08.11.29 14:04

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

fupfin

결국 실무를 하는 사람들이 객체지향 기술을 더욱 익혀 프레임워크로 발전시키는 것이 좋은 프레임워크를 만드는 바른 방향이라는 생각, 즉 강조점은 '객체지향 원리'에 있었던 ... ㅎㅎ 08.11.29 13:55

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

fupfin

참고로 제가 가지고 있는 프레임워크에 대한 생각은 이 글 을 참고해주시고요. 이 글을 쓴 취지가 좋은 프레임워크는 실무를 반영해야 한다는 것이므로 토비님의 이 글 이 제가 말하고 싶은 내용이라고 보시면 될 듯 합니다. 08.11.29 13:47

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

fupfin

저는 framework의 재사용성이라고 하면 컴포넌트 코드의 재사용이 아닌 workflow의 재사용이라고 생각합니다. 흔히 말하듯 template method pattern의 확장된 형태가 framework이라는 거죠. 08.11.29 13:43

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

fupfin

(필요 이상으로) 논란이 되었던 글의 답글이군요. ^^ 개인적으로 프레임워크에서 재사용을 다루어야 하는 것인지는 의문입니다. 예를 들어 스트럿츠는 action의 재사용성을 고려하고 만들었습니다. 하지만 action의 재사용성이 프레임워크에서 지원해야 할 문제일까요? 저는 언어 차원에서 OOP적인 기법으로 충분히 재사용을 할 수 있다고 봅니다. 08.11.29 13:42

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

아시모프

아참 위의 처음덧글에서 말하는 coding rule은 제블로그 글(덧글포함)에서 말하는 코드를 강제한다는 의미로서 말한것입니다. 08.11.29 12:41

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

아시모프

제가 알고 있는 framework 의 이해입니다. 예를들어 struts를 보더라도 validation의 대한 exception처리라든지 action간의 이동들은 framework의 규약에 종속되어 있습니다.(물론 커스텀도 가능하지만 말이죠..) 08.11.29 12:38

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

fupfin

써니 님 : 아이고 뭘 문의까지... 공개된 것이니 마음 껏... ^^ 08.11.29 12:32

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

fupfin

아시모프 님 : 아마 framework이라는 단어에 대한 이해가 저랑 약간 다른 듯 합니다. 저는 말씀하신 것들을 framework이 아닌 개발 표준으로 분류해서 다룹니다. 08.11.29 12:29

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

아시모프

framework의 다른측면 재사용성 이외의 project policy(exception, coding rule.etc) 적인 부분에 대해선 어떻게 생각하시나요? 08.11.29 08:41

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

선이

이 글 지금 고민하고 있는 주제에 대한 뚜렷한 해답. 그리고 토론~ 인용해도 될런지 문의 중… 08.11.29 01:05

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

선이

첫 댓글에 무례가 될런지 모르겠습니디만, 이 토론을 제가 작성하는 PPT 자료에 인용해도 될까요? 자료는 웹 공개용입니다만... ^^; 08.11.29 01:03

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

비스무스

희망을 품고 질르며 즐겁게 살아요 ^^ 08.11.28 15:37

사람의 마음 속에는 무엇이 있는가? 사람에게 주어지지 않은 것은 무엇인가? 사람은 무엇으로 사는가? - 종종 어릴 때 읽었던 동화에서 삶의 돌파구를 발견하곤 한다. 걱정은 즐~ 이미 우리 속에 있는 사랑을 붙잡고 살면 되는 거. by fupfin

쑤짱

희망을 품고 로또를 사며 즐겁게 살아요 ^^ 08.11.28 14:47

사람의 마음 속에는 무엇이 있는가? 사람에게 주어지지 않은 것은 무엇인가? 사람은 무엇으로 사는가? - 종종 어릴 때 읽었던 동화에서 삶의 돌파구를 발견하곤 한다. 걱정은 즐~ 이미 우리 속에 있는 사랑을 붙잡고 살면 되는 거. by fupfin

dawnsea

편법이긴 하지만 이런 방법도 있습니다. 물론 저는 우분투 데탑에 따로 머신 두고 쓴다능 -_-;////——- 그 방법 08.11.28 13:34

역시 개발자들에겐 Unix 기반 OS가 편하다. (Cygwin도 2% 부족해…) by fupfin

fupfin

오스카 님 : Visual Strudio를 한번도 안 써봤는데 다들 최고라고 하더군요. 한번 불법 복사라도 해서 써봐야겠어요. ㅋㅋ 아침놀 님 : 아항. 그런 방법이... 한글이야 뭐... 보조로 쓸 수 밖에 없으니 대~충 08.11.28 13:31

역시 개발자들에겐 Unix 기반 OS가 편하다. (Cygwin도 2% 부족해…) by fupfin

아침놀

cygwin은 로컬에서 sshd 띄워서 돌리면 그나마 좀 쓸만한데 한글 지원이 제대로 안 된다는 문제가..ㅠㅠ 08.11.28 13:24

역시 개발자들에겐 Unix 기반 OS가 편하다. (Cygwin도 2% 부족해…) by fupfin

아침놀

저도 그런 식으로 미투에 말리는 경우가 왕왕... 08.11.28 13:24

커널이 업데이트 돼서 리붓하려고 프로그램들 죽이다가 잠깐 미투 본다고 들어온게 한 시간 지났… by fupfin

fupfin

감사합니다. 잠시 눌렸나봐요. ^^ 08.11.28 13:22

그래 인생에 정답이 어디 있겠냐. 자신을 가두지 말고 주어지는 순간에 최선을 다하자. by fupfin

사진찍는프로그래머

요즘 글들이 많이 무겁네요 .. 힘내시고 나아지시길 ^^; 08.11.28 13:15

그래 인생에 정답이 어디 있겠냐. 자신을 가두지 말고 주어지는 순간에 최선을 다하자. by fupfin

오스카

전 리눅스 기반 서버 어플 개발할 때도 Windows 에서 개발했다는;;; Visual Studio 킹왕짱! ㅋㅋ 08.11.28 10:12

역시 개발자들에겐 Unix 기반 OS가 편하다. (Cygwin도 2% 부족해…) by fupfin

소내기

시그윈 몽땅 설치했는데 안써요--; 08.11.28 09:44

역시 개발자들에겐 Unix 기반 OS가 편하다. (Cygwin도 2% 부족해…) by fupfin

K-Dog

시그윈은 엉망진창 절름발이라고 생각ㅋㅋㅋ bash find grep vim cut echo od 손에 너무 익어서.. 08.11.28 09:22

역시 개발자들에겐 Unix 기반 OS가 편하다. (Cygwin도 2% 부족해…) by fupfin

K-Dog

역시 UNIX 기반 OS 개발자들에겐 UNIX 기반 OS가 편해요 08.11.28 09:20

역시 개발자들에겐 Unix 기반 OS가 편하다. (Cygwin도 2% 부족해…) by fupfin

fupfin

아침놀 : 오호 그렇군요. ORM 쪽만 잠깐 살펴 보았었는데... 애석하게도 Python을 사용할 기회가 없군요. 08.11.28 01:41

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

fupfin

아침놀 님 : 물론이죠. 일단 들어가면! (다 죽었어!) 08.11.28 01:28

대부분 인터넷 회사들의 채용 사이트는 IE 전용. 다음 빼고… (귀찮은데 확 거부해버릴까 보다. 아직 배가 불렀어 -_-); by fupfin

아침놀

그러면 '내가 들어가서 바꾸겠다'라는 생각으로 접근하심은;; 08.11.28 01:13

대부분 인터넷 회사들의 채용 사이트는 IE 전용. 다음 빼고… (귀찮은데 확 거부해버릴까 보다. 아직 배가 불렀어 -_-); by fupfin

아침놀

그래서 Django가 좋은 듯합니다;; 실제로 웹사이트 개발하다가 짜던 것을 그대로 프레임웍화한 경우라고 하니... 08.11.28 01:12

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

setq~♡

반복되는 일은 다른 사람을 시키세요. (일자리 창출) 08.11.27 16:04

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

praxis

그와는 별도로 프레임워크가 커버하는 영역을 잘 이해하고 있으려면 세번정도 같으나 다른일들을 삽질해본 사람이 아니면, 제대로된 프레임워크가 안나온다능.. 08.11.27 15:49

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

praxis

프레임워크라는게 보통 같은일을 세번정도 할 노력이 드는일이라 세번 넘게 할일이 아니면 투자대 효용가치가 없더군요. 08.11.27 15:48

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

fupfin

dawnsea 님 : 그죠? 현실에 맞지도 않는 블랙 박스를 가지고 와서 쓰라고 하니... 소내기 : 일단 업무에 집중하다보면 영감이 떠오를 때가 있을거여. 08.11.27 14:26

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

소내기

그 적임자중에 끼고 싶은데, 잘 안되네용~ 08.11.27 13:44

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

dawnsea

바틈업과 탑다운이 상위 1/3지점쯤에서-_-? 만나는 게 좋겠죵. 근데 보통 PT로 박스만 그리던 분들께서 탑다운 프렛셔~를;; 하는 경향이 있지 않나여 ㅋㅋ 08.11.27 12:58

프레임워크는 일부러 작정하고 만드는 것 보다 실무에서 반복되는 부분을 객체지향 원리를 사용해 모듈화하는 과정에서 서서히 만들어지는 것이 더 낫다고 생각한다. 그런 면에서 실무자가 프레임워크를 가장 잘 만들 수 있는 적임자 아니겠나? by fupfin

fupfin

잘 모르니까 이렇게 말이 많은거죠. 구현하다보면 길을 잃고 뱅뱅 도는 일이 일상다반사에요. -_- 08.11.27 00:31

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

스폰지박

아~ 나는 말한마디 섞지도 못하능구나…..(저는 설계보다는 구현에 중점을…..실은 구현하기도 바쁘다능 캬캬캬) [ 글보러가기 ] 08.11.26 23:58

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

praxis

멋지시군요. 다 자바를 사랑하기에 하시는 고민인듯.. 자바의 문제는 자바를 사용하는 대부분이 자바를 사랑하지 않는다는데 있지 않겠습니까? 08.11.26 23:45

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

Tolchi

gEEkInsIdE 님 규화보전은 모두를 고자로 만들어 버릴뿐이잖아요.... 08.11.26 21:44

비전이 없으면 망합니다. ( Proverbs 29:18, KJV ) by ucandoit

fupfin

ucandoit 님 : 예 낮잠 좀 자보도록 하겠습니다. ㅋㅋ 08.11.26 17:21

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

fupfin

아 항! DByC가 그거…(바보 아냐. -_-) 솔직히 Duck Type의 단점을 DByC(바로 써먹..)로 해결하는 것은 너무 무거운 느낌이고 dynamic type, static type, DByC 모두를 제공하는 것이 좋지 않을까? Scala의 compund type도 실용적인 것 같고… 08.11.26 17:21

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

소내기

전 제가 뭘 배포해서 남들이 가져다 쓴적이 없어서. --; 08.11.26 14:35

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

소내기

DByC DesingByContract 인가보네요. 08.11.26 14:34

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

ucandoit

JAVA, 잡아, 자 봐... 08.11.26 13:53

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

fupfin

Strong Type을 Design by contract라고 하기에는 좀 그렇지 않나? ㅎㅎ 그런데 DByC는 뭐여? 08.11.26 13:43

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

fupfin

내가 문제 삼는 것은 너무 '많은 변화'가 아닌 어떤 변화(단순한 메소드 추가)도 허용하지 않는 경직성이고 만약 계약 때문이었다면 interface 선언할 때에 final 같은 지시자를 두도록 하는 방법을 쓸 수 있었다고 생각해. 그리고 설계를 뒤로 미루는 Agile과 자바가 친해지기 어렵게 만드는 이유가 되기도 하고... 08.11.26 13:30

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

맹수

계약과 인터페이스 08.11.26 13:30

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

맹수

그런데 별도 지시어라고 하니까 DesignByContract가 생각 나는 군요.. DuckType에 DByC을 부치는게 이득일까요? StrongType이 더 이득일까요? 08.11.26 13:28

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

맹수

해서요... 그리고 사실 그런 프레임워크나 라이브러리의 API의 변화는 자바이든지 루비이든지. deprecated 하는 정책 말고 본적이 없어서요. (..) 08.11.26 13:27

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

맹수

대규모로 설계해 본적은 없지만.. 결국 변화를 줄때 변하지는 않는 축을 결정하고 그 축 중심으로 변화하라.라는 객채마법사들의 주문들이니까. 명시적으로 프로토콜을 만들든지. 덕타입으로 각각 책임을 할당하듯. 또 다형성 확득의 차원에서 계약 자체의 변화에 너무 많은 기능도 좀 아니지 않을까. . 08.11.26 13:22

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

fupfin

그냥 내가 만드는 프로그램 내에서라면 문제가 없지. 그런데 프레임워크나 기타 API를 만드는 경우라면 내가 만든 모듈을 누가 얼마나 쓰고 있는지 알 수 없는 상황이 되고 인터페이스 변경으로 하위 호환성이 안되는 일이 생겨 버리는 것이 문제. 08.11.26 13:19

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

맹수

Subinterfaces은 여러개 되는 군요. 흠. 08.11.26 13:14

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

맹수

솔직히 다시 컴파일 하는게 왜 문제인지 모르겠어요. 객체처럼 작은 단위들 안해서 굳이 그런 재컴파일 없는 동적인 부분이 필요한지. 08.11.26 13:12

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

fupfin

맹수 : 너무 다양한 언어를 하다보니 혼돈이 오고 있는 거야. -_-; 08.11.26 13:11

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

fupfin

OSGI 같은 것을 사용해서 버전 관리를 한다고 해도 Interface가 변경되면 다시 컴파일 해야 하는 문제는 여전히 존재. SOAP, REST 같은 비 Java 기술을 사용해서 컴포넌트끼리 연동하지 않는 한 Interface 문제는 계속 남을 수 밖에 없지 않을까? 08.11.26 13:10

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

맹수

이제 슬슬 기억이 안나는데.. 인터페이스끼리는 mixin 혹은 다중상속등이 안되나요? --; 08.11.26 13:08

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

맹수

사실 버젼의 문제라면 인터페이스의 문제라고 하기 보다는 모듈이나 컨포넌트에서 하는게 맞지 않나 싶은데요. 펄이나 루비처럼 모듈에 버젼기능을 추가한다거나. 08.11.26 13:04

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

fupfin

자바의 경우 프레임워크 클래스에 메소드가 추가 되었다고 해도 그 클래스를 가져다 쓰는 놈은 다시 컴파일 할 필요 없이 그냥 바이너리 상태에서 돌릴 수 있는데 인터페이스의 경우는 인터페이스에 어떤 변형(단순한 확장)만 있어도 다시 컴파일 해야만 하거든요. 어떤 특별한 기술 문제가 아니라 언어의 특성일 뿐이에요. (물론 제가 이해 못하는 언어학적인 이유가 있을지도 모르겠지만... -_-);' 08.11.26 12:51

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

오리왕

ㅋㅋㅋ 그런데 확장까지 가능한 어떤 새로운 방법이 있다면, 어떤 것일까요? 흠, 그건 programming langauge 개발자가 알아서 할 일인가.. 08.11.26 12:46

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

fupfin

하긴 자바 처음 설계할 때에 누가 인터페이스가 이렇게 성공할 줄 알았겠어. 08.11.26 12:06

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

fupfin

오리대마왕 님 : 다시 읽어보니 제가 좀 오해하게 썼네요. ㅎㅎ 죄송... 08.11.26 12:03

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

fupfin

켄트백의 구현 패턴에 보면 version interface pattern이 있는데 이 것이 이런 자바의 제한 때문에 생긴 패턴이죠. 그런데 다른 언어에서는 인터페이스를 써본 적이 없어서 어떤지 모르겠네요. 08.11.26 12:02

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

오리왕

아, "확장"에 국한해서 말씀하시는 것이라면 그렇겠네요. 전 "확장"이라는 표현을 "확장" 해서 "변경" 까지 언급하시는 것으로 잘못 이해했습니다. ^^ 08.11.26 12:01

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

fupfin

메소->메소드 입니다. (또 오타... -_-); 08.11.26 12:00

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

fupfin

오리대마왕 : 그게 메소를 변경하는 문제라면 말씀이 맞는데요. 단순히 몇가지 메소드를 추가하는 것 조차 안되니 말이죠. 저 글에서도 이런 특성 때문에 interface 대신 추상 클래스가 유용한 경우도 있다고 하네요. 켄트백의 구현패턴에서도 같은 얘기가 있고요. 하지만 추상 클래스는 다중 상속 문제 때문에 한계가...;;; 08.11.26 11:59

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

오리왕

일단 publish 된 interface 의 경우 변경하지 않는 것이 cilent 의 상호 연동을 보장하기 위한 방안이라고 생각합니다. 확장이야 모르겠지만, interface가 변경되어 버리면 그에 의존하던 기존 코드들은 다 동작을 못하겠죠. 감마옹도 그래서 일부러 2,3을 붙이더라도 기존것을 유지하려고 애쓴 것이 아닐까요 08.11.26 11:58

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

fupfin

맹수 : 이클립스 맹글면서 그러고 있다잖아. 언어가 이러니 저러니 투덜 거리는 것도 사실 바보 같은 짓이기는 하지. 솔직히 난 아직도 internal과 public도 구별 못하는 수준인데... 08.11.26 11:57

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

오리왕

전 반대로 생각했습니다. 정의된 interface를 변경하지 않는 것은 사용하는 측을 배려하기 위함으로 보입니다. 제가 해석하기로 본문 중 2,3 으로 숫자가 붙은 것은 원래 interface 쓰는 client module이 안심하고 사용하기 위함이지, 언어적 한계때문에 우회한 방법이라고 보이진 않네요. 08.11.26 11:56

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

맹수

오호 에릭감마가 어디서 그러고 있어요? +_+ 설마 1,2 안 부치고 One,Two...;;; 08.11.26 11:43

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

fupfin

에릭감마 같은 초고수가 인터페이스 이름 뒤에 1,2 숫자나 붙이고 있을 수 밖에 없는 상황이라니... 08.11.26 11:37

자바가 다중 상속을 못하게 한 것은 동의하는 편이지만 인터페이스를 확장 불가능하게 만든 것은 이해가 안 된다. "인터페이스를 많이 쓰도록 해. 그런데 인터페이스는 변경하면 안 되는 것 알지?" 사람 놀리냐? - 계약 때문이라면 별도 지시어를 만들 수도 있었다. by fupfin

쑤짱

흑! 가슴찡! 또 함께 할날이 왔으면 좋겠어요 ^^ 08.11.26 11:18

말처럼 우리가 다시 모이는 것 은 어려울지도 몰라. 그래도 난 우리가 같이 일했던 것이 너무 자랑스럽고 행복했어. 내가 최고가 아닌 것처럼 우리 중 누구도 최고는 아니었지만, 같이 있으면 든든했고 서로 생각을 나누며 함께 성장할 수 있었던 그것이 좋았어. by fupfin

fupfin

계도 : 예. 행운이었지요. 08.11.26 08:56

말처럼 우리가 다시 모이는 것 은 어려울지도 몰라. 그래도 난 우리가 같이 일했던 것이 너무 자랑스럽고 행복했어. 내가 최고가 아닌 것처럼 우리 중 누구도 최고는 아니었지만, 같이 있으면 든든했고 서로 생각을 나누며 함께 성장할 수 있었던 그것이 좋았어. by fupfin

gyedo

좋은 동료들과 일하셨었군요. 08.11.26 02:53

말처럼 우리가 다시 모이는 것 은 어려울지도 몰라. 그래도 난 우리가 같이 일했던 것이 너무 자랑스럽고 행복했어. 내가 최고가 아닌 것처럼 우리 중 누구도 최고는 아니었지만, 같이 있으면 든든했고 서로 생각을 나누며 함께 성장할 수 있었던 그것이 좋았어. by fupfin

맹수

gEEkInsIdE 흑흑. 말씀만이라도 송구스럽습니다.. (....) 08.11.26 00:57

사회적 평판.나는 크게 생각하지 않는다.옆에 함께 일하는 사람에게는 민감한데.함께 고생하는 사람들에게 피해를 줄까봐. 소심해지는 거. by 맹수

fupfin

말처럼 우리가 다시 모이는 것은 어려울지도 몰라. 그래도 난 우리가 같이 일했던 것이 너무 자랑스럽고 행복했어. 내가 최고가 아닌 것처럼 우리 중 누구도 최고는 아니었지만, 같이 있으면 든든했고 서로 생각을 나누며 함께 성장할 수 있었던 그것이 좋았어. 08.11.26 00:47

이력서 작성을 했는데 '제출' 버튼 누르기 무섭다. 누가 나 아는 사람이 좀 데리고 가서 잘 써먹어 줬으면 좋겠는데… (같이 일하자는 제안 다 거부해 놓고 무슨 소리 -_-); by fupfin

fupfin

모야. 우리 gen129 만드는 거야? ㅎㅎ 08.11.25 18:57

이력서 작성을 했는데 '제출' 버튼 누르기 무섭다. 누가 나 아는 사람이 좀 데리고 가서 잘 써먹어 줬으면 좋겠는데… (같이 일하자는 제안 다 거부해 놓고 무슨 소리 -_-); by fupfin

fupfin

친구들과