Learning an object-oriented language after programming in another paradigm, such as the traditional procedural style, is difficult. Learning to program and compose application in Smalltalk requires a complex set of new skills and new ways of thinking about problems(e.g Rosson & Carroll, 1990; Singley, & Alpert, 1991). Climbing the "Smalltalk Mountain" learning curve is cetainly nontrivial. Once you have reached that plateau where you feel comfortable building simple Smalltalk applications, there is still a significant distance to the expert peak.
다른 이론적인 테두리안에서 프로그램(전통적인 절차식 스타일)을 한 후 객체 지향 언어를 배우는 것은 어렵다. Smalltalk 안에서 복합된 응용 프로그램 하는 것을 배우는 것은 복잡한 새로운 기술과 문제에 대한 새로운 사고 방식을 요구한다.(" e.g Rosson & Carroll, 1990; Singley, & Alpert, 1991") "Smalltalk" 라는 산을 오르는 것은 확실히 사소한 것이 아니다. 일단 당신이 간단한 Smalltalk 응용 프로그램을 만드는 데 자신이 있는 경지에 닿았다고 해도, 아직 전문가의 경지와는 분명한 차이가 있다.
Smalltalk experts know many things that novices do not, at various abstraction levels and across a wide spectrum of programming and design knowledge and skills:
- The low-level details of the syntax and semantics of the Smalltalk language
- What is available in the form of classes, methods, and functionality in the existing base class libraries
- How to use the specific tools of the Smalltalk interactive development environment to find and reuse existing functionality for new problems, as well as understanding programs from both static and runtime perspective
- How to define and implement behavior in new classes and where these classes ought to reside in the existing class hierarchy
- Which classes work well together as frameworks
- Recurring patterns of object configurations and interactions and the sorts of problems for which these cooperating objects provide (at least partial) solutions
Smalltalk 전문가들은 여러가지 다양한 추상적 단계와 폭넓은 programming과 design에 대한 지식과 기술면에서 초심자들이 알지 못하는 많은 것을 알고 있다.
- Smalltalk의 문법과 언어기호적인 저급단계 (컴퓨터에서의 low-level 단계)적인 항목에 대해
- 현존하는 기반 class 라이브러리로부터 이용가능한 class, methods. 그리고 그 모듈들(현재는 functionality를 function 군들 또는 모듈 정도로 해석중. 태클 바람. --;)에 대해
- 새로운 문제를 찾고 문제 해결을 위한 기존의 모듈을 재사용하기 위해, 또는 정적이거나 동적인 관점 양쪽 측면에서 프로그램을 이해하기 위해 어떻게 Smalltalk IDE 툴을 사용해야 하는가에 대해
- 어떤 클래스들이 frameworks로서 서로 잘 작동하는지에 대해
- 객체의 환경설정과 상호작용, 이러한 서로 협력하는 객체들이 해결해야할 문제들의 정렬 등에서 반복되는 패턴에 대해
This is by no means an exhaustive list, and even novices understand and use much of the knowledge. But some items, especially the last -- recurring patterns of software design, or design patterns -- are the province of design expert.
A design pattern is a reusable implementation model or architecture that can be applied to solve a particular recurring class of problem. The pattern sometimes describes how methods in a single class or subhierarchy of classes work together; more often, it shows how multiple classes and their instances collaborate. It turns out that particular architectures reappear in different applications and systems to the extent that a generic pattern template emerges, one that experts reapply and customize to new application - and domain-specific problems. Hence, experts know how to apply design patterns to new problems to implement elegant and extensible solutions.
디자인 패턴은 끊이없이 발생하는 클래스 구성상의 문제에 해결책을 제시하는 재사용할수 있는 실행 모델이나 아키텍처이다. 때로 패턴은 단독적이거나 하위 클래스 구조에서 어떻게 매서드 들이 함께 작용하는지를 묘사한다.; 아마도, 패턴상에서는 좀더 빈번히 다중 클래스나 그들의 인스턴스의 협력을 보여줄다.
패턴은 각기 다른 어플리케이션과 시스템상에서 재현되는 특별한(고유한, 플랫폼 종속적인) 아키택처, 전문가들이 새로운 어플리케이션,분야에서 발생하는 특별한 문제들을 제거한다. (위에서 쓰인 one이 particular architecture와 동등한 위치로 해석한 방법. 다른의견 제안바람-상민
그러므로, 전문가들은 어떻게 새로운 문제에 대하여 고아하고 확장성있는 해결책으로 안내하는 디자인 패턴의 활용 방법을 알고 있다.
(그러므로, 전문가들은 새로운 문제를 해결하기 위해 명쾌하고 확장성이 뛰어난 디자인 패턴을 적용하는 방법을 알고 있다.)
In general, designers -- in numerous domains, not just software -- apply their experience with past problems and solution to new, similar problems. As Duego and Benson(1996) point out, expert designers apply what is known in cognitive psychology and artificial intelligence as case-based reasoning, remembering past cases and applying what they learned there. This is the sort of reasoning that chess masters, doctors, lawyers, and architects empoly to solve new problems. Now, design patterns allow software designers to learn from and apply the experiences of other designers as well. As in other domains, a literature of proven patterns has emerged. As a result, we can "stand on the shoulders of giants" to get us closer to the expert peak. As John Vlissies (1997) asserts, design patterns "capture expertise and make it accessible to non-experts" (p. 32).
디자이너들-소프트웨어에만 국한하지 않은 수많은 분야에서-은 그들의 과거의 문제와, 해법에 경험을 비슷한 문제에 적용 시킨다. Duego와 Genson(1996)은 전문 디자이너들이 사례를 기반으로 경험에서 인지한 지혜안에서 과거의 사례를 기억하고 그들이 배운것을 적용시키는 것에 주목한다. (생략 및 의역) 이것은 체스의 고수, 의사, 변호사 그리고 건축가들이 새로운 문제에 대응하는 추론 방식의 한 방식이다. 현재, 디자인 패턴은 소프트웨어 디자이너들이 배워온것들과 다른 분야의 디자이너(other designer)들의 경험들 모두를 감안한다. 이런 노력들은 결과적으로, "거인의 어깨에 올라서 있는것" 같은 방법으로 우리를 훌륭한 디자인에 이끌수 있다. John Vlissies(1997)은 디자인 패턴은 "전문 지식을 잡고 비전문가들이 그것을 이용하기 쉽게 해주는 것이라고 평한다. (p. 32).
Design patterns also provide a succinct vocabulary with which to describe new designs and retrospectively explain existing ones. Patterns let us understand a design at a high level before drilling down to focus on details. They allow us to envision entire configurations of objects and classes at a large grain size and communicate these ideas to other designers by name. We can say, "Implement the database access object as a Singleton," rather than, "Let's make sure the database access class has just one instance. The class should include a class variable to keep track of the singl instance. The class should make the instance globally available but control access to it. The class should control when the instance is created and ..." Which would you prefer?
디자인 패턴은 새로운 패턴에 관해서 간단하게 원리를 표현하고, 패턴은 존재하는 모습을 꾸준히 설명한다.패턴은 세부내용에 들어가기 앞서, 좀더 큰 관점으로 이해를 할수있게 한다. 패턴은 우리가 좀더 큰 관점에으로 ㄸ 다른 디자이너들의 생각의 교환시 객체과 클래스가 어떻게 구성되어 있는지 묘사한다. 우리는 "싱글턴 메소드로 데이터 베이스 접근 부분을 구성했습니다." 그리고 "데이터 베이스 접근은 오직 하나의 인스턴스만이 접근하도록 해습니다. 그 클래스는 싱글 인스턴스의 방법 사용을 위해서 클래스 변수를 사용할것입니다. 그 클래스는 광역으로 광역으로 접근가능한 인스턴스로 될것이지만, 나중고침
그 클래스는 그 인스턴스가 만들어지고... "고 말할수 있습니다. 당신은 어떻게 설명하겠습니까?
졸려서.. --; 조만간 마저 하겠음 -- 석천