More actions
소프트웨어 설계의 고고학
설계 원칙
- p.1
- 복싱에서는 스트레이트, 잽, 훅, 이 세가지 펀치를 기반으로 다른 모든 종류의 펀치가 나온다고한다. ~~~ 이러한 기본 자세가 튼튼하다면 그만큼 다른 펀치를 배우는 데도 진입 장벽이 낮아지기 때문이다.
- 스포츠를 사용해서 비유를 하는건 쉽게 이해는 되는데, 항상 별로 재미없어. - 김준석
의존관계
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
- 어떤 언어의 기능 혹은 이디엄이 초래할 수 있는 폐해를 이해하면 해당 기능과 이디엄을 사용하는 것이 적절한지 아닌지 좀 더 현명하게 결정할 수 있다.
객체란 무엇인가?
허튼소리!
객체는 기능의 집합이다
어떻게 잘못하고 있는가?
어떻게 '올바르게' 할 수 있는가?
- p.48
- 만약 빌 게이츠가 은행에 걸어들어와 계좌를 개설한 뒤 그의 모든 재산을 예금하겠다고 하면 어떻게 될까? 여러분이 은행 지점장이라면 절대 빌이란 고객을 놓치고 싶지 않을 것이다.
- 역시 빌게이. 돈의 힘이란. -김준석
- 만약 빌 게이츠가 은행에 걸어들어와 계좌를 개설한 뒤 그의 모든 재산을 예금하겠다고 하면 어떻게 될까? 여러분이 은행 지점장이라면 절대 빌이란 고객을 놓치고 싶지 않을 것이다.