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