공식이라고 보기는 좀. 아무튼 개념적으로는 랄프 존슨의 논문에서 찾을 수 있죠.

냠냠 evolving?

논리적 비약으로 보는 점이 뭔지부터 좀 말씀해주시죠.

Ralph E. Johnson, “FRAMEWORKS=(COMPONENTS+PATTERNS)”, Communications of the ACM, Vol. 40, No. 10, 1997

냠냠 디자인 패턴을 활용했을 수는 있어도 디자인 패턴 자체가 목적은 아니지 않나?

냠냠 메일로...;;

냠냠 구했 -_-)v

fupfin 앗. 보내드리려 했는데.

fupfin 저도 좀 읽어볼 수 있을까요?

fupfin 프레임워크에 내장된 디자인 패턴의 재사용(적용)이 목적의 하나죠. 왜 아닌가요?

냠냠 푸하하하하하!

fupfin "A framework is a set of classes that embodies an abstract design for solutions to a family of related problems"

냠냠 "=" 기호가 목적의 하나라는 의미는 아니지 않나?

fupfin 이건 IoC를 처음 소개한 Ralph Johnson의 86년 논문에서.

냠냠 문서 좀 읽고 얘기하자긍... (언제 읽을지 모르겠지만)

냠냠 목적이냐고 물어본 건 형이죠. =는 구성을 나타낸 것이죠.

냠냠 몰라몰라! 일단 읽고... 단문 대화로 너무 깊이 들어가면 꼬인다고...

fupfin 블로그나 포럼에 길게 써주시면 길게 답해드리죠. (언제 쓸지는 모르겠지만)

냠냠 일단 읽고 나도 어느 정도 기초 지식이 생긴 다음에 더 진전시키자는 얘기지...

fupfin "To me a framework is a way of thinking about a particular family of problems, and code to back it up" Kent Beck

우억- 용어의 연이은 등장 _φ(･_･

냠냠 응응 그 웁슬라의 패널 토의는 읽었는데...

브라이트아름 왜 읽으셨어요. ㅠㅠ

fupfin 그렇다면, 프레임워크가 두가지로 구성된다는 것은 인정하시는 것인가요? 단지 a way of thinking.. problems나 abstract design... related problems를 디자인 패턴으로 간단하게 설명하는 건 비약이라는 것인가요?

냠냠 결국 그렇게 되는 건가? 디자인 패턴을 사용해서 문제를 해결하지만 디자인 패턴 자체라고 보기엔 공백이나 건너 뛴 단계가 있다는 느낌?

fupfin 프레임워크와 패턴에 대한 건, 형이 감동적이라고 한, 이터너티님의 http://aeternum.egloos.com/2630624 시리즈를 보시죠.

fupfin 그리고 아무도 프레임워크는 디자인 패턴 자체라고 안했는데요. 저 공식은 매우 느슨하게 정의된 것이지만, 공식의 의도 자체는 프레임워크는 디자인 패턴만도 아니고 라이브러리만도 아니라는 거죠.

냠냠 일단 애초에 랄프 존슨의 공식과 저 공식이 같은 의미인지 의심스러운데 한번 확인해봐야겠어

fupfin 어떻게 다른 의미인지 한번 설명해주세요.

냠냠 확인해보고 (지금 회의 중이라...)

대화 재밌어요. 저도 통상 컴포넌트와 프레임워크를 저렇게 분리해서 설명합니다.

냠냠 랄프존슨이 말하는 패턴이 디자인 패턴을 말하는가가 관건인 건데... 회의가 오후까지 연장 됐...;;

난 이 공식(프레임워크 = 디자인 패턴 + 라이브러리)을 보는 순간, 아! 그럴듯한데?라고 생각했는데; 아닌가요? =_=a