BLOG main image
분류 전체보기 (344)
NWC Consulting (1)
서비스 (173)
출판 (169)
일반 (0)
195,318 Visitors up to today!
Today 34 hit, Yesterday 86 hit
daisy rss
'HFDP세미나'에 해당되는 글 22건
2009.04.27 22:12
저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2009.04.26 09:41

두 번째 세미나 후에
비도 오고, 시간도 늦은 탓인지 세미나 참석자는 신청자의 절반도 되지 않았습니다.
간식으로 사온 와플은 떡처럼 되어, 분위기에 한 몫 했습니다. 
세미나 내용의 주요 내용 중 하나인 상태머신에 대한 설명도 그리 만족스럽지 못했습니다. 

좋지 못한 환경에도 불구하고, 참석해주시고,
열심히 상태 다이어그램을 그려주신 참석자들에게 감사드립니다.
다음에 더 나은 모습으로 만나길 소망합니다.

이후 세미나에서는 좀 더 일찍 시작할 수 있도록 시간을 조정하려고 합니다.


첫 번째 세미나 후에
거의 10년 만에 불특정 다수 앞에서 세미나를 했습니다.
세미나 참석하시는 모든 분들에게 세미나 참석에 대한 보람을 느끼게 해드리고 싶었습니다.
세미나에서 잘한 것도 있고, 못한 것도 있을 것입니다.
잘한 것은 칭찬해 주고, 못한 것은 앞으로의 발전을 위해 건설적인 제안을 해주시기를 바랍니다.

20명 중에 2명만 빠지고 18명이 참여했습니다. 참석하지 못한 분들은 뵙질 못해서 아쉬웠습니다.
어찌보면 어렵고 지루한 주제인데도 불구하고, 열정적으로 세미나를 들어주셨습니다.
오늘 세미나 참석해 주신 분들에게 감사드립니다.

새로운 만남, 긴장도 되고 설레기도 합니다.
모임 안에서 더 많은 사람들이 만나고, 더 좋은 인연들을 맺기를 소망합니다.


이균환씨가 세미나 마지막 부분에서 인터페이스와 추상클래스의 차이에 대해서 질문하셨는데,
세미나 시간이 넘어 최대한 설명은 드렸으나 깊이 있는 설명은 되지 못한 듯 합니다.
이 부분은 매우 중요한 부분입니다.
그냥 넘어가기 힘든 부분이니 다음 세미나 시간에 연관의 일반화와 더불어 심도 있게 논의해 보도록 하겠습니다.


세미나 참석시의 모습들을 담은 사진은 참석자들의 허락을 받고, 올리도록 하겠습니다.

다시 한번 세미나 참석해 주신 분들에게 감사드립니다.

신고
[짱가™] | 2009.04.19 13:15 신고 | PERMALINK | EDIT/DEL | REPLY
수고 많이 하셨습니다.
고민을 많이 하신 흔적이 보여서 좋았습니다.
Arawn | 2009.04.19 22:48 신고 | PERMALINK | EDIT/DEL | REPLY
좋은 시간이었습니다.
흔하게 접하지 못한 표현으로 풀이해주셔서 여러모로 다른 방향에서 생각을
해 볼 수 있는 길을 찾은 것 같습니다.
다음 주에도 잘 부탁드립니다.
홀리아이 | 2009.04.19 22:52 신고 | PERMALINK | EDIT/DEL | REPLY
대리라는 개념이 신선해서 좋았습니다.
iDeeds | 2009.04.19 23:46 신고 | PERMALINK | EDIT/DEL | REPLY
첫번째 세미나를 늦은 시간까지 열정적인 강의를 해주셔서 감사합니다.
두번째 세미나도 큰 기대가 됩니다.
기쁨의 한 주 보내시고 두번째 세미나에서 뵙겠습니다.
항상 하나님과 함께 하시길 기도합니다.^^
타고난용기 | 2009.04.20 08:51 신고 | PERMALINK | EDIT/DEL | REPLY
그날 일이 있어서 가지말까 하다가 늦게나마 참석 했는데
안갔으면 크게 후회 할뻔 했습니다.
저희 부스 옆에 노트북으로 작업하시는 분이 인원 관리 하시는 분인줄 알고
"서명 해야 되나요?" 라고 말했는데... 지금 생각하니 뻘줌 하네요. ㅠㅠ
다음주에도 기대 하겠습니다. ^^
이성민 | 2009.04.20 09:37 신고 | PERMALINK | EDIT/DEL | REPLY
세미나 내용은 정말 좋았습니다....
신선하기도 했지만.. 무엇보다... 지금까지 제가 보던 책에 없는 내용이었습니다..

