[[PageList(^DesignPatterns/2011년스터디)]]
 * HolubOnPatterns를 함께 읽는 스터디.
 * 참가자:
  * [김준석], [김수경], [서지혜], [임상현]
  * 코치: [변형진]
 * 매 주 토요일 2시에 모입니다.
== 출석체크 ==
|| || [김준석] || [김수경] || [서지혜] || [임상현] ||
|| 3/19 || O || O || O || X ||
|| 3/27 || X || O || O || O ||
|| 4/2 || O || O || O || O ||
|| 4/10 || O || O || O || O ||
|| 4/29 || O || O || O || O ||
|| 5/6 || O || O || O || O ||
|| 5/13 || O || O || O || O ||
== 3월 19일 ==
 * DoWeHaveToStudyDesignPatterns?
 * HowToStudyDesignPatterns?
 * 진행 방식
  * 책을 읽으며 ["HolubOnPatterns/밑줄긋기" 밑줄을 긋자]
  * DB 프로젝트를 하자?
== 3월 27일 ==
=== 후기 ===
==== 김수경 ====
 1. HolubOnPatterns 0장에 대해 함께 이야기했다. 나 혼자 0장을 안 읽어와서 민망했다. 1장은 꼭 읽어와야지.
 1. High Cohesion Low Coupling과 SOLID(SRP, OCP, LSP, ISP, DIP)에 대해 다시 생각해보는 시간이 되었다.
  1. SRP(Single Response Principle)에 대해 얘기하면서 '책임'이란 무엇인가에 대한 이야기가 나왔다. 삽질 경험이 없는 사람에게 객체지향 원칙을 설명할 때 '책임'이 무엇인지 어떻게 이해시켜야 할지 모르겠다. 오늘 얘기하면서 낸 결론도 경험이 없으면 이해하기 어렵다는 것…
  1. DIP에서 의존관계 역전이 대체 무엇을 역전시킨다는 것인지 알게되었다. 기존에는 Highlevel 모듈이 Lowlevel 모듈에 의존하는 식이었지만 인터페이스를 사용하여 Lowlevel 모듈이 Highlevel이 제공하는 인터페이스에 의존하게 함으로써 설계를 더 유연하게 만들 수 있다.
 1. 여름방학때 1, 2학년들과 함께 OOP 스터디를 진행하고싶다.
==== 서지혜 ====
 1. 0장 읽어오고 밑줄긋기(안함), 내용에 대해 이야기 나누기
 1. 객체지향을 왜 해야하는가? 근본적으로 소프트웨어가 변화하기 때문이다. 객체지향은 변화에 잘 대응할 수 있는 설계 패턴이다. 
 1. DIP 
  1. 처음엔 단순히 인터페이스 대신 넘겨받는 구체클래스를 써야해서인 줄 알았는데 상위기술이 하위기술에 의존하는 것이 아닌 하위기술이 상위기술을 지원하기 위해 만들어지는 것이라는것을 알게되었다. 
  1. 의존관계 역전이라 해서 낯설었는데 이렇게 설명하니 상위기술에 하위기술이 맞추는게 당연한게 아닌가 하는 생각이 들었다. 
 1. SRP에서 책임나누기 - 변화를 상상해보라.. 서비스가 변경될 때 함께 수정되어야 할 코드들을 분리해라! 그것이 변화의 축이다. - 많은 상상과 삽질을 해야겠습니다. 
 1. 좋은 설계는 천재 프로그래머에 의해 한번에 만들어지는게 아니라 고민하는 프로그래머에 의해 지속적으로 만들어 지는 것 이다. 용기를 주는 말입니다. 
  1. 이 자리에 이 패턴을 적용해야할 이유를 대라. 패턴을 적용할 때에는 타당한 이유가 있어야 한다. 생각없이 적용된 패턴은 오히려 설계를 망친다.
  1. 즐겨라:) 
==== 임상현 ====
 * 왜 디자인 패턴을 쓰느냐?, SOLID를 공부했습니다. 오랜만에 공부를 잘 안돌아갑니다. , 열심히 공부해야겠습니다. 삽질을 덜하고 싶습니다. 

== 4월 02일 ==
=== 후기 ===
==== 김준석 ====
 1. 밑줄긑기가 잘 남는군. 역시 근데 책을 읽어온다는건 힘들어.
 1. 알면 알수록 오류는 정정되고 지식은 쌓이는 기분.
 1. 지금짜는 코드만큼 미래를 위해서는 개념공부가 중요하지만 난 잘안하지.


