User Tools

Site Tools


lecture:clojure:디자인_패턴

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
lecture:clojure:디자인_패턴 [2016/01/15 16:32]
psk810 [패턴에 대한 비판들]
lecture:clojure:디자인_패턴 [2019/02/04 14:26] (current)
Line 11: Line 11:
 Clojure Programming의 저자를 포함해서... 패턴에 대한 비판들이 있다. Clojure Programming의 저자를 포함해서... 패턴에 대한 비판들이 있다.
  
-  ​The design patterns may just be a sign of  +[[https://​en.wikipedia.org/​wiki/​Software_design_pattern#​Criticism|위키피디아]] 
-  ​some missing features of a given programming language. +The design patterns may just be a sign of some missing features of a given programming language. 
-  디자인 패턴은 해당 프로그래밍 언어에 그러한 기능이 없다는 징후일 뿐이다. +디자인 패턴은 해당 프로그래밍 언어에 그러한 기능이 없다는 징후일 뿐이다.
- +
- - 위키피디아(https://​en.wikipedia.org/​wiki/​Software_design_pattern#​Criticism) +
  
 (이게 맞는 말이기도 하고... 또 아니기도 하다) (이게 맞는 말이기도 하고... 또 아니기도 하다)
  
-내가 만든 프로그램에서 패턴이 보이면, 나는 그것을 문제의 신호라고 생각한다. 프로그램의 모양새는 단지 그것이 풀려고 하는 문제들만을 반영해야 한다. 코드에 (문제가 아닌) 어떤 다른 규정성이 있다는 것은 적어도 나에게는 하나의 신호로써,​ 즉 충분히 강력하지 않은 추상성을 사용했다는 것이 된다." +[[http://​www.paulgraham.com/​icad.html|Revenge of Nerds]], by 폴 그레함 
- - 폴 그레함. [Revenge of Nerds]의 말미에서+내가 만든 프로그램에서 패턴이 보이면, 나는 그것을 문제의 신호라고 생각한다. 프로그램의 모양새는 단지 그것이 풀려고 하는 문제들만을 반영해야 ​한다. 코드에 (문제가 아닌) 어떤 다른 규정성이 있다는 것은 적어도 나에게는 하나의 신호로써,​ 즉 충분히 강력하지 않은 추상성을 사용했다는 것이 된다.
  
-http://www.paulgraham.com/icad.html+  
 +[[http://thinkrelevance.com/blog/​2009/​10/​19/​the-case-for-clojure|Stuart Holloway의 elevator pitch]] 
 +> 디자인 패턴은 질병, 클로저는 치료제
  
  
-"​디자인 패턴은 질병, 클로저는 치료제"​ - Stuart Holloway의 elevator pitch 
-http://​thinkrelevance.com/​blog/​2009/​10/​19/​the-case-for-clojure 
  
  
Line 40: Line 37:
  - A Pattern Language, page x. Chrisopher Alexander  - A Pattern Language, page x. Chrisopher Alexander
  
-"각 패턴은 우리 환경에서 반복해서 발생하는 문제를 설명하고,​ 그리고 그런 문제들에 대해 해결의 핵심을 설명하는데,​ 이러한 해결책을 같은 방식으로 두 번 반복하지 않고, 백만번 이상 사용할 수 있는 방식으로 설명한다."​+"각 패턴은 우리 환경에서 반복해서 발생하는 문제를 설명하고,​ 그리고 그런 문제들에 대한 해결의 핵심을 설명하는데,​ 이러한 해결책을 같은 방식으로 두 번 반복하지 않고, 백 만번 이상 사용할 수 있는 방식으로 설명한다."​
  
 패턴은 구체적인 솔루션에 대한 것이 아니다. 해결하고자 하는 문제와 그 해결책의 핵심을 일컫는 것. 패턴은 구체적인 솔루션에 대한 것이 아니다. 해결하고자 하는 문제와 그 해결책의 핵심을 일컫는 것.
Line 46: Line 43:
 Page 3. 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." ​- 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."​
  
 관점에 따라 무엇이 패턴인지 아닌지 그 해석이 달라진다. 어떤이에게는 패턴이지만,​ 다른이에게는 그냥 언어에서 제공하는 문법이다. 관점에 따라 무엇이 패턴인지 아닌지 그 해석이 달라진다. 어떤이에게는 패턴이지만,​ 다른이에게는 그냥 언어에서 제공하는 문법이다.
Line 84: Line 81:
 ==== 클로저에서의 디자인 패턴 ==== ==== 클로저에서의 디자인 패턴 ====
  
-1급 함수, 동적 타입, 불변값과 같은 클로저의 언어적 특징으로 인해 많은 디자인 패턴들이 클로저에서는 사라진다.(언어 내적으로 포함되거나,​ 아니면 단지, 함수의 활용 수준 정도에서 해결된다.)+1급 함수, 동적 타입, 불변값과 같은 클로저의 언어적 특징으로 인해 많은 디자인 패턴들이 클로저에서는 사라진다.(언어 내적으로 포함되거나,​ 아니면 단지, 함수의 활용 수준 정도(이디엄)에서 해결된다.)
  
 === Peter Norvig의 동적언어에서의 디자인 패턴 === === Peter Norvig의 동적언어에서의 디자인 패턴 ===
Line 114: Line 111:
 ===== AOP ===== ===== AOP =====
  
-==== Robert ​Hook ====+[[https://​github.com/​technomancy/​robert-hooke|Robert ​Hooke]]
  
 ===== 함수형 디자인 패턴 ===== ===== 함수형 디자인 패턴 =====
Line 182: Line 179:
  
  
-==== Pipeline ====+==== Pipeline ​Pattern ​==== 
 + 
 +[[https://​github.com/​rm-hull/​monet|monet canvas drawing 라이브러리]] 
  
 ==== Prymid of Doom ==== ==== Prymid of Doom ====
 +
 +[[https://​adambard.com/​blog/​acceptable-error-handling-in-clojure/​|Maybe 모나드]]
lecture/clojure/디자인_패턴.1452875572.txt.gz · Last modified: 2019/02/04 14:26 (external edit)