Onionmixer: 검수 20180724

2018-07-24T09:22:21Z

검수 20180724

← Older revision		Revision as of 09:22, 24 July 2018
Line 122:		Line 122:
	\|-		\|-
	\| style="text-align:right;width:40px;float:left;" \| 제인:		\| style="text-align:right;width:40px;float:left;" \| 제인:
	\| 꼭 그렇지만도 않아. 내가 패턴을 선택하는 과정이 전혀 과학적이지 않다는 건 인정하지만 말이야. 지난 번 PLoP(~~Patters~~ Languages of Programs) 학회에서 누군가 한 패턴 전문가에게 어떻게 패턴을 결정했는지 질문하는 걸 우연히 들었거든. 전문가는 "내가 읽었지만 절반은 잊어버린 종이 조각에 대해 생각해보고, ''[디자인 패턴]'' 내부의 맨 앞 양면 페이지를 살피기도 하고, 때로는 추측에 맡겼죠,"라는 말을 했어. 패턴을 읽고 제2의 천성이 될 때까지 충분히 적용해보는 것이 핵심인 것 같아.		\| 꼭 그렇지만도 않아. 내가 패턴을 선택하는 과정이 전혀 과학적이지 않다는 건 인정하지만 말이야. 지난 번 PLoP(Patterns Languages of Programs) 학회에서 누군가 한 패턴 전문가에게 어떻게 패턴을 결정했는지 질문하는 걸 우연히 들었거든. 전문가는 "내가 읽었지만 절반은 잊어버린 종이 조각에 대해 생각해보고, ''[디자인 패턴]'' 내부의 맨 앞 양면 페이지를 살피기도 하고, 때로는 추측에 맡겼죠,"라는 말을 했어. 패턴을 읽고 제2의 천성이 될 때까지 충분히 적용해보는 것이 핵심인 것 같아.
	\|-		\|-
	\| style="text-align:right;width:40px;float:left;" \| 돈:		\| style="text-align:right;width:40px;float:left;" \| 돈:
Line 139:		Line 139:
	\| 좋았어! 한 번 읽어볼게. ''[제인의 칸막이 사무실을 급히 뛰어나가며 책을 흔든다]''		\| 좋았어! 한 번 읽어볼게. ''[제인의 칸막이 사무실을 급히 뛰어나가며 책을 흔든다]''
	\|}		\|}



	[[Category:DesignPatternSmalltalkCompanion]]		[[Category:DesignPatternSmalltalkCompanion]]

Onionmixer: 대화부분에 table적용

2013-01-20T04:58:52Z

대화부분에 table적용

Show changes

Onionmixer: DPSC 2.2장면2:원칙은깨어져선안된다 페이지 추가

2012-07-27T06:41:08Z

DPSC 2.2장면2:원칙은깨어져선안된다 페이지 추가

New page

===2.2 장면 2: 원칙은 깨어져선 안 된다.===

''[며칠 후, 돈은 까다로운 설계 문제로 인해 제인에게 도움을 요청한다.]''

돈⊗ 제인, 시간 있어?

제인⊗ 물론. 무슨 일이야?

돈⊗ 또 다른 설계 문제가 생겨서 말이야, 네가 좀 도와줄 수 있을까 해서.

제인⊗ 물론이지.

돈⊗ 심사 과정이 어떻게 작동할지에 대해 몇 가지 측면을 알아보려고 해. Claim이 어떻게 수락되어 지급되는지와 어떻게 거부되는지에 대해서 말이야.

제인⊗ 응, 지난번에 네가 설명해줬던 기억이 나.

돈⊗ 내 문제는 바로 이거야. 보상금을 청구하는 방법으로 이렇게 내려오거든. 요구문서에서 설명하는 원칙들이 서로 달라서 말이야. 어떻게 나타낼지 모르겠어.

제인⊗ 요구문서 좀 보여줄래? ''[돈이 문서를 건네주고 다음 단락을 함께 읽는다]''