==== 김수경 ====
 1. 이번 스터디는 책도 미리 읽어보고, 밑줄도 다들 열심히 그어서 더 재미있었다.
 1. 혼자 책을 읽을 때는 '동적인 행동양식'이 무엇인지 잘 감이 오지 않았는데 오늘 스터디하며 알게되었다.
  1. 책에 나온 교차 통풍 패턴을 예로 들어 말하자면, 정적인 구조를 볼 때 마주보는 양 쪽 벽 비슷한 높이에 창문이 있는 사무실은 교차 통풍 패턴에 속하는 것처럼 보일 수 있다. 그러나 창문 앞에 커다란 건물이 있으면 바람을 막아서 창을 통해 바람이 들어오지 않는다. 교차 통풍 패턴은 마주보는 양 벽에 각각 창이 있다는 그 자체로 실내 공기를 쾌적하게 만드는 것이 아니라 창을 통해 바람이 불어들어오고 불어나감으로써 실내 공기를 쾌적하게 만드는 것이다. 따라서 교차 통풍 패턴에서 마주보는 양 벽에 창이 존재한다는 정적 구조 보다는 창을 통해 바람이 들어오고 나가는 동적인 행동 양식과 그것을 통해 실내 공기를 쾌적하게 만든다는 의도가 중요하다고 할 수 있다.
 1. 홀럽 아저씨는 OO계의 진중권인듯.
  1. 책의 일부 내용으로 미루어보아 절차지향적 패러다임이 판칠때 OO를 들고 나와 절차지향의 수호자들''--절차지향으로 코드 잘 짜지도 못 하는 허접들--''과 격한 키배를 수도 없이 펼치지 않았을까…
 1. ''예측은 빗나가기 쉽다.''
 1. 무엇이든 생각없이 받아들이지 말고 장점과 단점을 모두 생각한 후에 지금 사용하기 적절한지 판단하고 적용하라는 아주 중요한 메세지가 반복되어 나온다. 다시 한번 되새기는 시간이 되었다.
==== 서지혜 ====
 * 처음에 0장에 대해 다시 얘기했는데 그새 잊었던 일을 다시 기억하게 되었다.
 * OOD와 OOP가 다르다는 것을 알았다.
 * 처음에 모든 기능을 고려하기 보다는(미래의 것까지) 기능을 확장할 수 있도록 유연하게 설계하라. 
==== 임상현 ====
 1. 밑줄 긋기를 하면서 책을 봤습니다. 그런데 처음이라 그냥 책보면서 긋던거 다 그어 버렸습니다 .
 2. 스터디 하는데 생각보다 시간이 빠르게가 아쉬웠습니다.
 3. 디자인이란 선택과 트레이드 오프, 리스크 관리의 연속이라는 점이 가슴에 와닿았습니다. 그래서 결국 자구 과제는 추가 사항이 없으므로 개판으로 짰습니다.
 4. 자구 과제를 하면서 이렇게 짜면 안되는데 이러면 코드가 개판인데 느끼고 있으면서 그렇게 밖에 할수 없는 능력이 슬펐습니다. 더 공부해서 잘짜야겠습니다.

== 4월 10일 ==
=== 후기 ===
==== 김준석 ====
 1. 1장이 끝났다. 많은 원칙에 대해 새롭게 다시 공부하게 되었는데 내가 강해지는걸(?) 느낀다!!
 1. 기본 원리를 파악하는건 매우 중요한 일이지만 정말 파악하기 어렵다는건 새삼스럽게 많이 느낀다.
==== 서지혜 ====
 1. 1장 끝
 1. 밑줄긋기를 안해서 그런지 기억에 잘 안남는다
 1. 밑줄긋기 시험 끝나고 하겠습니다.
 1. 저자는 열심히 getter와 setter를 깐다. get/set은 변수를 public으로 만드는 어려운 방법이다!
  1. 멤버변수를 선언하면 꼭꼭 getter/setter를 만들었던 나를 반성...(나중엔 귀찮아서 public으로 한적도 있다지)
