imported>linflus at 13:22, 7 July 2011

2011-07-07T13:22:17Z

New page

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

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

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

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

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

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

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

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

== 5월 27일 ==
=== 후기 ===
==== 김수경 ====
==== 김준석 ====
==== 서지혜 ====
==== 임상현 ====
== 6월 3일 ==
* 다음주로 모임 미룹니다..
== 6월 10일 ==
* 다음시간에는 [[임상현]]의 SE코드 리뷰를 하겠습니다.
=== 후기 ===
==== 김수경 ====
==== 김준석 ====
==== 서지혜 ====
==== 임상현 ====
----
[[DesignPatterns/2011년스터디]]

DesignPatterns/2011년스터디/1학기 - Revision history

imported>linflus at 13:22, 7 July 2011