김현남님의 세미나는 처음들은 것이었는데도...
오랜경험을 통해서 나온 내용이라는것과.. 그동안 쭉~ 사용해오시던,
실전에서 지금도사용되고 있는 내용이라는것이 느껴졌습니다.. ^^;;
이번한주 공부열심히해서 다음세미나 더욱 많은것을 느낄수있었으면 합니다..ㅎㅎ
엄성권 | 2009.04.20 10:54 신고 | PERMALINK | EDIT/DEL | REPLY
확신할수 없지만.. 뭔가 새로운 생각을 할수 있었습니다.
다음시간에도 꼭 뵙겠습니다.
tommy | 2009.04.20 11:28 신고 | PERMALINK | EDIT/DEL | REPLY
이번에 뵙지 못한 2인중 한명입니다.--;
기대 많이 했던 세미나인데..아쉽습니다.
다음 세미나도 못 갈 가능성이 많네요. 시간이 8시인 점이 희망적이긴 합니다만..
어쨌든 계속 끈을 놓지 않고 있을 생각입니다.^^
다음시간에 뵙길..
노익현 | 2009.04.20 11:52 신고 | PERMALINK | EDIT/DEL | REPLY
토요일 세미나 수고하셨습니다.
세미나에서 신선했던것은 "할일 = 역할 = 인터페이스" 그리고 "대리를 통한 생각"이었습니다. 준비를 많이하셔서 잘 풀어가시려고 노력하셨던것들이 느껴졌습니다.
모두에 구미를 맞춰줄수는 없겠지만.. 전달하고자 하는 핵심만 잘 설명해 주신다면 세미나를 찾아오시는분들이 하나라도 더 얻어가는것이 아닌가 싶습니다.
다음주에도 김현남님의 특유의 표현법및 설명으로 멋진 세미나 부탁드립니다.
박승진 | 2009.04.20 12:26 신고 | PERMALINK | EDIT/DEL | REPLY
느꼈던점은 책으로 읽었던 내용을 다시 듣고 그것을 정리하고 한번 더 접해 볼 수 있어서 좋았고요. 대리라는 새로운 개념에 대해서 들어서 신선했습니다. 또 자동화 된 툴을 만든다는 것도 좋았습니다.
아쉬운 점은 들으면서 질문할 거리가 있었는데 강의의 흐름을 방해하는 것 같아서 또 소극적인 성격 때문에 열심히 질문하지 못한 점이 좀 아쉬움으로 남았습니다.
발전방향이라... 이 세미나가 끝나고 다른 곳에서 만났을 때 약간이라도 아는 척하는 분이 한분이라도 더 생기길 바라고요. 이번 세미나를 들으면서 적용하고 싶은 패턴이 생겼는데.. 실천을 해 봤으면 하는 것이.. 저의 바램이죠.. 세미나 자체에 대한 발전 방향은 아직은 없네요.. ㅎㅎ
Justine | 2009.04.20 14:05 신고 | PERMALINK | EDIT/DEL | REPLY
참석자들의 배경을 잘 모르는 상황에서 주제를 선택하다 보니, 세미나 진행에 있어 설명이 좀 어렵고, 지루했을 수도 있습니다. 좀 덥기도 했고, 제 발표기술이나 목소리가 썩 좋지 않은 점도 일조를 했겠죠.

질책보다는 칭찬을 해 주시니 힘이 나네요. 앞으로 칭찬에 약해지지 않고, 비판에 강한 사람이 되기로 했는데. 역시 칭찬에 약해지네요.