==== 임상현 ====
 1. 책 1장을 이번에 다 읽었습니다. DB프로젝트 설계하는걸 구경 및 참여했습니다.
 2. 프로젝트 설계를 하는게 매우 신기했습니다. 가장 최근에 했던 프로젝트가 약 2년 전이라 하나도 모르겠는데 모듈을 잡고 그 모듈의 역활을 잡고 그에 따라 인터페이스를 만들고 하는 걸보고 생각없이 그냥 순차적으로 프로그래밍 하려고했던 제가 참 답이 없었던거 같습니다.
 3. "어떤 작업을 수행하는데 필요한 데이터를 요구하지 말라!!! 대신 정보를 가지고 있는 객체에게 일을 해달라고 부탁하라!" 항상 데이터를 get으로 꺼내와 바꿔놓고 set으로 넣어놨던 제 자신을 반성해 봅니다.
 4. DB 수업을 듣지 않아서 완전히 참여는 하지 않았지만 DB팀이 하는 프로젝트가 진행되는 모습을 계속 보고 싶습니다.
==== 김수경 ====
 1. 드디어 1장을 다 읽었다. 1장에 정말 중요한 내용이 많다는 것을 후기를 쓰려고 돌아보며 다시 한번 느낌. 이 책을 읽으면서 1장을 건너뛰고 각 패턴에 대한 설명만 찾아보는 사람이 있을 거라 생각하니 답답함. -L- 
 1. CRC 모델링에 대해 설명하는 부분에 '''도메인 영역의 언어로 문제를 기술하라'''는 말이 인상적이었다. get과 set을 사용할 필요가 없다는 걸 와닿게 하는 말이었다. 언젠가 정모에서 ''체험 OO 현장''같은 활동을 해보고 싶음. 우리 모두 객체가 되어보아Yo :)
 1. 데이터를 꺼내는 것보다 넣는 것이 좋다는 것을 진작에 생각했더라면…
== 4월 29일 ==
 * 2장 103쪽 전까지 읽어옵시다. 그리고 ["HolubOnPatterns/밑줄긋기" 밑줄을 그어요~]
=== 후기 ===
==== 김준석 ====
 1. 상속구현이 나쁘다고 말한다. 그래서 그런지 나뻐보인다. 코드가 꼬이니까.
 1. Factory Method와 Template Method 방법에대해 나쁜점을 설명하는데 Swing이 나오니까 다시 화난다. 난 Swing디자인이 싫어!!

==== 임상현 ====
 1. 상속구현이 왜 나쁜가에 대해 배웠다.
 1. 상속구현은 커플링을 늘리는 것 + 찾기 힘든 버그를 발생시키는 원인 이라 매우 슬픈거 같다. 
 1. 쩌는 형님들은 잘 쓰시겠지만 코드가 꼬이는 모습을 보니 내가 하는 상속구현은 일단 슬퍼질 가능성이 매우 높으므로 생각에 생각을 해서 쓰던가 아니면 닥치고 인터페이스 구현을 해야겠다.
==== 서지혜 ====
 1. 오랜만에 디피 스터디라 어색
 1. 오늘 스터디한 부분은 '왜 extends가 나쁜가'였다. 왜 나쁜지 예를 보았는데 와닿지 않아 이해하기 힘들었다.
 1. 홀럽에서 말하는 템플릿 메소드 패턴이랑 스프링의 템플릿 패턴은 다른가?(스프링의 패턴이 템플릿 메소드 패턴이었나?)
 1. 팩토리 메소드 패턴이 뭔지 잘 모르겠다. 기반 객체가 알지 못하는 파생 클래스를 생성한다니. 기반클래스는 원래 파생클래스를 알지 못해! 이말은 생성되는 파생클래스는 기반클래스를 '''반드시 확장해야 한다'''는 건가? 어려워.  
  1. 자바 스윙의 코드 일부를 보니 알거같기도.. 코드에서 기반클래스를 확장하는 파생 클래스가 아니라 속성이나 기능만 변경된 클래스를 구현 상속해 생성하고 있다. 
 1. 중간까지만 읽어오기 좋지 않아. ''나쁘다'' 만 듣고나니 답답하고 찜찜해. 
==== 김수경 ====
 1. 책을 다 못 읽어서 난감했다.
 1. 이번 장엔 코드가 많이 나왔는데 꼭 다시 읽어봐야겠다.

== 5월 6일 ==
 * 다음시간에는 임상현의 SE 프로젝트인 WinMerge프로젝트를 도와주겠습니다!!!
=== 후기 ===
==== 김준석 ====
 1. Factory Method, Abstract Factory Method, Template Method, Command, Strategy의 비교를 통해 상속구현의 비효율성에 대해 느꼇다.
 1. 인터페이스를 이용한 캡슐화는 참 편리하다 Java를 만든사람들은 이걸 목적에 두고 만든것일까? 
 1. 한번 짜봐야 할 필요성을 느낀다. Life Game으로 넘어가기전에.