* 정책은 보장되는 항목의 목록으로 구성되어 있고, 각 항목과 관련된 지급원칙도 함께 있 다. 지급에는 몇 가지 원칙이 있다:
* 특정 항목에서는 절차와 관련해 전혀 보상하지 않는다 (예: 보상 거부).
* 특정 항목에서는 균일한 달러 금액을 지급한다 (예: 123.4 절차의 경우 $25를 지불한다).
* 특정 항목에서는 해당하는 비용 중 일정 비율만 지급한다 (예: 234.5 절차의 경우 병원비의 50%를 지급한다).

그리고 지급원칙이 두 가지가 더 있어.

* 손절매 원칙(Stop-loss rule)은 개별 항목에 지급되는 최대금액을 조절한다 (예: 비용의 70% 또는 $500 중 적은 금액을 지급한다).
* 쿼리기반의 원칙(Query-based rule)은 청구인의 속성을 기반으로 한다 (예: 청구인이 여성일 경우 본 절차에 $200를 지급하고; 그 외에는 $150를 지급한다).

돈⊗ 어떻게든 이런 절차 코드를 서로 다른 원칙에 맞출 수는 있었어. 하지만 각 원칙은 사용자가 결정한단 말이지! 원칙을 Policy로 코드화할 수 있으면 좋겠지만, 문제는 사용자가 어떤 원칙을 원할 것인지 미리 아는 방법이 없다는 거야.

제인⊗ 내가 보기엔 각각의 “원칙”들이 보상 전략(Strategy)으로 들리는데?

돈⊗ 그렇게 말하니 흥미로운데? 무슨 의미지?

제인⊗ Strategy는 또 다른 패턴이야. Strategy 패턴의 의도를 읽어줄게 ''[디자인 패턴 서적에 다가가 책을 펼친 후 다음 문장을 읽는다]'' : "알고리즘 군을 정의하고, 각각의 알고리즘을 별도의 클래스로 캡슐화하여 상호 교환이 가능하게 만든다. Strategy 패턴은 이를 사용하는 클라이언트에게 영향을 주지 않고 독립적으로 다양하게 나타난다."

돈⊗ 글쎄, 보상은 알고리즘이 아닌 것 같은데. 그래도 시도는 해보고 싶어. Strategy 패턴이 어떻게 실행되는지 보여줘 봐.

제인⊗ 각각의 원칙을 하나의 전략 객체로 만들 순 없는지 살펴보자. 기본적으로 각 원칙은 한 라인 항목에 대한 총합을 계산하는 것이 맞지?

돈⊗ 맞아.

제인⊗ 그러니까 각각의 객체는 reimbursementFor: aLineItem라고 불리는 메시지를 이해해야만 해. 각 원칙마다 하나의 클래스가 있어. 네가 설명한 첫 번째 원칙이 뭐였지?

돈⊗ “절차와 관련해 전혀 보상하지 않는다.”

제인⊗ 특별한 사례의 경우네. 이 원칙을 reimbursementFor: 로 구현하는 건 쉽겠어: 반환(return) 값이 항상 0이 되니까.

돈⊗ 두 번째는 어때? 균일한 달러 금액을 지급하는 원칙 말이야.

제인⊗ 보상금액을 계속 유지하는 인스턴스 변수가 하나 있을 거야. 그럼 reimbursementFor: 메소드가 그 인스턴스 변수 값을 반환할거야.

돈⊗ 이제 이해가 가기 시작했어. 그럼 “라인 항목에 해당하는 비용 중 일정 비율만 지급”하는 원칙은 퍼센트를 저장하고 reimbursementFor: 메소드가 라인 항목의 비용에 퍼센트를 곱한 결과를 반환하겠지?

제인⊗ 맞아. 3개의 클래스 계층구조는 이렇게 되겠지.

[[image:dpsc_2.2_01.png]]

제인⊗ Claim은 특정 절차 코드에 어떤 원칙을 적용할 것인지 찾아본 후에 그 절차에 맞는 원칙을 적용할 필요가 있어.

돈⊗ 나쁘지 않은 걸! 문제 일부는 해결됐네. 그럼 다음 건 어때? 손절매 원칙은 앞서 말한 두 원칙처럼 작동하질 않아. 다른 원칙 하나를 먼저 실행한 후에 그 결과를 바탕으로 상환금액을 결정해야 할 것 같은데.

