HolubOnPatterns/밑줄긋기

소프트웨어 설계의 고고학

설계 원칙

• p.1
  • 복싱에서는 스트레이트, 잽, 훅, 이 세가지 펀치를 기반으로 다른 모든 종류의 펀치가 나온다고한다. ~~~ 이러한 기본 자세가 튼튼하다면 그만큼 다른 펀치를 배우는 데도 진입 장벽이 낮아지기 때문이다.
  • 스포츠를 사용해서 비유를 하는건 쉽게 이해는 되는데, 항상 별로 재미없어. - 김준석

의존관계

• p.3
  • 슬프게도 개발자 입장에서는 의사 결정에 참여하여 변경에 대한 요구를 막지 못하는 것이 대부분이다.
    • 요구사항의 변경같은경우 어쩔수 없지만 기술적인 부분이라면 개발자가 가장 힘있지 않나? - 김준석

OO와 디자인패턴 기초 다지기

패턴 vs 이디엄

• p.22
  • 이디엄은 일상적으로 사용하게 된 패턴이다.
  • 지난주엔 이 말 떄문에 혼란스러웠는데 책에서 다시 보니 왜 혼란스러웠는지 모르겠어요. - 김수경
    • 난 책보고도 이상한 말이라는 생각밖에 안드는군. - 김준석
  • 1980년대 초 C언어가 왕이었을 무렵 상속은 하나의 디자인 패턴이었다.
  • 지금은 이디엄이 되어 누구나 아무 생각 없이 사용하는 상속이 패턴이었다는 사실도 재미있고 C언어가 왕이었다는 표현도 재미있네요. - 김수경

디자인패턴이란 무엇인가?

• p.22
  • 먼저 패턴은 발명되는 것이 아니라 발견되는 것이라는 사실을 이해해야만 한다.
• p.23
  • 그러므로 패턴은 해결 방법 그 자체라기보다는 해결 방법의 일반 구조라 할 수 있다.
  • 패턴은 어떤 류의 문제를 해결하기 위해 사용되는 일반적인 기술이다.
  • 패턴은 이와 같이 일반적인 해결 방법이기 때문에 한 프로그램에서 다른 프로그램으로 디자인패턴을 복사해 붙여넣는 것은 거의 불가능하다.
  • 그들은 패턴 자체를 패턴을 설명하기 위해 사용한 코드와 혼동하고 있는 것이다.
• p.24
  • 현실에서는 한 패턴에 참여하고 있는 객체와 클래스가 동시에 다른 패턴에서도 사용되는 경우가 매우 많다.
  • 패턴에 입문한 지 얼마 안 되는 초보자일수록 무언가 멋져 보이는 클래스 다이어그램에 관심을 쏟는데, 더욱 중요한 것은 '패턴의 의도'(혹은 목적)와 '동적인 행동양식'이다.
  • '동적인 행동양식'이 무엇인지 잘 감이 오지 않네요. - 김수경
    • '동적인 행동양식'은 패턴을 통한 목적 달성에 이루기까지 흐름이 어떻게 이루어지는지에 대한것 같아 -김준석
  • 시원하면서도 안락한 느낌을 주는 방들을 살펴보면 앞으로 '교차 통풍'이라 부를 패턴이 창발한다.
  • 강의실에서 공대 냄새가 나는 이유를 알았습니다. 강의실은 '교차 통풍' 패턴에 속하지 않아요. - 김수경
    • 하긴 시원하면서도 안락하지 않은게 공대 강의실이지 - 김준석
  • 이 의도를 만족시킨다면 어떤 구조든 이 패턴의 합당한 실체화가 된다.
• p.25
  • 패턴의 실체화는 디자인이지 코드가 아니며, 하나의 디자인은 여러 가지 합당한 방법으로 구현할 수 있다.
  • 패턴의 실체화 방식은 다양하지만 여러분이 좋아하는 요소만 쏙 뽑아 사용할 수는 없다.
• p.26
  • 남서쪽 창은 두 개의 패턴 모두에 참여하고 있다는 점에서 흥미롭다.
• p.27
  • 중요한 것은 구조를 통해서만 패턴을 파악하는 것이 불가능하다는 사실을 이해하는 것이다.
  • 패턴을 찾아내려면 아키텍처의 의도를 포함한 문맥 정보가 필요하다.
  • 생각 없이 패턴을 복사하고 붙여넣는 것은 마음대로 낙서를 한 뒤 멋진 그림을 주장하는 것과 같은 우매한 것이다.
  • 나도 이런적이 있었지 패턴을 쓴다고 다 좋아지는게 아니니까 - 김준석
  • 패턴은 디자인으로 실체화 되고 디자인은 구현으로 실체화 된다.
  • 구현은 추상화 시켜 디자인이되고 그것을 추상화시켜서 패턴이된다 - 김준석