==== 임상현 ====
==== 서지혜 ====
 1. 너무 어려웠다.
 1. 기억이 잘 안나네 책을 다시 읽고 이 후기는 고치도록 하겠습니다.
==== 김수경 ====
 1. 지난주에 헷갈렸던 Factory Method 패턴에 대해 이해할 수 있게 됐다. 
  1. Factory Method 패턴은 상속을 통해 바뀌는 부분을 오버라이딩하여 구현
  1. Strategy 패턴은 implements를 통해 바뀌는 부분을 구현하여 넘겨준다.
 1. 또 난 책을 안 읽었다........ 죄송합니다......
== 5월 13일 ==
 * 다음 범위 : 3장 173page까지 읽어오기
=== 후기 ===
==== 김수경 ====
 1. 오늘은 LifeGame으로 바로 넘어가기 전에 [임상현]의 SE 과제인 파일 비교 프로그램을 설계해보았다.
  1. MVC 모델에 맞춰 설계해야해서 [HolubOnPatterns]에서 좋다고 하는대로만 설계하지는 않음.
  1. DB 프로젝트를 시작할 때처럼 전체 아키텍쳐에서 어떤 것들이 오고가야하는지부터 생각했는데 쉽지 않았다.
  1. Block과 Line에서 어느 쪽이 실제 status를 가지고 있어야 할지가 설계의 주요 이슈였다.

==== 김준석 ====
 1. SE프로젝트에서 후회하는 부분에 대해 집어보고 갈수 있었던 유용한 시간.
  1. MVC로 나누고 Data모델을 위한 Drawable을 만드는 이유를 알것 같았다. 서로 직접적인 통신을 꼭 안해도되는군..
 1. 다시한번 보고싶은데 지금 생각해보니..?


==== 서지혜 ====
 1. 텍스트만 읽고 라이프게임으로 넘어가는 것이 현재 우리의 수준에 적절하지 못하다고 판단함.
  1. [임상현]의 {{{SE프로젝트인 '''SimpleMerge'''}}}를 구현해 보기로 하였다.
 1. '''남의 프로젝트에 감놔라 배놔라 하기 프로젝트'''를 하였다.
  1. 지난 SE 프로젝트가 기억이.. 안난다. 내가 한게 없다.. 그래서 SimpleMerge를 구현해본다 하여 반가웠다. 
   1. JUnit과 EasyMock이 핵심인 프로젝트라 TDD를 하고싶었다.
   1. 그러나 아키텍쳐 설계를 하고 나니 시간이 늦어버렸다.
   1. 아키텍쳐 설계와 그에 따른 인터페이스를 만들었다.
    1. 프로그램이 동작하는 모습을 상상해보니 아키텍쳐의 윤곽을 잡을 수 있었다.
    1. 이번 기회에 MVC가 뭔지 제대로 알았다(개념만)
    1. '''Model''' : 비즈니스 로직에 필요한 데이터들을 저장하는 클래스군.
    1. '''View''' : 유저에게 보여질 인터페이스군.
    1. '''Control''' : Model과 View 사이의 정보 교환을 제어하는 클래스군. 모델군의 데이터를 뷰가 출력하는데 용이하도록, 뷰에서 받은 데이터를 모델에게 적합하도록 가공해준다.
   1. [임상현] 엔포지에 결과물을 공유해 주세요
  1. 재미있다. 내 프로젝트가 아니라 마음놓고 끄적일 수 있었다. 굿.
   1. 과제나 프로젝트를 만들때 기능 구현에만 집중하지 말고 이렇게 스터디한 내용을 적용해보니 좋다. 뭔가 배우긴 했었구나 하는 생각이 든다.
==== 임상현 ====
 1. SE project인 merge 프로그램 디자인을 했다. MVC모델이 스팩이라 자유롭게 책에 나온걸 자유롭게 써보진 못했다.
 1. 군대갔다오니 java를 하나도 모른다. 계속 삽질해서 매우 슬펐다. 그래도 책에서 읽은 것들을 써 볼려고 하는데 머리속에서 뭔가 떠오르는 것 같지만 구현은 안되서 아쉬웠다.
 1. 일단 java를 다시 공부해야겠고 책에 나온 내용을 정말로 내껄로 쓰려면 이번처럼 활용하는 일을 계속 해봐야겠다.


----
[DesignPatterns], [스터디분류], [2011년활동지도]