제인⊗ 네가 뭔가 중요한 걸 발견한 것 같은데. 한번 찾아볼게 ''[디자인 패턴 서적을 들고 책을 넘기기 시작한다]''. 여기 새로운 행위를 추가하기 위해 런타임에서 객체의 행위를 변경하는 방법을 알려주는 패턴이 있어. 아, 찾았다! Decorator 패턴이야 ''[책을 넘겨 177페이지에 실린 다이어그램을 돈에게 보여준다]''. 이 다이어그램에서 어떻게 Decorator가 기존 객체가 아닌 다른 객체의 인스턴스를 포함시키면서 기존 객체와 동일한 인터페이스를 구현하는지 이해하겠어? 네 문제도 비슷하게 해결하면 될 것 같아.

돈⊗ 또 헷갈리네. 기존 객체는 뭐고 다른 객체는 뭐야?

제인⊗ 구체적으로 말해줄게. StopLossStrategy라 불리는 다른 원칙이 있다고 가정하고, 그 안에 다른 Strategy가 포함되어 있다고 쳐. 그럼 이 원칙은 원칙에 포함된 Strategy 로 메시지를 전송(forwarding)한 다음 그 결과가 손절매 금액을 초과하는지 확인함으로써 reimbursementFor: 메소드를 구현하는 거야.

돈⊗ ''[망설이며]'' 네가 무슨 말을 하는지 알 것 같아. 이런 모양이 되겠다는 말이지? ''[제인의 그림을 가져와 새로운 클래스를 추가한다]''.

[[image:dpsc_2.2_02.png]]

제인⊗ 맞아.

돈⊗ 그럼 이 디자인 패턴이란 건 정말 효과적인걸! 하나의 설계에 하나 이상의 패턴을 통합했잖아. 앞에서 네가 설명한 방법대로라면 독자적으로 작동할 줄 알았거든.

제인⊗ 항상 그런건 아냐. 디자인 패턴은 하나만 사용할 수 있지만 대개는 하나의 설계에 몇 가지 패턴이 함께 사용되는 걸 볼 수 있을 거야. 함께 자주 사용되는 특정한 패턴들이 있어. ''[디자인 패턴]''의 각 패턴 마지막 부분에 “관련 패턴”이라는 절에서 열거하고 있어.

돈⊗ 저자들이 그걸 생각해 냈다니 다행이야. 하지만 어떤 패턴을 적용할 것인지는 어떻게 알지? 넌 그냥 임의로 뽑은 것 같아서 말이야.

제인⊗ 꼭 그렇지만도 않아. 내가 패턴을 선택하는 과정이 전혀 과학적이지 않다는 건 인정하지만 말이야. 지난 번 PLoP(Patters Languages of Programs) 학회에서 누군가 한 패턴 전문가에게 어떻게 패턴을 결정했는지 질문하는 걸 우연히 들었거든. 전문가는 “내가 읽었지만 절반은 잊어버린 종이 조각에 대해 생각해보고, ''[디자인 패턴]'' 내부의 맨 앞 양면 페이지를 살피기도 하고, 때로는 추측에 맡겼죠,”라는 말을 했어. 패턴을 읽고 제2의 천성이 될 때까지 충분히 적용해보는 것이 핵심인 것 같아.

돈⊗ 그렇구나. 패턴에 관해 실제로 읽을 필요가 있는 것 같아.

제인⊗ 정말 많이 배울 수 있을 거야. 내 책을 빌려갈래? ''[책을 돈에게 건네준다]''.

돈⊗ 당연하지. ''[그는 책을 받는다]''. 가서 이 설계를 문서화 시켜야겠어. 그건 그렇고 쿼리기반의 원칙에 대해서는 해줄 말 있어?

제인⊗ 글쎄, 런타임 쿼리를 처리하는 Interpreter 패턴을 이용할 수 있지. ''[디자인 패턴]'' 243페이지를 찾아 봐.

돈⊗ 좋았어! 한 번 읽어볼게. ''[제인의 칸막이 사무실을 급히 뛰어나가며 책을 흔든다]''
[[Category:DesignPatternSmalltalkCompanion]]

DesignPatternSmalltalkCompanion:2.2 - Revision history

Onionmixer: 검수 20180724

Onionmixer: 대화부분에 table적용

Onionmixer: DPSC 2.2장면2:원칙은깨어져선안된다 페이지 추가