패턴, 무엇이 좋은가?

• p.28
  • 즉 패턴을 사용하지 않고 설명하는 것보다 훨씬 짧고 훨씬 명확했다.
• p.29
  • 패턴은 커뮤니케이션을 극적으로 향상시켜주는 유기적 프레임워크를 제공하며 결국 이것이 디자인의 모든 것이다.

디자인에서 패턴의 역활

• p.29
  • 패턴은 구현에 대해 생각하기 시작할 때 등장하게 된다.
• p.30
  • 디자인 패턴은 보통 디자인 문서에 상세히 나타나지는 않으며 구현하는 사람이 내리는 결정을 나타내 준다.

디자인에서 패턴의 역활

• p.30
  • '우둔한 프로그래머와 아키텍처'는 패턴이 항상 좋은 것이며 가능한 모든 곳에서 사용해야 한다고 일관되게 믿는다.
• p.31
  • 미래에 변화될 것이라 생각하기 때문에 코드를 복잡하게 하는 것은 좋은 생각이 아니다.(적어도 내 경우는 미래를 예측하려 할때마다 내 예상이 빗나갔다.)
  • 요구되는 기능을 삭제하는 것은 불필요한 기능을 추가하는 것만큼 나쁘다.
  • 요구되는 기능을 왜 삭제하는가? 요구되는 기능을 구현하는게 우리 일 아닌가? -임상현
  • 사용자가 무언가를 정말로 하고 싶어한다면 이에 대해 질문하지 말아야 한다고 주장한다.
  • 확실히 근근히 나오는 확인 팝업창 겁나 귀찮습니다. -임상현
• p.32
  • 단순함 , 완전성 그리고 수정의 용이성이란 세가지 요구 사항은 상충되기도 한다.
  • 인터페이스는 패턴 전체를 도입하는 것과는 달리 그다지 복잡성을 증가시키지 않는다. 반면 기능 변경이나 추가 시 리팩토링이 쉬워진다.

패턴 분류하기

• p.32
  • 패턴을 분류하는 것은 필요한 상황에서 적절한 패턴을 선택하는 것을 용이하게 해준다는 점에서 유용하다.
• p.34
  • 패턴들이 서로 의존하고 있다는 사실을 이해하는 것도 중요하다.
  • 여러 패턴들이 서로 관련이 있으며 실제 프로그래밍할 때는 이들을 엮어 함께 사용하는 경우가 많다는 사실만 명심하면 된다.
• p.34
  • 패턴 간의 연관성 의존성 때문에 한 패턴을 다른 패턴과 구분하기 어려울 수도 있다. 이럴 경우에는 정적 구조 대신 패턴의 의도에 초점을 맞추기 바란다.

자바를 C언어 스타일로 프로그래밍하기

• p.37
  • 절차 지향 프로그래밍은 데이터를 조작 혹은 검토하는 서브루틴 간의 데이터 흐름을 구조화 한다.
  • 사실 많은 절차 지향적 프로그램은 사용자 인터페이스를 통해 데이터베이스 테이블을 보여주는 역할을 할 뿐이다.
  • 객체 지향 시스템은 상호 협동하는 에이전트들의 네트워크이며, 에이전트는 메시지를 통해 통신한다.
  • 절차 지향 시스템에서는 변화가 프로그램의 나머지에 '퍼저나가는'경향이 있다.
  • 객체 지향 시스템에서는 변화가 한곳에 집중되는 경향이 있다.
• p.40
  • 절차 지향적 해결 방법이 본질적으로 나쁜 것은 아니다. 하지만 선택을 할 때는 이 선택에 따르는 위험까지 고려해 보기 바란다.

열린 눈으로 프로그래밍하기

• p.40
  • 디자인은 선택화 트레이드 오프, 리스크 관리의 연속이다.
  • 자신이 하고 있는 일이 어떤 결과를 초래할지를 알지 못한다면 이는 디자인을 하고 있는 것이 아니라 어둠 속에서 비틀거리고 있을 뿐이다.
• p.41
  • 어떤 언어의 기능 혹은 이디엄이 초래할 수 있는 폐해를 이해하면 해당 기능과 이디엄을 사용하는 것이 적절한지 아닌지 좀 더 현명하게 결정할 수 있다.

소형 데이터베이스 구현하기

---

HolubOnPatterns, DesignPatterns/2011년스터디