디자인 패턴은 반복해서 발생하는 문제들에 대한 일반적이고 재사용가능한 해법들을 말한다. OOP의 트레이드 마크로, 자바와 루비 세계의 많은 프로그래머들에게 친숙한 공통 용어를 제공한다.

Clojure Programming의 저자를 포함해서… 패턴에 대한 비판들이 있다.

위키피디아

The design patterns may just be a sign of some missing features of a given programming language.
디자인 패턴은 해당 프로그래밍 언어에 그러한 기능이 없다는 징후일 뿐이다.

(이게 맞는 말이기도 하고… 또 아니기도 하다)

Revenge of Nerds, by 폴 그레함

내가 만든 프로그램에서 패턴이 보이면, 나는 그것을 문제의 신호라고 생각한다. 프로그램의 모양새는 단지 그것이 풀려고 하는 문제들만을 반영해야 > 한다. 코드에 (문제가 아닌) 어떤 다른 규정성이 있다는 것은 적어도 나에게는 하나의 신호로써, 즉 충분히 강력하지 않은 추상성을 사용했다는 것> 이 된다.

Stuart Holloway의 elevator pitch

디자인 패턴은 질병, 클로저는 치료제

GOF의 디자인 패턴 1장에서는 Chrisopher Alexander의 패턴에 대한 정의를 인용한다.

Page 2.

“Each pattern describes a problem which occurs over and over again in our environments, and then describes the core of the solution to that problem, in such a way that can use this solution a million time over, without ever doing it the same way twice” - A Pattern Language, page x. Chrisopher Alexander

“각 패턴은 우리 환경에서 반복해서 발생하는 문제를 설명하고, 그리고 그런 문제들에 대한 해결의 핵심을 설명하는데, 이러한 해결책을 같은 방식으로 두 번 반복하지 않고, 백 만번 이상 사용할 수 있는 방식으로 설명한다.”

패턴은 구체적인 솔루션에 대한 것이 아니다. 해결하고자 하는 문제와 그 해결책의 핵심을 일컫는 것.

Page 3.

“Point of view affects one's interpretation of what is and isn't a pattern. One person's pattern can be another person's primitive building block. For this book we have concentrated on patterns at a certain level of abstraction.”

관점에 따라 무엇이 패턴인지 아닌지 그 해석이 달라진다. 어떤이에게는 패턴이지만, 다른이에게는 그냥 언어에서 제공하는 문법이다.

“The design pattern in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context”

이 책에서 디자인 패턴은 특정 상황에서의 일반적인 디자인 문제를 해결하기 위해 커뮤니케이션하는 객체와 클래스간들에 대한 설명이다.

Page 4.

“The choice of programming language is important because it influences one's point of view. Our patterns assume Smalltalk/C++-level language features, and that choice determines what can and cannot be implemented easily. If we assumed procedural languages, we might have included design patterns called “Inheritance”, “Encapsulation”, and “Polymorphism”. Similarly, some of our patterns are supported directly by the less common obejct-oriented language. CLOS has multi-methods,for example, which lessen the need for a pattern such as Visitor(page 331). In fact, there are enough differences between Smalltalk and C++ to mean that some patterns can be expressed more easily in one language than the other(See Iterator(257) for an example.)” - page 4.

어떤 언어를 선택하느냐는 관점에 영향을 준다. 우리는 Smalltalk/C++ 언어에 기반해서 패턴을 설명한다. 이러한 선택이 어떤 패턴은 구현이 쉽고 어떤 것은 어려운지를 결정한다. 만일 절차적 언어였다면, 우리는 “상속”, “캡슐화”, “다형성”을 패턴으로 추가했을 것이다. 다른 객체 지향 언어에서는 우리가 제시한 패턴들이 언어차원에서 지원된다. CLOS에서는 multi-methods를 기본으로 제공하는데, 그래서 거기서는 Visitor 패턴을 구현할 필요가 없다. Iterator 패턴은 Smalltalk와 C++에서 그 구현의 쉽고 어려움이 크게 다르다.

Sean Corfield: http://librelist.com/browser//foray/2013/6/13/design-patterns-clojure/#98299143dcc1b9e8e3add49386443db7

• 비슷한 문제들이 반복해서 나타나므로 해결책도 반복된다. 이것이 바로 패턴이다.
• 패턴은 개념이지 구현이 아니다. 따라서 언어에 상관없이 패턴은 개념적 측면에서 봐야 한다.
  • 비판들은 대개 패턴의 구현적 측면에서 머물고 있다.
  • 패턴은 레시피가 아니다. 개념이다.
  • 패턴은 각 언어마다 그 구현이 다르며, 특히 패러다임에 따라 큰 편차를 보인다.