좋은 의견들 주셔서 감사합니다.
김양원 | 2009.04.20 14:14 신고 | PERMALINK | EDIT/DEL | REPLY
어디서도 듣지 못할(?) 대리 개념의 접근법에 대해서 좋은 경험을 하게 되었습니다.
디자인 패턴의 개념과 경험의 접근이 아닌 근본적인 원리로써 접근할 수 있는 방법을 배운 매우 중요한 시간이였던 것 같습니다.

다음 세미나가 기대됩니다. ^^
이우석 | 2009.04.20 18:46 신고 | PERMALINK | EDIT/DEL | REPLY
첫번째 세미나가 있던 당일날 밀린 일 처리를 해야되서 출근을 하느라 아쉽게도 참석을 못했습니다.
PT를 보구서 기존과는 다른 접근이다라고 느껴었는데 그 느낌을 세미나 장소로 쭉 이어가지 못한 부분이 아쉽네요.
이번 주는 업무 스케쥴 조절을 잘해서 첫번재 시간때 놓친 경험과 공유의 시간을 꼭 갖고 싶습니다.
이균환 | 2009.04.21 16:19 신고 | PERMALINK | EDIT/DEL | REPLY
제 이름이 떡하니 나와서 깜짝 놀랬습니다. (-- )( --)
대리를 통한 프로세스의 정의, 역할론의 인터페이스 내용등 생각해볼 만한 꺼리를 주셔서 좋은 강의였던것 같습니다.
아직 내공이 부족해 말씀하시는 것을 그대로 척척 알아듣지 못하지만 꾸준히 노력토록 하겠습니다.
수고하셨습니다. ^^
김상은 | 2009.04.22 01:03 신고 | PERMALINK | EDIT/DEL | REPLY
"대리를 통해 자신만의 자동화 도구를 만들라!!"
패턴에 대한 접근방법을 새로운 시선으로 바라 볼 수있는 유익한 시간이었습니다.
한편으론 귀찮니즘이 강한 사람이 더 훌륭한 도구를 만들수 있겠다 란 생각도 해봅니다.
저의 가치를 더 높일 수 있게 노력해야겠습니다. 감사합니다.
백승우 | 2009.04.22 09:21 신고 | PERMALINK | EDIT/DEL | REPLY
늦게 답변을 올리네요..^^
수고하셨습니다.

이번주 기대하겠습니다.
임재욱 | 2009.04.22 19:20 신고 | PERMALINK | EDIT/DEL | REPLY
강의 후에 임대리가 되자라는 말을 머리 속에 새겼습니다..ㅋㅋㅋ

마지막 시장에서의 자신의 상품가치에 대한 것과
IT업계 종사자들의 현실과의 불합치성의 딜레마를 다시 한 번 새겨볼 수 있어서 좋은 시간이 된 것 같습니다...
수고하셨습니다..꾸벅~
Name
Password
Homepage
Secret
2009.04.25 11:50
통합본입니다.





오늘 세미나는 8시부터입니다.
착각하실 분들도 있을 거 같네요. 일찍 오신 분들은 뭐, 기다리면서 공부를...  

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2009.04.23 23:48

이 장에서는 앞에서 다루었던 패턴보다 덜 인기 있는 패턴들을 다룹니다.
Bridge, Builder, Chain of Responsibility, Flyweight, Interpreter, Mediator, Memento, Prototype, Visitor

근데 개수가 너무 많네요. 이걸 다 간단하게 다루고 넘어가도 되는지 확신이 서지 않네요. 

Interpreter는 어떤 언어에 대한 간단한 인터프리터를 만들때만 필요한 것이니 넘어간다고 치고.
다른 패턴들은?
여기서 언급되는 패턴들은 사용되는 범위가 좁고, 장점 만큼 단점도 많은 것들 같습니다. 그래서 사용하기가 조심스럽지요. 특히 Bridge, Chain of Responsibility, Visitor는 설계를 복잡하게 만들고, 설계된 내용을 이해하기 어렵게 합니다.


