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 의 코멘트는 흥미롭다. "무엇이 좋은 객체지향 디자인을 만드는가?"
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?”
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?”
이는 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
