DesignPatternSmalltalkCompanion:1.1: Difference between revisions
Onionmixer (talk | contribs) mNo edit summary |
Onionmixer (talk | contribs) (사소한 수정) |
||
| Line 1: | Line 1: | ||
===1.1 왜 디자인 패턴인가?=== | ===1.1 왜 디자인 패턴인가?=== | ||
전통적 절차적 스타일과 같은 다른 패러다임으로 프로그래밍한 후 객체지향 언어를 학습하기란 힘들다. 스몰토크로 애플리케이션을 만들고 구성하는 방법을 학습하려면 새로운 기술과 문제에 관한 새로운 사고방식들이 필요하다 (예: Rosson & Carroll, 1990; Singley, Carroll, & Alpert, 1991). | 전통적 절차적 스타일과 같은 다른 패러다임으로 프로그래밍한 후 객체지향 언어를 학습하기란 힘들다. 스몰토크로 애플리케이션을 만들고 구성하는 방법을 학습하려면 새로운 기술과 문제에 관한 새로운 사고방식들이 필요하다 (예: Rosson & Carroll, 1990; Singley, Carroll, & Alpert, 1991). "Smalltalk Mountain"의 학습 곡선을 오르는 것은 확실히 중요하다. 단순한 스몰토크 애플리케이션을 구축하는 것에 익숙해지는 안정기에 접어 들고 나면 전문가의 고지까지 엄청나게 떨어져있기 때문이다. | ||
스몰토크 전문가들은 다양한 추상화 수준에서 넓은 프로그래밍 스펙트럼과 디자인 지식 및 기술에 이르기까지 초보자가 알지 못하는 것들을 많이 알고 있다. | 스몰토크 전문가들은 다양한 추상화 수준에서 넓은 프로그래밍 스펙트럼과 디자인 지식 및 기술에 이르기까지 초보자가 알지 못하는 것들을 많이 알고 있다. | ||
* 스몰토크 언어의 구문과 의미론에 관한 저수준의 상세내용 | * 스몰토크 언어의 구문과 의미론에 관한 저수준의 상세내용 | ||
* 기존의 기반 클래스 라이브러리에 클래스, | * 기존의 기반 클래스 라이브러리에 클래스, 메서드, 기능성 형태에서 이용할 수 있는 것 | ||
* 새로 발생한 문제에 대해 기존 기능성을 검색하여 재사용하기 위해 스몰토크 대화형 개발환경에서 특정 도구를 사용하는 방법 뿐 아니라 프로그램을 정적 관점과 런타임 관점에서 이해하는 방법 | * 새로 발생한 문제에 대해 기존 기능성을 검색하여 재사용하기 위해 스몰토크 대화형 개발환경에서 특정 도구를 사용하는 방법 뿐 아니라 프로그램을 정적 관점과 런타임 관점에서 이해하는 방법 | ||
* 새로운 클래스에서 행위를 정의하고 구현하는 방법, 그리고 이 클래스가 기존 클래스 계층구조 중 어디에 위치해야 하는지 | * 새로운 클래스에서 행위를 정의하고 구현하는 방법, 그리고 이 클래스가 기존 클래스 계층구조 중 어디에 위치해야 하는지 | ||
| Line 16: | Line 16: | ||
디자인 패턴은 특정 되풀이되는 클래스 문제를 해결하는데 적용할 수 있는 재사용이 가능한 구현 모델 또는 아키텍처다. 패턴은 때때로 하나의 클래스 또는 클래스의 계층구조가 어떻게 함께 작용하는지를 설명한다; 그리고 대부분의 경우는 다수의 클래스와 그 인스턴스가 어떻게 공동으로 작업하는지를 보여준다. 전문가는 새로운 애플리케이션 특정적 문제와 도메인 특정적 문제에 대해 일반적인 패턴 형태를 재적용하고 수정(customize)하기 때문에 특정 아키텍처가 여러 애플리케이션과 시스템에서 다시 나타나는 것으로 밝혀졌다. 따라서 전문가들은 근사하고 확장이 가능한 해법을 실행하기 위해서 새로운 문제에 대해 디자인 패턴을 어떻게 적용시키는지 알고 있다. | 디자인 패턴은 특정 되풀이되는 클래스 문제를 해결하는데 적용할 수 있는 재사용이 가능한 구현 모델 또는 아키텍처다. 패턴은 때때로 하나의 클래스 또는 클래스의 계층구조가 어떻게 함께 작용하는지를 설명한다; 그리고 대부분의 경우는 다수의 클래스와 그 인스턴스가 어떻게 공동으로 작업하는지를 보여준다. 전문가는 새로운 애플리케이션 특정적 문제와 도메인 특정적 문제에 대해 일반적인 패턴 형태를 재적용하고 수정(customize)하기 때문에 특정 아키텍처가 여러 애플리케이션과 시스템에서 다시 나타나는 것으로 밝혀졌다. 따라서 전문가들은 근사하고 확장이 가능한 해법을 실행하기 위해서 새로운 문제에 대해 디자인 패턴을 어떻게 적용시키는지 알고 있다. | ||
일반적으로 | 일반적으로 설계자들은ㅡ딱히 소프트웨어 분야 뿐만 아니라 많은 분야에서ㅡ과거의 문제와 해법에 대한 경험을 새로 직면하게 된 비슷한 문제에 적용한다. Duego와 Benson (1996)이 지적한 바와 같이, 전문 설계자들은 인지 심리학과 인공 지능에서 사례 기반의 추론이라 알려진 것을 적용시켜 과거의 사례를 기억해내어 그를 통해 배운 것을 적용한다. 이것은 체스 마스터, 의사, 변호사, 건축가가 새로운 문제를 해결하는데 사용하는 추론과 같은 종류이다. 현재 디자인 패턴은 소프트웨어 설계자들이 다른 설계자들의 경험으로부터 학습하고 이를 적용시키기도 한다. 다른 분야에서와 마찬가지로 입증된 패턴에 대한 문헌이 생겨나고 있다. 따라서 우리는 전문가 경지로 더 가까이 가기 위해 "다른 이들의 업적을 이용해 발전할 수 있다"" (p. 32). | ||
'''디자인 패턴'''은 새로운 디자인을 설명하고 기존 패턴을 회고적으로 설명하는 짧은 단어집도 제공한다. 패턴은 세부 사항으로 뛰어들기 전에 디자인을 고수준에서 이해하도록 해준다. 또한 객체와 클래스의 전체적 구성을 커다란 입자로 상상하도록 하여 다른 설계자들이 이러한 구성에 붙여진 이름을 이용해 의사소통을 할 수 있도록 해준다. 우리는 "데이터베이스 접근 클래스에 하나의 인스턴스만 가지도록 한다. 클래스에는 단일 인스턴스를 추적하도록 하나의 클래스 변수만 포함해야 한다. 클래스는 전반적으로 이용할 수 있지만 그에 대한 접근을 통제하는 인스턴스를 만들어야 한다. 클래스는 인스턴스 생성 시기를 조절할 수 있어야 하며…"라고 말하기보다는 "데이터베이스 접근 객체를 Singleton으로 구현하자"고 말할 수 있는 것이다. 당신은 어느 편이 더 좋은가? | |||
[[Category:DesignPatternSmalltalkCompanion]] | [[Category:DesignPatternSmalltalkCompanion]] | ||
Revision as of 10:13, 8 January 2013
1.1 왜 디자인 패턴인가?
전통적 절차적 스타일과 같은 다른 패러다임으로 프로그래밍한 후 객체지향 언어를 학습하기란 힘들다. 스몰토크로 애플리케이션을 만들고 구성하는 방법을 학습하려면 새로운 기술과 문제에 관한 새로운 사고방식들이 필요하다 (예: Rosson & Carroll, 1990; Singley, Carroll, & Alpert, 1991). "Smalltalk Mountain"의 학습 곡선을 오르는 것은 확실히 중요하다. 단순한 스몰토크 애플리케이션을 구축하는 것에 익숙해지는 안정기에 접어 들고 나면 전문가의 고지까지 엄청나게 떨어져있기 때문이다.
스몰토크 전문가들은 다양한 추상화 수준에서 넓은 프로그래밍 스펙트럼과 디자인 지식 및 기술에 이르기까지 초보자가 알지 못하는 것들을 많이 알고 있다.
- 스몰토크 언어의 구문과 의미론에 관한 저수준의 상세내용
- 기존의 기반 클래스 라이브러리에 클래스, 메서드, 기능성 형태에서 이용할 수 있는 것
- 새로 발생한 문제에 대해 기존 기능성을 검색하여 재사용하기 위해 스몰토크 대화형 개발환경에서 특정 도구를 사용하는 방법 뿐 아니라 프로그램을 정적 관점과 런타임 관점에서 이해하는 방법
- 새로운 클래스에서 행위를 정의하고 구현하는 방법, 그리고 이 클래스가 기존 클래스 계층구조 중 어디에 위치해야 하는지
- 어떠한 클래스가 프레임워크로서 잘 작동하는지 여부
- 객체 구성과 상호작용의 반복 (되풀이되는) 패턴, 그리고 협력하는 객체들이 (최소한 일부라도) 해법을 제공하는 문제의 종류
위의 목록은 절대 완벽하다고 할 수 없으며 대부분은 초보자들도 이해하고 이용할 수 있다. 하지만 몇 개의 항목, 특히 마지막 항목은ㅡ소프트웨어 설계에서 반복되는 패턴 또는 디자인 패턴ㅡ디자인 전문가 분야이다.
디자인 패턴은 특정 되풀이되는 클래스 문제를 해결하는데 적용할 수 있는 재사용이 가능한 구현 모델 또는 아키텍처다. 패턴은 때때로 하나의 클래스 또는 클래스의 계층구조가 어떻게 함께 작용하는지를 설명한다; 그리고 대부분의 경우는 다수의 클래스와 그 인스턴스가 어떻게 공동으로 작업하는지를 보여준다. 전문가는 새로운 애플리케이션 특정적 문제와 도메인 특정적 문제에 대해 일반적인 패턴 형태를 재적용하고 수정(customize)하기 때문에 특정 아키텍처가 여러 애플리케이션과 시스템에서 다시 나타나는 것으로 밝혀졌다. 따라서 전문가들은 근사하고 확장이 가능한 해법을 실행하기 위해서 새로운 문제에 대해 디자인 패턴을 어떻게 적용시키는지 알고 있다.
일반적으로 설계자들은ㅡ딱히 소프트웨어 분야 뿐만 아니라 많은 분야에서ㅡ과거의 문제와 해법에 대한 경험을 새로 직면하게 된 비슷한 문제에 적용한다. Duego와 Benson (1996)이 지적한 바와 같이, 전문 설계자들은 인지 심리학과 인공 지능에서 사례 기반의 추론이라 알려진 것을 적용시켜 과거의 사례를 기억해내어 그를 통해 배운 것을 적용한다. 이것은 체스 마스터, 의사, 변호사, 건축가가 새로운 문제를 해결하는데 사용하는 추론과 같은 종류이다. 현재 디자인 패턴은 소프트웨어 설계자들이 다른 설계자들의 경험으로부터 학습하고 이를 적용시키기도 한다. 다른 분야에서와 마찬가지로 입증된 패턴에 대한 문헌이 생겨나고 있다. 따라서 우리는 전문가 경지로 더 가까이 가기 위해 "다른 이들의 업적을 이용해 발전할 수 있다"" (p. 32).
디자인 패턴은 새로운 디자인을 설명하고 기존 패턴을 회고적으로 설명하는 짧은 단어집도 제공한다. 패턴은 세부 사항으로 뛰어들기 전에 디자인을 고수준에서 이해하도록 해준다. 또한 객체와 클래스의 전체적 구성을 커다란 입자로 상상하도록 하여 다른 설계자들이 이러한 구성에 붙여진 이름을 이용해 의사소통을 할 수 있도록 해준다. 우리는 "데이터베이스 접근 클래스에 하나의 인스턴스만 가지도록 한다. 클래스에는 단일 인스턴스를 추적하도록 하나의 클래스 변수만 포함해야 한다. 클래스는 전반적으로 이용할 수 있지만 그에 대한 접근을 통제하는 인스턴스를 만들어야 한다. 클래스는 인스턴스 생성 시기를 조절할 수 있어야 하며…"라고 말하기보다는 "데이터베이스 접근 객체를 Singleton으로 구현하자"고 말할 수 있는 것이다. 당신은 어느 편이 더 좋은가?