1. Bridge
브리지 패턴은 추상팩토리와 더불어 디자인 패턴 학습자들이 이해하기 어려워 하는 패턴 중 하나입니다.
생긴 것도 추상팩토리와 닮아 있습니다.

브리지는 추상도 바뀌고 구체도 자주 바뀔 때 사용합니다.
추상이 자주 바뀐다는 것은 프로젝트 단위에서는 잘 일어나지 않습니다.
최소한 다수의 버전이 동시에 사용되는 제품이 있을 때 추상이 바뀔 가능성이 있습니다.

p651의 RemoteControl과 TV와 그 사이에 연관이 브리지를 형성합니다. 다리처럼 보이나요?

2. Builder
빌더는 생성 절차가 여러 단계로 나누어질 만큼 복잡한 경우 사용됩니다. 구체적인 생성 절차도, 단계의 구체적인 방법도 달라질 수 있습니다.

3. Chain of Responsibility
자꾸 책임을 역할로 번역하고 있어 눈에 거슬리네요.

여러 종류의 처리해야 할 일들이 있고, 처리해야 할 일의 종류에 따라 담당자들이 있는데, 누가 그 일을 담당하는지를 감추고 싶을 때 사용합니다. 누가 그 일을 담당하는지를 감춘다는 것은 담당자가 바뀔 수 있다는 것을 의미합니다. 

이 패턴은 필터를 생각하면 이해가 쉬울 수도 있습니다. 구조는 단일 연결 리스트입니다. 

4. Flyweight
특별한 인스턴스들이 정해져있고, 이것들에 대한 표현 방법이 다양한 경우에 사용됩니다.
예를 들어, 알파벳이라는 것은 인스턴스가 정해져있습니다. 더 늘어나거나 줄어들지 않습니다. 그런데 이것들이 화면에 보일 때는 다양하게 보일 수 있습니다.

5. Mediator
이것은 패턴이라기 보다는 컬레보레이션에 대한 설계라고 봐야 합니다.
컬레보레이션이라는 것이 객체들의 협력에 대한 것으로 객체들의 협력을 제어하기 위해 중앙집중형 구조가 됩니다.

6. Mementor
이전 상태로 복구해야 할 때 사용합니다. 
이름은 멋있는데, 취급을 제대로 받지 못하고 있네요.

7. Prototype
인스턴스를 새로 생성하는 것이 아니라 복사하고 싶을 때 사용합니다.
근데, 왜 복사를 해서 할까요?
객체가 현재 상태를 갖기까지 드린 노력이 클 경우, 다시 처음 부터 생성해서 여기까지 도달하게 하고 싶지 않다는 것이죠. 그냥 복사해서 사용하겠다는 것입니다.

8. Visitor
추가되는 기능이 복잡한 구조를 갖는 대상들에 대한 것일 때 사용합니다. 
기능의 구현은 대상들을 방문해서 처리합니다. 
어떻게 방문하도록 할 것인지는 Traverser가 압니다. 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2009.04.23 23:12
컴파운드 패턴은 아키텍처 패턴이라고 불립니다.

저는 패턴 학습은 아키텍처 패턴에서 부터 시작하는 것이 더 좋다고 생각합니다. 
디자인 패턴에서 부터 시작하면 13장에서 이야기했던 것과 같이 오용될 가능성이 높습니다.
디자인 패턴이, 왜 어디에 사용해야 하는지는 아키텍처 수준에서 등장하기 때문입니다.


1. p554 패턴의 필요성을 드러내는 단어들이 있습니다.
이런 단어들을 전체적으로 정리해 놓는다면 많은 도움이 될 것 같습니다.
옵저버의 경우, '실시간으로, 추적, 감시, 관찰' 등의 단어가 등장합니다. 

2. p555 Observable이라는 구체 클래스를 만들고 있는데  
Observable은 역할의 이름으로 구체 클래스 이름으로 그냥 사용하는 것은 적당하지 않습니다.
역할 이름에 대해서는 세미나에서 인터페이스와 추상클래스에 대해서 설명할 때 같이 설명하도록 합니다.