• 어떤 언어에서는 그 패턴이 없는 것이 아니라, 언어 자체에 내장되어 보이지 않는 것일 뿐.
  • 하지만 객체지향언어, 특히 클래스 기반의 객체지향 언어에게만 특화된 패턴들은 함수형 언어에서는 불필요하다.
    • GOF의 DP에서도 OOP관점에서의 디자인 패턴을 본 것이지만, 만일 절차적 언어를 선택했다면 생성자, 상속 패턴 등이 나왔을 것이라고 했듯이
    • 함수형 언어에서는 객체나 클래스가 없기 때문에, 그들 때문에 존재하게 된 패턴들은 사라지게 된다.
  • 혹은 이디엄(Idiom) 수준으로 단순화된다.
  • 함수형 언어에서도 패턴은 있으며, 단지 그 패턴을 어떻게 구현할 지는 언어의 특성의 따라 다르다.
    • 예를 들어 모나드도 패턴이라고 볼 수 있는데, 이것은 헤스켈과 클로저에서 그 구현 및 쓰임의 정도가 다르다.
    • 클로저와 같은 리습에서는 매크로가 중요한 역할을 한다.
• 결국 일상적으로 사용되는 패턴을 쉽게 사용할 수 있도록 만든 언어가 더 고급한 언어이다.
  • 즉 그것이 패턴이었는지도 모르고, 부지불식간에 자연스럽게 사용하도록 하는 것.

1급 함수, 동적 타입, 불변값과 같은 클로저의 언어적 특징으로 인해 많은 디자인 패턴들이 클로저에서는 사라진다.(언어 내적으로 포함되거나, 아니면 단지, 함수의 활용 수준 정도에서 해결된다.)

http://norvig.com/design-patterns/design-patterns.pdf

GOF의 DP 23개중 16개가 사라지거나 단순화된다.(Lisp이나 Dylan 언어에서, C++보다는)

• First-class type
  • Abstract-Factory,Flyweight, Factory-Method, State, Proxy, Chain-Of-Responsibility
• First-class function
  • Command, Strategy, Template-Method, Visitor
• Macros
  • Interpreter, Iterator
• Method Combination
  • Mediator, Observer
• Multimethods
  • Builder
• Modules
  • Facade

http://mishadoff.com/blog/clojure-design-patterns/

GOF의 DP 23개 전부에 대해 자바 버전와 클로저 버전을 상황과 사례를 들어서 두 사람이 대화를 하면서 설명한다.

클로저 코드에서 나타나는 패턴들.

https://strange-loop-2012-notes.readthedocs.org/en/latest/monday/functional-design-patterns.html

• State Patterns
  • State/Event
    • Derive state from previous state + input
    • Need to recover past states (and perhaps inputs)
    • Need to visualize intermediate states
  • Consquences
    • An input to the system can cause multiple events/side effects
    • Generated events can trigger state change
• Data Building Patterns
  • Accumulator Pattern
    • Large collection of inputs – maybe larger than memory
    • Small or scalar result
  • Reduce/Combine
    • Input is tree-like
    • Divide and conquer approach
    • Associative combination of intermediate results (a + b) + c = a + (b + c)
  • Recursive Expansion
    • Build a result from primitives
    • Abstractions are built in layers
    • Recurse until there’s no more work
    • Examples: macro expansion, Datomic transaction fns
• Flow Control Patterns
  • Pipeline Pattern
    • Some process with many discreet steps
    • one execution path – no branching
    • Each step has a similar “shape” – a map or record in Clojure
  • Wrapper Pattern
    • Similar to the Pipeline
    • Possible branch at each step
  • Token Pattern
    • An Operation may not have an identity
    • But you may need to cancel it
  • Observer Pattern
    • Register an observer with a stateful function
  • Strategy Pattern
    • Many processes with similar structures
    • Extension points for future variations
    • This is a GoF pattern which starts to disappear in Clojure

Scala와 Groovy에서의 패턴들

http://www.ibm.com/developerworks/java/library/j-ft10/index.html

헤스켈에서 나타나는 패턴들

https://patternsinfp.wordpress.com/welcome/

http://langexplr.blogspot.kr/2007/05/using-scala-extractors-with-xsd-schema.html