1.1. Aha! ¶
Before launching into our descriptions of specific design patterns, we present a case study of sorts, involving multiple patterns. In the Design Pattern preface, the Gang of Four speak about moving from a "Huh?" to an "Aha!" experience with regard to understanding design patterns. We present here a little drama portraying such a transition. It consists of three vignettes: three days in the life of two Smalltalk programmers who work for MegaCorp Insurance Company. We are listening in on conversations between Don (an object newbie, but an experienced business analyst) and Jane (an object and pattern expert). Don comes to Jane with his design problems, and they solve them together. Although the characters are fictitious, the designs are real and have all been part of actual systems written in Smalltalk. Our goal is to demonstrate how, by careful analysis, design patterns can help derive solutions to real-world problems.
(μ€κ°μ€κ° ꡬλΌμ κ°κΉμ΄ μμμ΄λΌλ. --;;;)
λμμΈ ν¨ν΄μ λν ꡬ체μ μΈ μ€λͺ
μ λ€μ΄κ°κΈ° μ μ μ°λ¦¬λ λ€μν ν¨ν΄λ€μ΄ ν¬ν¨λ κ²λ€μ λν μμλ€μ 보μ¬μ€λ€. λμμΈ ν¨ν΄ μλ¬Έμμ GoFλ λμμΈ ν¨ν΄μ μ΄ν΄νκ² λλ©΄μ "Huh?" μμ "Aha!" λ‘ λ°λλ κ²½νμ λν΄ μ΄μΌκΈ°νλ€. μ°λ¦¬λ μ¬κΈ° μμ λ¨λ§κ·Ήμ 보μ¬μ€ κ²μ΄λ€. κ·Έκ²μ 3κ°μ μμ μ΄μΌκΈ°λ‘ ꡬμ±λμ΄μλ€ : MegaCorpλΌλ 보ννμ¬μμ μΌνλ λλͺ
μ Smalltalk νλ‘κ·Έλλ¨Έμ 3μΌμ μ΄μΌκΈ°μ΄λ€. μ°λ¦¬λ Don κ³Ό(OOPμ λν΄μλ μ΄λ³΄μ§λ§ κ²½νμλ μ¬μ
λΆμκ°) Jane (OOPμ Pattern μ λ¬Έκ°)μ λνλ΄μ©μ λ£κ³ μλ€. Don μ κ·Έμ λ¬Έμ λ₯Ό Janeμκ² κ°μ Έμ€κ³ , κ·Έλ€μ κ°μ΄ κ·Έ λ¬Έμ λ₯Ό ν΄κ²°νλ€. λΉλ‘ μ¬κΈ°μ μΈλ¬Όλ€μ νꡬμ κ²μ΄μ§λ§, design μ μ€μ μ κ²μ΄κ³ , Smalltalkλ‘ μ°μ¬μ§ μ€μ μ μμ€ν
μ€ μΌλΆμ΄λ€. μ°λ¦¬μ λͺ©νλ μ΄λ»κ² design patternμ΄ μ€μ μΈκ³μ λ¬Έμ λ€μ λν ν΄κ²°μ±
μ κ°μ Έλ€ μ£Όλκ°μ λν΄ μ€λͺ
νλ κ²μ΄λ€.
Chapter 2
Aha!
2.1 Scene One : State of Confusion
Our story begins with a tired-looking Don approaching Jane's cubicle, where Jane sits quietly typing at her keyboard.
μ°λ¦¬μ μ΄μΌκΈ°λ μ§μΉνμ μ μ§μΌλ©° μ μΈμ cubicle (μ.. μ¬λ¬΄μ€μμμ νν°ν΄λ‘ ꡬλΆλ κ³³ μ λμΈλ―. a small room that is made by separating off part of a larger room)λ‘ κ°λ Don κ³Ό ν¨κ» μμνλ€. μ μΈμ μμ μ cubicleμμ μ‘°μ©ν νμ΄ννλ©° μμμλ€.
Our story begins with a tired-looking Don approaching Jane's cubicle, where Jane sits quietly typing at her keyboard.
μ°λ¦¬μ μ΄μΌκΈ°λ μ§μΉνμ μ μ§μΌλ©° μ μΈμ cubicle (μ.. μ¬λ¬΄μ€μμμ νν°ν΄λ‘ ꡬλΆλ κ³³ μ λμΈλ―. a small room that is made by separating off part of a larger room)λ‘ κ°λ Don κ³Ό ν¨κ» μμνλ€. μ μΈμ μμ μ cubicleμμ μ‘°μ©ν νμ΄ννλ©° μμμλ€.
Don : Hey, Jane, could you help me with this problem? I've been looking at this requirements document for days now, and I can't seem to get my mind around it.
Jane~ μ΄ λ¬Έμ μ’ ν΄κ²°ν΄μ£Όμ€λμ? μ€λ νλ£¨μ’ μΌ μ΄ μꡬ문μλ₯Ό μ³λ€λ΄€μ§λ§, λλ¬΄μ§ μμ΄λμ΄κ° μλ μ€λ₯΄λ€μ.
Jane~ μ΄ λ¬Έμ μ’ ν΄κ²°ν΄μ£Όμ€λμ? μ€λ νλ£¨μ’ μΌ μ΄ μꡬ문μλ₯Ό μ³λ€λ΄€μ§λ§, λλ¬΄μ§ μμ΄λμ΄κ° μλ μ€λ₯΄λ€μ.
Jane : That's all right. I don't mind at all. What's the problem?
μ’μμ. μ΄λ€λ¬Έμ μΈκ°μ?
μ’μμ. μ΄λ€λ¬Έμ μΈκ°μ?
Don : It's this claims-processing workflow system I've been asked to design. I just can't see how the objects will work together. I think I've found the basic objects in the system, but I don't understand how to make sense from their behaviors.
μ κ° λμμΈλΆννλ κ²μ λ°λ‘ μ΄ μꡬ-μ§ν μμ νλ¦μμ€ν μ λλ€. (κ·Έλ₯ μμ΄ κ·Έλλ‘ μ¨λ λ κ² κ°μλ°.. λ체ν μ©μ΄κ° μκ°μλλ€. μ, μ΄ν λΈλ €λΌ. --;) μ΄ κ°μ²΄λ€μ΄ μ΄λ»κ² κ°μ§ μμ©ν΄μΌ ν μ§ λͺ¨λ₯΄κ² μ΄μ. μ κ° μκ°νκΈ°λ‘ , μ΄ μμ€ν μμμ κΈ°λ³Έμ μΈ κ°μ²΄λ€μ μ°Ύμ κ² κ°μλ°, κ° κ°μ²΄λ€μ νμλ€μ μ΄λ»κ² μ΄ν΄ν΄μΌ ν μ§ λͺ¨λ₯΄κ² μ΄μ.
μ κ° λμμΈλΆννλ κ²μ λ°λ‘ μ΄ μꡬ-μ§ν μμ νλ¦μμ€ν μ λλ€. (κ·Έλ₯ μμ΄ κ·Έλλ‘ μ¨λ λ κ² κ°μλ°.. λ체ν μ©μ΄κ° μκ°μλλ€. μ, μ΄ν λΈλ €λΌ. --;) μ΄ κ°μ²΄λ€μ΄ μ΄λ»κ² κ°μ§ μμ©ν΄μΌ ν μ§ λͺ¨λ₯΄κ² μ΄μ. μ κ° μκ°νκΈ°λ‘ , μ΄ μμ€ν μμμ κΈ°λ³Έμ μΈ κ°μ²΄λ€μ μ°Ύμ κ² κ°μλ°, κ° κ°μ²΄λ€μ νμλ€μ μ΄λ»κ² μ΄ν΄ν΄μΌ ν μ§ λͺ¨λ₯΄κ² μ΄μ.
Jane : Can you show me what you've done?
Don : Here, let me show you the section of the requirements document I've got the problem with:
μ¬κΈ°μ. μꡬ문μμμ λ¬Έμ μ λΆλΆμ λλ€.
μ¬κΈ°μ. μꡬ문μμμ λ¬Έμ μ λΆλΆμ λλ€.
- Data Entry. This consists of various systems that receive health claims from a variety of different sources. All are logged by assigning a unique identifier. Paper claims and supporting via OCR (optical character recognition) to capture the data associated with each form field.
- Validation. The scanned and entered forms are validated to ensure that the fields are consistent and completely filled in. Incomplete or improperly filled-in forms are rejected by the system and are sent back to the claimant for resubmittal.
- Provider/Plan Match. An automated process attempts to mach the plan (the contract unser which the claim is being paid) and the health care provider (e.g., the doctor) identified on the claim with the providers with which the overall claim processing organization has a contract. If there is no exact match, the program identifies the most likely matches based on soundex technology (an algorithm for finding similar-sounding words). The system displays prospective matches to knowledge workers in order of the likeinhood of the match, who then identify the correct provider.
- Automatic Adjudication. The system determines whether a claim can be paid and how much to pay if and only if there are no inconsistencies between key data items associated with the claim. If there are inconsistencies, the system "pends" the claim for processing by the appropriate claims adjudicator.
- Adjudication of Pended Claims. The adjudicator can access the system for a claim history or a representation of the original claim. The adjudicator either approves the claim for payment, specifying the proper amount to pay, or generates correspondence denying the claim.
Validation. μ€μΊλκ³ μ
λ ₯λμ΄μ§ formλ€μ κ° νλλ€μ λν΄ μΌκ΄μ±λ³΄μ¦κ³Ό λͺ¨λ νΌμ΄ μμ ν μ±μμ‘λμ§μ λν 보μ¦μ μν΄ κ²μ¦μμ
μ κ±°μΉλ€. λΆμμ νκ±°λ μ μ μΉ λͺ»ν μ
λ ₯μ μμ€ν
μ μν΄ rejectλκ³ , μ¬νμΈμ μν΄ μꡬμμκ² λλ‘ λ³΄λ΄μ§λ€.