3. p569 설명을 기억해 둡니다.
1. 사용자는 뷰하고만 접촉할 수 있습니다.
뷰는 모델을 보여주는 창이라고 할 수 있습니다. 뷰에 대해서 뭔가를 하면 뷰에서 컨트롤러한테 사용자가 어떤 일을 했는지 알려줍니다. 그러면 컨트롤러가 상황에 맞게 작업을 처리합니다.
2. 컨트롤러는 모델이 해야 할 일을 요청합니다.
컨트롤러에서는 사용자의 행동을 받아서 해석합니다. 사용자가 버튼을 클릭하면 컨트롤러에서 그것이 무엇을 의미하는지 해석하고, 그 행동에 따라서 모델을 어떤 식으로 조작해야 하는지 결정합니다.
3. 컨트롤러에서 뷰를 변경해달라고 요청할 수 있습니다.
컨트롤러에서 뷰로부터 어떤 행동을 받았을 때, 그 행동의 결과로 뷰를 바꿔달라고 할 수 있습니다. 예를 들어, 컨트롤러에서 인터페이스에 있는 어떤 버튼이나 메뉴를 활성화 또는 비활성화 시킬 수 있습니다.
4. 상태가 변경되면 모델에서 뷰한테 그 사실을 알립니다.
사용자가 한 행동 때문이든 다른 내부적인 변화 때문이든, 모델에서 뭔가가 바뀌면 모델에서 뷰한테 상태가 변경되었음을 알립니다.
5. 뷰에서 모델한테 상태를 요청합니다.
뷰에서 화면에 표시할 상태는 모델로부터 직접 가져옵니다. 예를 들어, 모델에서 뷰한테 새로운 곡이 재생되기 시작했다고 알려주면 뷰에서는 모델한테 곡 제목을 요청하고, 그것을 받아서 화면에 표시합니다. 컨트롤러에서 뷰를 바꾸라는 요청을 했을 때도 뷰에서 모델한테 상태를 알려달라고 요청할 수도 있습니다.


4. p569 컨트롤러의 필요성에 대해서 묻는 질문
기업용 소프트웨어의 경우, 요청은 사용자 인터페이스에서 메뉴나 버튼으로 작성됩니다. 분명한 요청의 단위가 정해져 있습니다. 이런 경우, 컨트롤러는 사용자의 행동을 받아서 해석할 필요가 없습니다. 이미 사용자 인터페이스에 요청하는 것이 무엇인지가 명확하게 정해졌기 때문입니다.
컨트롤러는 그래픽 시스템을 예로 들면, 이해하기가 쉽습니다. 그래픽 시스템에서는 사용자의 행동을 받아서 이전 상태를 기반으로 해석을 해야 합니다. 예를 들어, 사용자가 Canvas 상에 마우스를 눌렀는데, 그래픽 객체가 있는 곳을 선택하였고, 그 후에 마우스를 이동한다면 그래픽 객체를 이동해야 합니다. 그런데 그래픽 객체가 없는 것을 선택하고, 마우스를 이동한다면 그것은 러버밴딩을 해야 합니다.


저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2009.04.20 19:48
프록시 패턴은 간단한데, 이 장에서 제시되는 예제들의 구현이 복잡합니다. 세부적인 구현에 관심이 없다면 구현 부분은 뛰어 버리세요.


간단히 집고 넘어갑시다.
1. p498 프록시 패턴은
어떤 객체에 다른 객체들이 직접 접근하지 못하도록 해야 할 때 사용합니다.

2. p509 질문들
이 책에서 나오는 질문들을 자세히 보면, "이 패턴이 저 패턴하고 비슷한 거 같은데요?"라는 질문이 자주 등장함을 알 수 있습니다.
사실 디자인 패턴들은 클래스 다이어그램만 보면 다 비슷비슷해 보입니다. 사실 클래스 다이어그램에 작성되는 관계라는 것이 몇 개 안되거든요. 그 중에 디자인 패턴은 실현이라는 관계, 즉 역할과 역할 수행이라는 부분에 초점을 강하게 맞추고 있지요.

