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
- 패턴 간의 연관성 의존성 때문에 한 패턴을 다른 패턴과 구분하기 어려울 수도 있다. 이럴 경우에는 정적 구조 대신 패턴의 의도에 초점을 맞추기 바란다.
디자인 일반
- p.35
- 객체 지향 디자인(OOD)과 객체 지향 프로그래밍(OOP)은 매우 다른것이다.
- 디자인 프로세스는 유스케이스 분석등을 통한 요수사항 수집에서 시작해 코딩이 시작되는 디자인으로 끝나게 된다.
- 프로그래밍 프로세스는 디자인에서 시작하며 상속, 캡슐화, 디자인 패턴 등을 이용하고 디자은의 실체인 컴퓨터 프로그램을 내놓는다.
- 이와같은 기술의 융합은 애자일(Agile) 방법론에서 특히 중요한데 디자인과 코딩이 병렬적으로 진행되기 때문이다.
- 애자일을 하려면 디자인, 코딩을 둘다 할줄 알아야 하나.. - 서지혜
- 어떤 애자일 방법론도 춤추는 꼭두각시 프로그래머와 이를 조종하는 아키텍트란 도식을 지지하지 않는다.
자바를 C언어 스타일로 프로그래밍하기
- p.37
- 절차 지향 프로그래밍은 데이터를 조작 혹은 검토하는 서브루틴 간의 데이터 흐름을 구조화 한다.
- 사실 많은 절차 지향적 프로그램은 사용자 인터페이스를 통해 데이터베이스 테이블을 보여주는 역할을 할 뿐이다.
- 객체 지향 시스템은 상호 협동하는 에이전트들의 네트워크이며, 에이전트는 메시지를 통해 통신한다.
- 절차 지향 시스템에서는 변화가 프로그램의 나머지에 '퍼저나가는'경향이 있다.
- 객체 지향 시스템에서는 변화가 한곳에 집중되는 경향이 있다.
- p.40
- 절차 지향적 해결 방법이 본질적으로 나쁜 것은 아니다. 하지만 선택을 할 때는 이 선택에 따르는 위험까지 고려해 보기 바란다.
열린 눈으로 프로그래밍하기
- p.40
- 디자인은 선택과 트레이드 오프, 리스크 관리의 연속이다.
- 자신이 하고 있는 일이 어떤 결과를 초래할지를 알지 못한다면 이는 디자인을 하고 있는 것이 아니라 어둠 속에서 비틀거리고 있을 뿐이다.
- p.41
- 어떤 언어의 기능 혹은 이디엄이 초래할 수 있는 폐해를 이해하면 해당 기능과 이디엄을 사용하는 것이 적절한지 아닌지 좀 더 현명하게 결정할 수 있다.
객체란 무엇인가?
허튼소리!
- p.42
- 우선 OO 시스템을 지능 있는 동물(객체)의 모임이라 생각하자.
- OO 디자인에서 가장 중요한 원리는 데이터 추상화이다.
- "객체는 메소드라 불리는 함수가 있는 자료 구조이며 메소드가 자료 구조를 조작한다."라는 설명을 보았을지도 모르겠다. 허튼소리! 당치 않다.
- 봉봉 생각나! 봉봉도 그책을 읽은게 아닐까?- 김준석
객체는 기능의 집합이다
- p.43
- 켄 아놀드는 다음과 같이 말한다. "정보가 아닌 도움을 요청하라(Ask for help, not for information)."
- 이건 굉장한 개념이야!!! 너! 일해! -김준석
어떻게 잘못하고 있는가?
- p.45
- 이러한 룰을 따르면 문제점을 고치거나 새로운 기능을 추가함으로써 발생하는 변화가 한곳에 집중된다. 이때 유지 보수가 용이하다는 것과 복잡하지 않다는 것을 혼동하지 말기 바란다.
어떻게 '올바르게' 할 수 있는가?
- p.48
- 만약 빌 게이츠가 은행에 걸어들어와 계좌를 개설한 뒤 그의 모든 재산을 예금하겠다고 하면 어떻게 될까? 여러분이 은행 지점장이라면 절대 빌이란 고객을 놓치고 싶지 않을 것이다.
- 역시 빌게이. 돈의 힘이란. -김준석
- 만약 빌 게이츠가 은행에 걸어들어와 계좌를 개설한 뒤 그의 모든 재산을 예금하겠다고 하면 어떻게 될까? 여러분이 은행 지점장이라면 절대 빌이란 고객을 놓치고 싶지 않을 것이다.