E D R , A S I H C RSS

Full text search for "Gof"

Gof


Search BackLinks only
Display context of search results
Case-sensitive searching
  • PatternCatalog . . . . 23 matches
          * ["Gof/AbstractFactory"]
          * ["Gof/Builder"]
          * ["Gof/FactoryMethod"]
          * ["Gof/Prototype"]
          * ["Gof/Singleton"]
          * ["Gof/Adapter"]
          * ["Gof/Bridge"]
          * ["Gof/Composite"]
          * ["Gof/Decorator"]
          * ["Gof/Facade"]
          * ["Gof/Flyweight"]
          * ["Gof/Proxy"]
          * ["Gof/ChainOfResponsibility"]
          * ["Gof/Command"]
          * ["Gof/Interpreter"]
          * ["Gof/Iterator"]
          * ["Gof/Mediator"]
          * ["Gof/Memento"]
          * ["Gof/Observer"]
          * ["Gof/State"]
  • AbstractFactory . . . . 1 match
         Gof/AbstractFactory
  • AbstractFactoryPattern . . . . 1 match
         ["Gof/AbstractFactory"]
  • AdapterPattern . . . . 1 match
         #redirect Gof/Adapter
  • CleanCode . . . . 1 match
          * [http://wiki.zeropage.org/wiki.php/Gof/AbstractFactory Factory Pattern]
  • CommandPattern . . . . 1 match
         ["Gof/Command"]
  • CompositePattern . . . . 1 match
         ["Gof/Composite"]
  • FacadePattern . . . . 1 match
         #redirect Gof/Facade
  • FactoryMethodPattern . . . . 1 match
         #redirect Gof/FactoryMethod
  • GofStructureDiagramConsideredHarmful . . . . 1 match
         There's a mistake that's repeated throughout the Design Patterns book, and unfortunately, the mistake is being repeated by new patterns authors who ape the GoF style.
         Design Pattern 책 전반에 걸쳐 반복적으로 잘못 이해되는 내용들이 있는데, 불행하게도 이러한 실수는 GoF의 스타일을 모방한 다른 Pattern 책의 저자들에게서도 반복적으로 나타난다.
         Each GoF pattern has a section called "Structure" that contains an OMT (or for more recent works, UML) diagram. This "Structure" section title is misleading because it suggests that there is only one Structure of a Pattern, while in fact there are many structures and ways to implement each Pattern.
         사실은 각 Pattern을 구현하기 위한 여러가지 방법이 있는데, GoF의 OMT diagram을 보노라면 마치 각 Pattern에 대한 단 한가지 구현만이 있는 것으로 잘못 이해될 수 있다.
         But inexperienced Patterns students and users don't know this. They read the Patterns literature too quickly, often thinking that they understand a Pattern merely by understanding it's single "Structure" diagram. This is a shortcoming of the GoF Form, one which I believe is harmful to readers.
         하지만, Pattern에 대한 경험이 부족한 학생들이나 사용자들은 이 사실을 모르고 있다. 그들은 Pattern에 대한 저술들을 너무 빨리 읽는다. 단지 한 개의 Diagram만을 이해하는 것으로 Pattern을 이해했다고 착각하는 경우도 잦다. 이게 바로 필자가 생각하기에는 독자들에게 해로워보이는 GoF 방식의 단점이다.
         What about all those important and subtle Implementation notes that are included with each GoF Pattern? Don't those notes make it clear that a Pattern can be implemented in many ways? Answer: No, because many folks never even read the Implementation notes. They much prefer the nice, neat Structure diagrams, because they usually only take up a third of a page, and you don't have to read and think a lot to understand them.
         GoF 책의 각 Pattern 마다 첨부되어 있는 구현에 대한 매우 중요하고 민감한 해설들은 어떠한가? 이 해설들을 통해서 Pattern이 여러 방법으로 구현될 수 있다는 사실을 알 수는 없을까? 알 수 없을 것이다. 왜냐하면 많은 독자들이 아예 구현에 대한 해설 부분을 읽지도 않고 넘어가기 때문이다. 그들은 보통 간략하고 훌륭하게 그려진 Structure diagram을 더 선호하는데, 그 이유는 보통 Diagram에 대한 내용이 세 페이지 정도 분량 밖에 되지 않을 뿐더러 이것을 이해하기 위해 많은 시간동안 고민을 할 필요도 없기 때문이다.
         Diagrams are seductive, especially to engineers. Diagrams communicate a great deal in a small amount of space. But in the case of the GoF Structure Diagrams, the picture doesn't say enough. It is far more important to convey to readers that a Pattern has numerous Structures, and can be implemented in numerous ways.
         엔지니어들에게 있어서 Diagram은 정말 뿌리치기 힘든 유혹이다. 하지만 Gof의 Structure diagram의 경우엔 충분히 많은 내용을 말해줄 수 없다. Pattern들이 다양한 Structure를 가질 수 있으며, 다양하게 구현될 수 있다는 것을 독자들에게 알려주기엔 턱없이 부족하다.
         I routinely ask folks to add the word "SAMPLE" to each GoF Structure diagram in the Design Patterns book. In the future, I'd much prefer to see sketches of numerous structures for each Pattern, so readers can quickly understand that there isn't just one way to implement a Pattern. But if an author will take that step, I'd suggest going even further: loose the GoF style altogether and communicate via a pattern language, rich with diagrams, strong language, code and stories.
         결론은~ 패턴을 구현하는데에 꼭 한가지 형태의 다이어그램과 한가지 형태의 구현이 있다는 것은 아니라는 이야기. GoF 에서의 다이어그램 또한 하나의 예라는 것을 강조.
  • HowToStudyDesignPatterns . . . . 1 match
         DP의 저자(GoF) 중 한 명인 랄프 존슨은 다음과 같이 말합니다:
         역시 GoF의 한명인 존 블리스사이즈는 다음과 같이 말합니다:
          ''The other thing I want to underscore here is how to go about reading Design Patterns, a.k.a. the "GoF" book. Many people feel that to fully grasp its content, they need to read it sequentially. But GoF is really a reference book, not a novel. Imagine trying to learn German by reading a Deutsch-English dictionary cover-to-cover;it just won't work! If you want to master German, you have to immerse yourself in German culture. You have to live German. The same is true of design patterns: you must immerse yourself in software development before you can master them. You have to live the patterns.
          Read Design Patterns like a novel if you must, but few people will become fluent that way. Put the patterns to work in the heat of a software development project. Draw on their insights as you encounter real design problems. That’s the most efficient way to make the GoF patterns your own.''
         주변에서 특정 패턴이 구현된 코드를 구하기가 힘들다면 이 패턴을 자신이 만지고 있는 코드에 적용해 보려고 노력해 볼 수 있습니다. 이렇게 해보고 저렇게도 해보고, 그러다가 오히려 복잡도만 증가하면 "아 이 경우에는 이 패턴을 쓰면 안되겠구나"하는 걸 학습할 수도 있죠. GoF는 한결 같이 패턴을 배울 때에는 "이 패턴이 적합한 상황과 동시에 이 패턴이 악용/오용될 수 있는 상황"을 함께 공부하라고 합니다.
         그런데 사실 GoF의 DP에 나온 패턴들보다 더 핵심적인 어휘군이 있습니다. 마이크로패턴이라고도 불리는 것들인데, delegation, double dispatch 같은 것들을 말합니다. DP에도 조금 언급되어 있긴 합니다. 이런 마이크로패턴은 우리가 알게 모르게 매일 사용하는 것들이고 그 활용도가 아주 높습니다. 실제로 써보면 알겠지만, DP의 패턴 하나 쓰는 일이 그리 흔한 게 아닙니다. 마이크로패턴은 켄트벡의 SBPP에 잘 나와있습니다. 영어로 치자면 관사나 조동사 같은 것들입니다.
          1. ["DesignPatternSmalltalkCompanion"] : GoF가 오른쪽 날개라면 DPSC는 왼쪽 날개
         DP를 처음 공부한다면, DPE와 DPJW를 RF와 함께 보면서 앞서의 두권을 RF적으로 독해해 나가기를 권합니다. 이게 된 후에는 {{{~cpp GoF}}}와 DPSC를 함께 볼 수 있겠습니다. 양자는 상호보완적인 면이 강합니다. 이 쯤 되어서 SBPP를 보면 상당히 충격을 받을 수 있습니다. 스스로가 생각하기에 코딩 경험이 많다면 다른 DP책 이전에 SBPP를 먼저 봐도 좋습니다.
          * GofStructureDiagramConsideredHarmful - 관련 Article.
  • MediatorPattern . . . . 1 match
         ["Gof/Mediator"]
  • SingletonPattern . . . . 1 match
         프로그램 내에서 오직 하나만 존재해야만 하는 공용 객체에 대한 해결방법. (내용에 대해서는 ["Gof/Singleton"] 참조)
  • StatePattern . . . . 1 match
         #redirect Gof/State
  • VisitorPattern . . . . 1 match
         ["Gof/Visitor"]
  • 우리가나아갈방향 . . . . 1 match
          Gof 꺼 올려놨으니 그거 먼저보라니까.. 충고 안듣으시더니. -_-; DPSC가 더 어려울텐데.. 흡. --석천
  • 정모/2006.9.13 . . . . 1 match
          - Design Patterns - Gof 의 뭐시기, 알자~~ 영진출판사
Found 17 matching pages out of 7540 total pages (5000 pages are searched)

You can also click here to search title.

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
Processing time 0.3992 sec