언제 사용되는지를 명확히 구분해야 이런 질문들이 안나옵니다.


과제 입니다. 
1. 대리가 나옵니다. 이 대리하고 세미나때 설명했던 대리하고는 성격이 쫌~ 다르죠.
대리도 나오고 했으니, 프록시 패턴 설계를 대리해봅시다.

안건국씨가 마지막 세미나실 나오면서 질문을 했습니다.
Decorator 패턴 설계 대리에서 설명이 좀 상세하지 않은 부분이었던 것 같습니다. 프록시 패턴 설계를 대리하려면 알아야 할 것 같아서 설명합니다.

아래는 대리를 구성한 것입니다.
Adaptor 설계(다르게 표현된 역할, 역할을 수행할 대상)
{
1. 다음과 같이 어댑터 이름을 작성한다.
역할을 수행할 대상 +To + 다르게 표현된 역할 + Adaptor
2. 다르게 표현된 역할을 인터페이스로, 어댑터를 클래스로
해서 실현을 작성한다.
3. 어댑터에서 역할을 수행할 대상 방향으로 연관을 작성한
다.
}

아래는 구성된 대리가 올바로 돌아가는지를 확인하기 위해 실제 값들을 사용해서 시뮬레이션 해 본 것입니다.
Adaptor 설계(Duck, Turkey)
{
1. TurkeyToDuckAdaptor
2. 실현(Duck, TurkeyToDuckAdaptor)
3. 연관(TurkeyToDuckAdaptor, Turkey)
}

질문은 위에서 2번 단계와 3번 단계에 대한 것이었습니다.
2번의 실현과 3번의 연관은 패턴 대리자가 갖는 기본 행위로 정의되어 있다고 가정했습니다.
실제로 어떻게 하느냐가 이전 슬라이드에서 빠르게 설명하고 넘어가서 이 부분을 놓친 분들이 있을 것 같습니다.
어떻게 하는지를 설명하면,
실현은 첫 번째 인자를 인터페이스로, 두 번째 인자를 클래스로 작성하는 것으로 정의되어 있겠지요. 
2번에서는 Duck을 인터페이스로 TurkeyToDuckAdaptor를 클래스로 해서 실현 관계를 작성합니다.
연관은 첫 번째 인자를 source(출발)로 두번째 인자를 target(도착)으로 해서 연관 관계를 작성합니다.
3번에서 TurkeyToDuckAdaptor에서 Turkey 쪽으로 연관 관계를 작성합니다.



신고
Name
Password
Homepage
Secret
2009.04.20 18:35

상태 머신은 상태 다이어그램에 작성되며, 복잡한 반응형 시스템을 모델링하는데 중요하게 다루어집니다.
상태 머신에 대한 설명은 간단하게 언급하고 넘어가기에는 좀 많은 이야기를 해야 합니다.


간단히 집고 넘어갑시다.
1. p424
전문가이고 비전문가이고 상태 다이어그램을 제대로 그리는 사람들을 아직까지 만나보지 못했습니다.
역시나 이 책에서도 그렇네요. 물론 예제는 예제니까 오해하지는 않겠습니다.
여기의 예가 지금까지와는 조금 다르다는 것을 느꼈나요? 뽑기 기계를 동작시키는 임베디드 시스템입니다. 뽑기 기계가 반응형 시스템입니다.

세미나에서 이 예제를 가지고 상태 다이어그램을 작성해보도록 하겠습니다.

2. p450 4번째 질문 '스테이트 패턴을 사용하면 디자인에'로 시작하는 질문
if나 switch를 가지고 구현하는 것에 비하면, 스테이트 패턴은 복잡한 상태기반의 반응형 시스템을 구현하는 매우 훌륭한 방법입니다. 하지만 더 나은 방법일 뿐이지 원칙적인 방법은 아닙니다.
이런 방법으로는 복합상태를 갖는 계층형 상태머신을 처리하기에는 한계가 있습니다. 
아래 링크를 참조하세요. 상태머신에 대한 직접적인 구현으로 참조할 만한 최고의 자료가 있습니다. 
http://www.quantum-leaps.com

