Design Patterns as a Path to Conceptual Integrity
κ°λ μ μμ μ±μ κ²½λ‘λ‘μμ λμμΈ ν¨ν΄λ€
κ°λ μ μμ μ±μ κ²½λ‘λ‘μμ λμμΈ ν¨ν΄λ€
24 June, 2001
Stan Feighny
Stan Feighny
During our discussions about the organization of design patterns there was a comment about the difficulty of identifying the βgenerative natureβ of design patterns. This may be a good property to identify, for if we understood how design patterns are used in the design process, then their organization may not be far behind. Alexander makes a point that the generative nature of design patterns is one of the key benefits. In practice, on the software side, the generative nature seems to have fallen away and the more common approach for using design patterns is characterized as βwhen faced with problem xyzβ¦the solution isβ¦β One might say in software a more opportunistic application of design patterns is prevalent over a generative use of design patterns.
λμμΈν¨ν΄μ μ‘°μ§μ λν μ°λ¦¬μ ν λ‘ μ€ λμμΈ ν¨ν΄μ 'μμ°μ μΈ μμ±' μ μ μνκΈ° μ΄λ ΅λ€λ μκ²¬μ΄ μμλ€.λ§μΌ μ°λ¦¬κ° μ΄λ»κ² λμμΈ νλ‘μΈμ€μμ λμμΈ ν¨ν΄λ€μ΄ μ΄μ©λλμ§ μ΄ν΄νλ€λ©΄, κ·Έλ¦¬κ³ ν¨ν΄λ€μ μ‘°μ§νκ° λ©λ¦¬ μ¨μ΄μμ§ μλ€λ©΄, μ΄λ μ μλ₯Ό μν μ’μ νλ‘νΌν°κ° λ κ²μ΄λ€. ν¬λ¦¬μ€ν νΌ μλ μ°λ(Alexander) λ λμμΈ ν¨ν΄μ μμ°μ μμ±μ μ΄λμ΄ λλ μμμ€ νλμμ κ°μ‘°νλ€. μννΈμ¨μ΄μ κ΄μ μ μ
무 λ΄μμ μμ°μ μΈ μμ±μ μ€ν¨νκ² μ²λΌ 보μ΄λ©°, λμμΈ ν¨ν΄μ μ΄μ©νλ λ μΌλ°μ μΈ μ κ·Ό λ°©λ²μ λ€μκ³Ό κ°μ μμΌλ‘ λ¬μ¬λλ€. "xyz λ¬Έμ μ λν΄ μ§λ©΄νκ² λμμλ.. ν΄κ²°μ±
μ.." νΉμλ μννΈμ¨μ΄κ³μμ λ λμμΈν¨ν΄μ νΈμμ£Όμμ μΈ μ μ©μ λμμΈν¨ν΄μ μμ±μ μΈ μ΄μ©λ³΄λ€ μ μ©νλ€κ³ λ§ν μ§λ λͺ¨λ₯Έλ€.
The source of this difference may be the lack of focus on design patterns in the design process. In fact, we seldom see discussions of the design process associated with design patterns. It is as though design patterns are a tool that is used independent of the process. Letβs investigate this further:
μ΄λ¬ν μ°¨μ΄μ κ·Όλ³Έμ λμμΈ νλ‘μΈμ€ λ΄μμμ λμμΈ ν¨ν΄μ λν μ΄μ μ λΆμ‘±μΌμ§λ λͺ¨λ₯Έλ€. μ¬μ€μ, μ°λ¦¬λ λμμΈ ν¨ν΄κ³Ό κ΄λ ¨λ λμμΈ νλ‘μΈμ€μ λν ν λ‘ μ κ±°μ λ³΄μ§ λͺ»νλ€. λμμΈν¨ν΄μ νλ‘μΈμ€μ λ
립μ μΌλ‘ μ°μ΄λ λꡬμ²λΌ 보기λ νλ€. μ΄μ λν΄ μ’ λ μ°κ΅¬ν΄λ³΄μ.
A comment from Carriere and Kazman at SEI is interesting: βWhat Makes a Good Object Oriented Design?β
Β· The existence of an architecture, on top of any object/class design
Β· The internal regularity (β¦.or conceptual integrity) of the architectural design
Β· The existence of an architecture, on top of any object/class design
Β· The internal regularity (β¦.or conceptual integrity) of the architectural design
SEI μμμ Carriere μ Kazman μ μ½λ©νΈλ ν₯λ―Έλ‘λ€. "무μμ΄ μ’μ κ°μ²΄μ§ν₯ λμμΈμ λ§λλκ°?"
μ€λΈμ νΈ/ν΄λμ€ λμμΈ μμ μν€ν
μ³μ μ‘΄μ¬
μν€ν μ³ λμμΈμ λ΄λΆμ μ κ·μ±(λλ ConceptualIntegrity)
This is what Brooks wrote 25 years ago. "β¦ Conceptual integrity is the most important consideration in system design."Brooks 86 He continues: βThe dilemma is a cruel one. For efficiency and conceptual integrity, one prefers a few good minds doing design and construction. Yet for large systems one wants a way to bring considerable manpower to bear, so that the product can make a timely appearance. How can these two needs be reconciled?βμν€ν μ³ λμμΈμ λ΄λΆμ μ κ·μ±(λλ ConceptualIntegrity)
μ΄λ Brooks κ° 25λ
μ μ μ΄ λ§μ΄λ€. "ConceptualIntegrity λ μμ€ν
λμμΈμμ κ°μ₯ μ€μν μΌμ΄λ€." κ·Έλ κ³μ λ§νλ€. "μ΄ λλ λ§λ μμΈν κ²μ΄λ€. ν¨μ¨μ±κ³Ό κ°λ
μ μμ μ±μ€ νΉμλ λμμΈκ³Ό ꡬμΆμ νλ κ²μ μ νΈν κ²μ΄λ€. ν° μμ€ν
μ λν΄ νΉμλ μ±
μμ λ§‘μ μ€μν 맨 νμλ₯Ό κ°μ Έμ¬ λ°©λ²μ μν κ²μ΄λ€. κ·Έλμ νλ‘λνΈλ μ μμ μΆνν κ²μ΄λ€. μ΄λ»κ² μ΄ λ νμμμλ€μ΄ μ‘°νλ₯Ό μ΄λ£° κ±°μΈκ°?
One approach would be to identify and elevate a single overriding quality (such as adaptability or isolation of change) and use that quality as a foundation for the design process. If this overriding quality were one of the goals or even a specific design criteria of the process then perhaps the βmanyβ could produce a timely product with the same conceptual integrity as βa few good minds.β How can this be accomplished and the and at least parts of the βcruel dilemmaβ resolved?
νλμ μ΄νλ‘μΉλ μ μ, κ°μ₯ μ΅μ°μ μ μ€μν νΉμ§μ μμΉμν¨λ€. (μ΄λν°λΉλ¦¬ν°λ λ³νμ λν λΆλ¦¬) κ·Έλ¦¬κ³ μ΄ ν리ν°λ€λ€μ λμμΈ νλ‘μΈμ€μ μ€λ¦½μ μ©λλ‘ μ΄μ©ν μ μλ€. λ§μΌ μ΄ μ΅μ°μ μ νΉμ§μ΄ νλ‘μΈμ€μ λͺ©μ μ΄λ ꡬ체μ λμμΈ λΆλ₯μ νλλΌλ©΄ μλ§ 'many'λ κ°μ κ°λ
μ μμ μ±μ "μ½κ°μ μ’μ κ°μ "μΌλ‘μ μ μμ νλ‘λνΈλ₯Ό ..
μ΄λ»κ² μ΄λ₯Ό λ¬μ±ν κ²μ΄λ©°, 'μμΈν λλ λ§' μ μΌλΆλ₯Ό ν΄κ²°ν κ²μΈκ°?
μ΄λ»κ² μ΄λ₯Ό λ¬μ±ν κ²μ΄λ©°, 'μμΈν λλ λ§' μ μΌλΆλ₯Ό ν΄κ²°ν κ²μΈκ°?
The following summary is from βDesign Patterns as a Litmus Paper to Test the Strength of Object-Oriented Methodsβ and may provide some insight:
http://www.econ.kuleuven.ac.be/tew/academic/infosys/Members/Snoeck/litmus2.ps
http://www.econ.kuleuven.ac.be/tew/academic/infosys/Members/Snoeck/litmus2.ps
λ€μμ "κ°μ²΄μ§ν₯ λ©μλλ€μ ν¨κ³Όλ₯Ό ν
μ€νΈνκΈ° μν 리νΈλ¨Έμ€ μ’
μ΄λ‘μμ λμμΈ ν¨ν΄" μΌλ‘λΆν°μ μμ½μ΄λ©°, ν΅μ°°λ ₯μ μ 곡ν΄μ€ κ²μ΄λ€.
1. Some O-O design methodologies provide a systematic process in the form of axiomatic steps for developing architectures or micro-architectures that are optimality partitioned (modularized) according to a specific design criteria.
λͺλͺ O-O λμμΈ λ°©λ²λ‘ λ€μ ꡬ체μ λμμΈ κΈ°μ€μ λ°λΌ μ΅μ μΌλ‘ λλμ΄μ§(λͺ¨λνλμ΄μ§) μν€ν μ³λ λ§μ΄ν¬λ‘-μν€ν μ³λ€μ κ°λ°νλ λͺ νν λ¨κ³μ νΌμμ μμ€ν μ μΈ νλ‘μΈμ€λ₯Ό μ 곡νλ€.
λͺλͺ O-O λμμΈ λ°©λ²λ‘ λ€μ ꡬ체μ λμμΈ κΈ°μ€μ λ°λΌ μ΅μ μΌλ‘ λλμ΄μ§(λͺ¨λνλμ΄μ§) μν€ν μ³λ λ§μ΄ν¬λ‘-μν€ν μ³λ€μ κ°λ°νλ λͺ νν λ¨κ³μ νΌμμ μμ€ν μ μΈ νλ‘μΈμ€λ₯Ό μ 곡νλ€.
2. The following methodologies are listed according to their key design criteria for modularization:
λ€μμ λ°©λ²λ‘ λ€μ λͺ¨λνμ λν κ·Έλ€μ ν€ λμμΈ κΈ°μ€μ λ°λ₯Έ λͺ©λ‘μ΄λ€.
a. Booch in OOSE relies heavily on expert designers and experience to provide the system modularization principle.
OOSE μ Booch λ system modularization principle μ μ 곡νκΈ° μν΄ μ λ¬Έκ° λμμ΄λμ κ²½νμ λ§€μ° μμ‘΄μ μ΄λ€.
λ€μμ λ°©λ²λ‘ λ€μ λͺ¨λνμ λν κ·Έλ€μ ν€ λμμΈ κΈ°μ€μ λ°λ₯Έ λͺ©λ‘μ΄λ€.
a. Booch in OOSE relies heavily on expert designers and experience to provide the system modularization principle.
OOSE μ Booch λ system modularization principle μ μ 곡νκΈ° μν΄ μ λ¬Έκ° λμμ΄λμ κ²½νμ λ§€μ° μμ‘΄μ μ΄λ€.
b. OMT, Coad-Yourdon, Shaer-Mellor are data driven and as such raise data dependency as the system modularization principle.
OMT, Coad-Yourdon, Shaer-Mellor μ κ²½μ° data driven μ΄λ©°, system modularization principle λ‘μ λ°μ΄ν° μμ‘΄μ±μ λ€μλ€.
OMT, Coad-Yourdon, Shaer-Mellor μ κ²½μ° data driven μ΄λ©°, system modularization principle λ‘μ λ°μ΄ν° μμ‘΄μ±μ λ€μλ€.
c. Wirfs-Brock with Responsibility Driven Design (RDD) raises contract minimization as the system modularization principle.
ResponsibilityDrivenDesign μ Wirfs-Brockλ system modularization μ λν΄ κ³μ½ μ΅μνλ₯Ό λ€μλ€.
ResponsibilityDrivenDesign μ Wirfs-Brockλ system modularization μ λν΄ κ³μ½ μ΅μνλ₯Ό λ€μλ€.
d. Snoeck with Event Driven Design (EDD) raises existence dependency as the system modularization principle.
EventDrivenDesign μ Snoeck λ system modularization principle μ λν΄ μμ‘΄μ± μ‘΄μ¬λ₯Ό λ€μλ€.
EventDrivenDesign μ Snoeck λ system modularization principle μ λν΄ μμ‘΄μ± μ‘΄μ¬λ₯Ό λ€μλ€.
3. According to the authors only RDD and EDD have axiomatic rules for OO design and therefore are strong OO design methods.
μ μμ μνλ©΄, μ€μ§ RDD μ EDD κ° OO λμμΈ λν λͺ νν λ£°μ κ°μ§κ³ μμΌλ©° κ·Έλ¬λ―λ‘ μ΄λ€μ μ€λλ ₯μλ OO λμμΈ λ°©λ²λ€μ΄λ€.
μ μμ μνλ©΄, μ€μ§ RDD μ EDD κ° OO λμμΈ λν λͺ νν λ£°μ κ°μ§κ³ μμΌλ©° κ·Έλ¬λ―λ‘ μ΄λ€μ μ€λλ ₯μλ OO λμμΈ λ°©λ²λ€μ΄λ€.
4. Design patterns provide guidance in designing micro-architectures according to a primary modularization principle: βencapsulate the part that changes.β
λμμΈ ν¨ν΄μ "λ³ννλ λΆλΆμ λν΄ μΊ‘μννλΌ"λ 1μ°¨μ μΈ λͺ¨λν μ리μ λ°λΌ λ§μ΄ν¬λ‘-μν€ν μ³λ€μ λμμΈνλ κ°μ΄λλ₯Ό μ 곡νλ€.
λμμΈ ν¨ν΄μ "λ³ννλ λΆλΆμ λν΄ μΊ‘μννλΌ"λ 1μ°¨μ μΈ λͺ¨λν μ리μ λ°λΌ λ§μ΄ν¬λ‘-μν€ν μ³λ€μ λμμΈνλ κ°μ΄λλ₯Ό μ 곡νλ€.
5. EDD and RDD will generate different design patterns that meet the primary modularization principle βencapsulate the part that changes.β in different ways when applied according to their axiomatic rules. For example RDD generates Mediator, Command, Template Method and Chain of responsibility (mostly behavior) where as EDD generates Observer, Composite, and Chain of responsibility (mostly structure).
EDO μ RDD λ μ΄ 1μ°¨ μλ¦¬μΈ "λ³ννλ λΆλΆμ λν΄ μΊ‘μννλΌ"μ κ·Έλ€μ λͺ νν λ£°λ€μ λ°λΌ μ μ©λ λ λ€λ₯Έ λ°©λ²λ€λ‘ λ§λμ, λ€λ₯Έ λμμΈ ν¨ν΄λ€μ μμ±ν΄ λΌ κ²μ΄λ€. μλ₯Ό λ€λ©΄, RDDλ Mediator, Command, TemplateMethod, ChainOfResponsibility (μ£Όλ‘ behavior), EDD λ Observer, Composite, ChainOfResposibility(μ£Όλ‘ structure) λ₯Ό μμ±ν΄λΌκ²μ΄λ€.
EDO μ RDD λ μ΄ 1μ°¨ μλ¦¬μΈ "λ³ννλ λΆλΆμ λν΄ μΊ‘μννλΌ"μ κ·Έλ€μ λͺ νν λ£°λ€μ λ°λΌ μ μ©λ λ λ€λ₯Έ λ°©λ²λ€λ‘ λ§λμ, λ€λ₯Έ λμμΈ ν¨ν΄λ€μ μμ±ν΄ λΌ κ²μ΄λ€. μλ₯Ό λ€λ©΄, RDDλ Mediator, Command, TemplateMethod, ChainOfResponsibility (μ£Όλ‘ behavior), EDD λ Observer, Composite, ChainOfResposibility(μ£Όλ‘ structure) λ₯Ό μμ±ν΄λΌκ²μ΄λ€.
Now putting this together with the earlier discussion about conceptual integrity we can propose some questions for discussion:
μ, μ΄μ ConceptualIntegrity μ λν ν λ‘ κ³Ό ν¨κ» μ°λ¦¬λ ν λ‘ μ μν μ§λ¬Έλ€μ μ μν μ μλ€.
Β· Are some O-O design methods better at creating an environment where design patterns are used in a generative sense?
Β· Will strong O-O design methods produce results for the βmanyβ with the same conceptual integrity as βa few good minds.β
Β· Will strong O-O design methods produce results for the βmanyβ with the same conceptual integrity as βa few good minds.β
λͺλͺ O-O λμμΈ λ©μλλ€μ λμμΈ ν¨ν΄μ μμ±μ κ΄μ μμ μ΄μ©νλ νκ²½μ λ§λλλ° λ μ’μκ°?
μ€λλ ₯μλ O-O λμμΈ λ©μλλ€μ΄ "a few good minds" μ²λΌ κ°μ κ°λ μ μμ μ±μ κ°μ§ "many" λ₯Ό μ λν κ²°κ³Όλ¬Όμ λ§λ€μ΄λΌ κ²μΈκ°?
μ€λλ ₯μλ O-O λμμΈ λ©μλλ€μ΄ "a few good minds" μ²λΌ κ°μ κ°λ μ μμ μ±μ κ°μ§ "many" λ₯Ό μ λν κ²°κ³Όλ¬Όμ λ§λ€μ΄λΌ κ²μΈκ°?
Even closer to our topic:
μ°λ¦¬μ μ£Όμ μ λ κ°κΉμμ§ μ μλ€.
μ°λ¦¬μ μ£Όμ μ λ κ°κΉμμ§ μ μλ€.
Β· Does J2EE have a primary modularization principle?
Β· How does it meet this objective?
Β· Does the product have conceptual integrity?
Β· Along what principle (experience, data, existence dependency, contract minimization, or some unknown principle) is the application partitioned?
Β· Does this give insight into the organization of design patterns?
J2EE λ 1μ°¨μ μΈ λͺ¨λν μ리λ₯Ό κ°μ§κ³ μλκ°?
μ΄λ»κ² μ΄ λͺ©νμ λ§λ κ²μΈκ°?
μ°μΆλ¬Όμ κ°λ μ μμ μ±μ κ°μ§λκ°?
μ΄λ€ μ리μ λ°λΌ (κ²½ν, λ°μ΄ν°, μμ‘΄μ± μ‘΄μ¬, κ³μ½ μ΅μν, λλ μλ €μ§μ§ μμ μ리λ€) κ° μ΄ν리μΌμ΄μ μ λͺ¨λννλκ°?
μ΄ μ리λ λμμΈ ν¨ν΄μ μ‘°μ§μΌλ‘ ν΅μ°°λ ₯μ μ£Όλκ°?
Β· How does it meet this objective?
Β· Does the product have conceptual integrity?
Β· Along what principle (experience, data, existence dependency, contract minimization, or some unknown principle) is the application partitioned?
Β· Does this give insight into the organization of design patterns?
J2EE λ 1μ°¨μ μΈ λͺ¨λν μ리λ₯Ό κ°μ§κ³ μλκ°?
μ΄λ»κ² μ΄ λͺ©νμ λ§λ κ²μΈκ°?
μ°μΆλ¬Όμ κ°λ μ μμ μ±μ κ°μ§λκ°?
μ΄λ€ μ리μ λ°λΌ (κ²½ν, λ°μ΄ν°, μμ‘΄μ± μ‘΄μ¬, κ³μ½ μ΅μν, λλ μλ €μ§μ§ μμ μ리λ€) κ° μ΄ν리μΌμ΄μ μ λͺ¨λννλκ°?
μ΄ μ리λ λμμΈ ν¨ν΄μ μ‘°μ§μΌλ‘ ν΅μ°°λ ₯μ μ£Όλκ°?
The dilemma is a cruel one. For efficiency and conceptual integrity, one prefers a few good minds doing design and construction. Yet for large systems one wants a way to bring considerable manpower to bear, so that the product can make a timely appearance. How can these two needs be reconciled?
Brooks Mythical Man Month 86
Brooks Mythical Man Month 86