객체지향의 사실과 오해 5 ~ 7장

바로 시작하겠습니다.

5장. 책임과 메세지

• 요청(메시지)를 처리하기 위해 객체가 수행하는 행동을 책임이라고 한다.
  즉 메서드란 메시지를 수신했을 때 책임을 수행하는 방법이다.
• 자율적인 객체란 스스로의 의지와 판단에 따라 각자 맡은 책임을 수행하는 객체이다.
• 객체지향 세계는 자율적인 객체들의 공동체다. 객체가 자율적이기 위해서는 객체에게 할당되는 책임의 수준 역시 자율적이어야 한다.
  필자는 이 말이 의존성이 너무 많거나 강한 의존이 존재하면 안 좋다는 말로 이해했다.
• 자율적인 책임의 특징은 객체가 어떻게(how) 해야 하는가가 아니라 무엇(what)을 해야 하는가를 설명한다는 것이다.
• 다형성이란 서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것을 의미한다.
• 객체지향 패러다임이 강력한 이유는 다형성을 이용해 협력을 유연하게 만들 수 있기 때문이라는 점을 기억하자.
• 객체지향의 세계에서 객체들이 서로 협력하기 위해 사용할 수 있는 유일한 방법은 메시지를 보내는 것이다.
  참고로 메시지란 메시지 이름과 인자의 조합이다. 또한 메시지 전송은 수신자와 메시지의 조합이다.
• 객체가 메시지를 선택하는 것이 아니라, 메세지가 객체를 선택하는 것이다.
• 객체의 인터페이스는 객체가 수신할 수 있는 메시지의 목록으로 구성되며 객체가 어떤 메시지를 수신할 수 있는지가
  객체가 제공하는 인터페이스의 모양을 빚는다.
• 객체가 가져야 할 상태와 메서드 구현은 객체의 내부다. 객체의 외부는 공용 인터페이스다.
  쉽게 말해 객체가 외부로부터 메시지를 수신할 수 있는 목록이다.

6장. 객체 지도

• 객체지향 개발에는 두 가지가 필요하다. 바로 사용자에게 제공할 기능과 기능을 담을 안정적인 구조다.
  책에서는 객체지향을 위한 안정적인 재료는 구조이고 불완전한 재료는 기능이라고 말하고 있다.
• 사용자가 프로그램을 사용하는 대상 분야를 도메인이라고 한다. (게임, 병원 진료, 은행)
  이전에 필자는 도메인을 소프트웨어를 사용해 해결하고자하는 문제 영역이라고 들었다. 책과 들은 내용이 일치하는 것 같다.
• 도메인 모델이란 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태다.
  도메인 모델은 소프트웨어 개발과 관련된 이해관계자들이 도메인에 대해 생각하는 관점이다.
• 도메인 모델은 단순 다이어그램이 아닌 멘탈 모델(자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형)이다.
• 도메인 모델의 핵심은 사용자가 도메인을 바라보는 관점을 반영해 소프트웨어를 설계하고 구현한다.
  사용자들은 도메인을 구성하는 중요한 개념과 개념 간의 관계를 가장 잘 알고 있는 사람들이기 때문이다.
• 사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것을 유스케이스라고 한다.
• 유스케이스의 가치는 사용자들의 목표를 중심으로 시스템의 기능적인 요구사항들을 이야기 형식으로 묶을 수 있다는 점이다.
• 불안정한 기능을 안정적인 구조에 담음으로써 변경에 대한 파급효과를 최소화하는 것은 훌륭한 객체지향 설계자가 갖춰야 할 기본적인 설계 능력이다.
• 도메인 모델은 안정적인 구조를 개념화하기 위해, 유스케이스는 불안정한 기능을 서술하기 위해 가장 일반적으로 사용되는 도구다.
• 예제에서 정기 예금, 계좌, 이자율 같은 개념을 스스로 상태와 행위를 관리하는 자율적인 객체로 간주하는 예시가 인상 깊었다.
  이자는 이자율에 의해 생성되며, 이자를 계산하는 책임을 가진 객체는 이자율이다. 라는 내용이 아주 좋았다.

7장. 함께 모으기

• 협력 안에서 메시지를 선택하고 메시지를 수신할 객체를 선택하는 것은 객체의 인터페이스,
  즉 명세 관점(객체들의 책임)에서 객체를 바라보는 것이다.
• 다시 한 번 강조!! 객체지향 설계의 첫 목표는 훌륭한 객체를 설계하는 것이 아니라 훌륭한 협력을 설계하는 것이다.
  훌륭한 협력을 설계하면 자동으로 따라오는 것이 훌륭한 객체다.
• 메시지를 먼저 선택하고 그 후에 메시지를 수신하기에 적절한 객체를 선택해야 한다.
• 예시를 들자면 커피를 주문한다. 라는 메시지를 먼저 정하고 커피를 주문할 객체를 정한다.
  그럼 이제 커피를 주문한다라는 메시지를 처리할 객체는 손님 타입의 인스턴스로 정한다.
• 설계에 너무 많은 시간을 쏟지 말고 일단 코드로 작성(구현)하고 코드를 바탕으로 한 피드백을 통해 수정을 하자.
• 어떤 메시지가 있을 때 그 메시지를 수신할 객체를 선택하는 방법은 도메인 개념에서 제일 적절한 것을 택하는 것이다.
• 반드시 인터페이스와 구현을 분리하자.

마지막 7장에서 도메인 간의 관계를 나타내는 도메인 모델이 한 눈에 설계를 확인하기 좋았다. 자주 참고해야겠다.

찜찜해서 7장까지 다 읽고 다시 미션에 도전하려고 한다. 메시지를 먼저 설계하는 것으로..! 나 자신 파이팅!!! 

정말 좋은 객체지향 관련 서적이라는 것을 느끼면서 종종 다시 읽어야겠다고 느꼈다. 많은 것을 다시 배우고 복습해서 기분이 좋다.

 

이상으로 포스팅을 마칩니다. 감사합니다.

 

참고 문헌

객체지향의 사실과 오해 (저자: 조영호)