신고
Name
Password
Homepage
Secret
2009.04.18 16:00

이 장에서는 패턴을 처음 익히거나, 패턴에 푹 빠져있을 때 꼭 들어야 하는 조언들을 들려줍니다.

1. p620. force

영화 스타워즈에 의하면 포스란 "우주를 형성하고 제어하는 것"이라고 합니다. 패턴의 정의에서 포스란 해결책을 형성하고 제어하는 것인 셈이죠. 해결책이 포스의 양면(밝은 면이라고 할 수 있는 목적과 어두운 면이라고 할 수 있는 제약조건) 사이에서 균형을 이룰 수 있어야 비로소 제대로 된 패턴이 만들어지는 것입니다.

이 비유도 멋지네요. 그런데 그리 와 닿지는 않는군요.
저는 force를 원동력에 비유합니다. force는 해결책을 결정 짓는 원동력입니다.
해결책을 선택하는 데 결정적인 영향을 줄 수 있는 힘입니다.  
써 놓고 보니, 그게 그거 같기도 하네요.

2. p632 - 633

패턴으로 생각한다는 건 무엇을 뜻할까요? 어떤 디자인을 봤을 때 패턴을 적용할지 여부를 결정할 수 있는 안목을 가지는 것을 뜻합니다.

언제 패턴을 적용할지를 올바르게 결정하려면 상당한 경험과 지식이 축적되어야 합니다.

 

리팩토링의 목적은 행동을 변경하는 것이 아니라 구조를 개선하는 데 있습니다.

 패턴과 리팩토링이 어떻게 관계 되는지를 한 문장으로 정리했네요.


3. p639. 명심하세요.

너무 오버하지 말고 항상 단순한 해결책을 찾아 보세요. 패턴을 쓰지 않는 간단한 해결책이 있다면 그 방법을 써야 합니다. 


 

신고
Name
Password
Homepage
Secret
2009.04.18 08:52
HFDP 1차 세미나(20090418) 발표자료입니다.


대리라는 조금은 생소한 개념을 사용해서 디자인 패턴을 이해하고, 확장하는 데 기반을 갖추는 것을 목표로 합니다. 


책 내용 비평한 것은 출력하시는 분들을 위해 pdf 파일로 작성했습니다. 내용은 9장까지 정리한 내용을 그대로 복사한 것입니다.
신고
이성민 | 2009.04.20 15:05 신고 | PERMALINK | EDIT/DEL | REPLY
잘보겠습니다~ ^^
Name
Password
Homepage
Secret
2009.04.15 18:01
책 내용만 보았을 때는 그리 어렵지 않게 학습할 수 있을 것 같습니다.
이 장에서는 구현 부분에 좀 난이도가 있는 것들이 있으니 그 부분만 좀 신경쓰면 되겠습니다.  


간단히 집고 넘어갑시다.


1. p360 '그럼 이제 어떻게 할까요?'에서, 참 민감한 내용이 나오네요.
이런 경우 참 난감하죠. 특히 조직에서 비슷한 위치에 있는 사람들이 힘겨루기할 때는 정말 불필요한 논쟁의 시간이 요구됩니다. 좀 더 낫게 고치자는 건데, 고치는 쪽에서는 그것을 잘못으로 받아들입니다. 자기가 잘못했으니 고쳐야 한다고 생각하는거죠.
저는 고칠 것은 그때 바로 고치는 것이 좋다고 생각합니다. 안 고치고 뭘 하려고 머리쓰다보면 나중에 더 힘들어지는 경우가 많습니다. 

힘겨루기보다 먼저 고쳐주는 넓은 아량을 갖춘 개발자들이 많아 졌으면 좋겠습니다. 사실 논쟁을 하는 시간이면 고치고도 남는 경우가 많거든요.

2. p376 네 번째 질문과 답에서 갑자기 책가방이 튀어나오네요.
컬렉션은 중복과 순서를 고려하느냐에 따라 좀 더 구체화됩니다.
그 중에서 중복을 허용하고, 순서도 고려하지 않아도 되는 컬렉션을 bag이라고 합니다.

