예제보다는 책을 읽으면서 핵심적이고 정리할만한 문구, 내용들만 적어둘 예정
이 책의 목적
프로그래밍 패러다임은 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다. 또한 프로그래밍 패러다임을 교육시킴으로써 동일한 규칙과 방법을 공유하는 개발자로 성장할 수 있도록 준비시킬 수 있다.
프로그래밍 패러다임은 (과학에서의 패러다임과 달리) 과거의 패러다임을 폐기시키지 않는다. 오히려 과거에 있던 패러다임의 단점을 보완하는 발전적인 과정을 거친다. 혁명적이라기보단 발전적이다.
이는 객체지향 패러다임을 주로 사용한다고 하더라도 다른 패러다임을 배우는 것이 도움이 될 것이라는 사실을 암시한다.
(물론 그 반대도 성립할 것)
소프트웨어 설계에 있어 실무는 이론에 선행한다. 이론도 결국 실무에서 관찰한 결과를 바탕으로 정립한 것 뿐이다. 따라서 이 책에서는 이론보다는 코드를 중심으로 설명한다.
모듈의 조건
- 제대로 실행되야 한다.
- 변경에 용이해야 한다.
- 이해하기 쉬워야 한다.
- 자율적인 객체를 만들면 결합도를 낮추고 응집도를 높일 수 있다.
- 핵심은 다른 객체의 내부에 직접 관여하지 않고 오직 메시지(함수)로만 상호작용 하는 것
훌륭한 객체지향 설계란
불필요한 세부사항을 캡슐화하는 자율적인 객체들이 낮은 결합도와 높은 응집도를 가지고 협력하도록 최소한의 의존성만을 남기는 것
그런데 이 '자율적인 객체'와 '최소한의 의존성'은 트레이드 오프 관계가 되기도 한다.
(예제 p.30~33 을 찾아 보면 잘 이해할 수 있다)
이를 통해 두 가지를 알 수 있다.
- 어떤 기능을 설계하는 방법은 두 가지 이상일 수 있다.
- 동일한 기능을 한 가지 이상의 방법으로 설계할 수 있기 때문에 결국 설계는 트레이드 오프의 산물이다. 어떤 경우에도 '모든 사람을 만족하는 설계'를 만들 수는 없다.
설계는 균형의 예술이다. 훌륭한 설계는 적절한 트레이드오프의 결과물이라는 사실을 명심하라. 이러한 트레이드 오프 과정이 설계를 어려우면서도 흥미진진한 작업으로 만드는 것이다.
p.33
객체지향에서의 의인화
책의 예제에서는 가방, 매표소 같은 무생물도 마치 스스로 행동하고 자신을 책임지는 자율적인 존재로 취급했다. 비록 현실에서는 수동적인 존재라고 하더라도 객체지향의 세계에서는 모든 것이 능동적이고 자율적인 존재로 바뀐다.
좋은 설계란 ?
- 설계를 구현과 떨어뜨려서 이야기 하는 것은 불가능하다. 설계는 코드 작성의 일부이며 코드를 작성하지 않고서는 검증할 수 없다.
- 오늘 요구하는 기능을 온전히 수행하면서 내일의 변경을 매끄럽게 수용할 수 있는 것이 좋은 설계다.
- 변경을 수용할 수 있는 것이 중요한 이유는 요구사항이 항상 변경되기 때문이다.
- 개발을 시작하는 시점에 필요한 모든 요구사항을 수집하는 것은 불가능에 가깝다.
- 또한 변경에 용이하지 않은 구조는 버그를 유발할 수 있기 때문
정상적으로 동작하면서 변경에 용이하다는 이 개념은 앞에서 나오는 모듈의 조건과도 맥이 닿는다.
- 그런 의미에서 객체지향은 의존성을 효율적으로 통제할 수 있는 다양한 방법을 제공함으로써 요구사항 변경에 좀 더 수월하게 대응할 수 있는 가능성을 높여준다.
- 변경 가능한 코드란 이해하기 쉬운 코드다. (클린코드)
1장 정리
객체지향은 '데이터 + 프로세스' 단위로 이루어진 여러 자율적인 객체들이 메시지를 통해 상호작용하는 구조다. 이렇게 협력하고 상호작용하는 과정 속에서 객체 간의 의존 관계는 불가피하다. 훌륭한 객체지향 설계는 (의도한대로 동작하는 동시에) 의존성을 줄여 '변경에 용이한' 구조를 제공하는 설계다.
책에서는 변경을 위한 유연함을 집중적으로 강조하고 있긴 한데, 그 만큼 확실하지도 않은 미래의 변경 때문에 확장을 염두에 둔 복잡한 패턴만 지향하는 것도 옮지 않다고 봄.
책에서도 '변경 가능한 코드란 이해하기 쉬운 코드다, 코드 변경에 유연하다고 하더라도 이해하기 힘들다면 코드를 수정하겠다는 마음이 선뜻 들지 않을 것이다' 라고 표현하고 있음그 적절함의 '정도'를 찾는 것이 어렵기 때문에 설계라는 것이 쉽지 않은 것 같다.