3. p377 Single Responsibility
왜 클래스가 하나의 책임만을 갖도록 설계되어야 할까요?
뭔가를 하려면 그것을 할 수 있는 구조를 갖춰야 합니다. 이왕이면 최적의 구조를 갖도록 해야겠지요.
최적의 구조를 갖도록 하려면 구조를 이루는 구성요소가 적어야 합니다. 그래야 '이것을 이렇게 하면 저것이 문제고, 저것을 이렇게 하면 이것이 문제고'와 같이 이것 저것 다 따져볼 수 있지요.
구조를 이루는 구성요소가 많다면, 우리 머리의 한계를 넘어가는 경우가 생기겠지요.
클래스는 자기가 할 일에 적합한 구조를 갖아야 합니다. 그 구조를 유지하면서 다른 애들이 할 수 있는 일까지 떠 맡을 수 있다면 떠 맡아도 됩니다. 하지만 그 일을 하기 위해서 추가적인 구조가 요구된다면 떠 맡아서는 안됩니다.

우리는 가끔 만능을 원합니다. 동일한 구조를 갖고 있는데 더 많은 일을 할 수 있기를 원합니다.
물론 보통 사람과 같은 구조라면 슈퍼맨이 더 나을 것입니다. 하지만 슈퍼맨과 같은 능력은 그만한 구조를 갖춰야 하는데 모든 능력에 맞도록 구조를 짠다면 아마도 괴물덩어리가 나올 겁니다. 고치지도 못하는.

슈퍼맨을 만들려고 하다가 괴물덩어리를 만들기 보다 슈퍼맨이 할 수 있는 일을 나누어서 할 수 있도록 하는 것이 우리 인간의 능력을 고려해볼 때 더 성공적일 것입니다.

근데, 구조를 갖지 않는 경우는 어떨까요? 객체지향 프로그래밍을 한다면 이런 의문이 들 것 같습니다.
메소드만 있는 클래스의 경우입니다. 사실 이 경우는 구조적인 효율성 문제는 없지만 관리의 문제가 생깁니다. 뭘 하나 바꾸려면 어디에 있는지 찾아야 하는데 찾는 비용이 만만치 않습니다. 볼 필요가 없는 것들도 보이고요. 집중력을 확 떨어뜨리지요.
이 정도 관리 문제를 감수하겠다면, 굳이 그러지 말라고 하지는 못하겠네요. 사실 구조를 갖지 않는다면 책임을 메소드로 잘 나누고, 공통부분들에 대해서 계층적으로 잘 나누면 됩니다. 함수라이브러리 형태가 되는거지요. 

다음과 같은 디자인 원칙이 나오죠.
클래스를 바꾸는 이유는 한 가지 뿐이어야 한다.

그리고 사이드에 이런 이야기도 나옵니다.
이 원칙에 따라 한 클래스에서는 한 가지 책임만 맡도록 해야 합니다.

역자는 responsibility를 역할 또는 역할을 맡는으로 번역하고 있습니다. 그래서 책임으로 바꾸었습니다.
책임이 역할을 맡는다는 뜻으로 풀이 될 수 있지만, 이 페이지의 내용에서는 역할이 책임보다 더 오해를 일으킬 수 있는 용어라고 생각합니다.  

변경이유를 생각할 때 'iterate 하는 방법'이 바뀌었을 때, 'collecting하는 방법'이 바뀌었을 때와 같이 한 덩어리 이유로 생각해야 합니다. 이유나 역할이라는 것이 작은 것도 있고 큰 것도 있으니까요.
저는 위에서 한 가지 이유나 한 가지 역할을 이야기 할 때는 객체의 존재목적에 해당하는 존재역할이라는 용어를 사용합니다.


생각해 볼 문제들

1. p405
실체는 전체와 부분의 구조를 갖습니다. 컴포지트 패턴은 패턴이라기 보다는 실체 개념을 설명한 것 뿐입니다.


신고
Name
Password
Homepage
Secret
prev"" #1 #2 #3 next

티스토리 툴바