후기
사놓고 조금 읽고 말아서 먼지가 쌓여있던 그 책! 객체지향의 사실과 오해
최근에 사내에서 스터디를 진행하면서 끝까지 다 읽는데 성공하였다.
책을 읽어보면서 신선하게 느꼈던 부분이 참 많았던 것 같다.
책에서 객체간의 행동을 먼저 정의한 다음 상태를 결정하라는 부분을 읽었을 때는 내가 정말 오해하고 있었구나 반성이 들었다. 평소에 나는 클래스에 먼저 필드부터 만들곤 했었기 때문이었다.
또, 책에서는 도메인 모델을 설계 할때 사용자의 관점(멘탈모델)에 근접하게 설계하는 것이 중요하다는 점이 와닿았다.
도메인을 가장 잘 이해하고 있는 것은 결국 서비스를 이용하고 있는 사용자가 아니겠는가?
객체 지향이란 무엇인가?
여느 객체지향 책과 비슷하게 객체지향을 실세계에 비유한 설명을 하지만 저자는 독자가 함정에 빠지지 않게 계속 경고를 해준다.
객체지향의 목표는 실셰계를 모방하는 것이 아니라 오히려 새로운 세계를 창조하는 것이다
중요한 점은 객체는 현실 세계의 사물과 다르게 자신의 상태를 스스로 관리하는 자율적인 존재라는 것이다.
객체의 상태를 외부에 노출시키면 안되고 외부에서 직접 상태를 변경시키게 두면 안된다.
객체의 행동을 유발하는 것은 외부로 부터 전달된 메시지지만 객체의 상태를 변경할지 여부는 객체 스스로가 결정해야 한다.
행동이 상태를 결정한다
객체는 메시지를 주고 받으며 공동의 목표를 달성하기 위해 협력하는 존재들이다.
그렇기 때문에 먼저 객체의 행동을 결정하고 그 후에 행동에 적절한 상태를 선택해야한다.
상태를 먼저 정의 할 경우 캡슐화가 저해되고 객체를 협력자가 아닌 고립된 섬으로 만들게 된다.
따라서 객체의 재사용성이 저하된다.
객체의 상태를 먼저 결정하고 행동을 나중에 결정하는 방법은 설계에 나쁜 영향을 끼친다.
객체 설계
객체지향 세계를 구축하기 위해서 사용자에게 제공할 기능과 기능을 담는 안정적인 구조라는 재료가 준비되어 있어야 한다.
- 기능은 사용자가 자신의 목표를 달성하기 위해 사용할 수 있는 시스템의 서비스이다.
- 구조는 시스템의 기능을 구현하기 위한 기반으로, 기능 변경을 수용할 수 있도록 안정적이어야 한다.
안정적인 재료: 구조
도메인: 사용자가 프로그램을 사용하는 대상 분야
모델: 대상을 단순화해서 표현한 것, 복잡성을 관리하기 위해 사용하는 기본적인 도구다
도메인 모델: 소프트웨어 개발과 관련된 이해관계들이 도메인에 대해 생각하는 관점
- 도메인 모델은 이해관계자들이 바라보는 멘탈 모델(Mental Model)이다.
- 멘탈 모델이란 사람들이 자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형이다
- 도메인 모델은 문서나 다이어그램이 아니라 사람들의 머릿속에 들어있는 공유된 멘탈 모델이다.
멘탈 모델
- 사용자 모델: 사용자가 제품에 대해 가지고 있는 개념들의 모습
- 디자인 모델: 설계자가 마음 속에 갖고 있는 시스템에 대한 개념화
- 시스템 이미지: 최종 제품
객체지향을 이용하면 도메인에 대한 사용자 모델, 디자인 모델, 시스템 이미지가 모두 유사한 모습을 유지하도록 만드는 것이 가능하다. 객체지향의 이러한 특징을 연결완전성, 또는 표현적 차이라고 한다.
표현적 차이
소프트웨어 객체가 현실 객체를 왜곡한다고 하더라도 소프트웨어 객체는 현실 객체의 특성을 토대로 구축된다. 이처럼 소프트웨어 객체와 현실 객체 사이의 의미적 거리를 가리켜 표현적 차이 또는 의미적 차이라고 한다.
💡 소프트웨어 객체를 창조하기 위해 우리가 은유해야 하는 대상은 바로 도메인 모델이다.
도메인 모델의 핵심은 사용자가 도메인을 바라보는 관점을 반영해 소프트웨어를 설계하고 구현하는 것이다.
도메인에 대한 사용자의 관점을 반영해야 하는 이유는 사용자들이 누구보다도 도메인의 ‘본질적인’ 측면을 가장 잘 이해하고 있기 때문이다.
- 본질적이라는 것은 변경이 적고 비교적 그 특성이 오랜 시간 유지된다는 것을 의미한다.
불안정한 재료: 기능
비록 도메인 모델이 도메인과 관련된 중요한 개념과 관계를 보여준다고 해도 실제로 사용자에게 중요한 것은 도메인 모델이 아니라 소프트웨어의 기능이다.
유스케이스
사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것을 유스케이스라고 한다.
- 유스케이스는 사용자와 시스템 간의 상호작용을 일련의 이야기 흐름으로 표현하는 것이다.
- 유스케이스는 하나의 시나리오가 아니라 여러 시나리오들의 집합이다.
- 유스케이스는 단순한 피쳐(feature) 목록과 다르다.
- 피처는 시스템이 수행해야 하는 기능의 목록을 단순하게 나열한 것이다.
- 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다.
- 유스케이스는 내부 설계와 관련된 정보를 포함하지 않는다.
유스케이스는 설계 기법도, 객체지향 기법도 아니다
유스케이스는 단지 사용자가 바라보는 시스템의 외부 관점만을 표현한다.
유스케이스는 시스템의 내부 구조나 실행 매커니즘에 관한 어떤 정보도 제공하지 않는다.
객체지향 설계 관점
개념 관점(Conceptual Perspective): 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현한다. 이 관점은 사용자가 도메인을 바라보는 관점을 반영한다.
명세 관점(Specification Perspective): 도메인의 개념이 아니라 객체의 인터페이스를 바라보는 것이다. 명세 관점에서 프로그래머는 객체가 협력을 위해 ‘무엇’을 할 수 있는가에 초점을 맞춘다.
구현 관점(Implementation Perspective): 객체들이 책임을 수행하는 데 필요한 동작하는 코드를 작성하는 것이다. 따라서 프로그래머는 객체의 책임을 ‘어떻게’ 수행할 것인가에 초점을 맞추며 인터페이스를 구현하는 데 필요한 속성과 메서드를 클래스에 추가한다.
💡 협력 안에서 메시지를 선택하고 메시지를 수신할 객체를 선택하는 것은 객체의 인스턴스, 즉 명세 관점에서 객체를 바라보는 것이다.
연관 관계: 한 타입의 인스턴스가 다른 타입의 인스턴스틀 포함하지는 않지만 서로 알고 있어야 할 경우
객체지향 설계의 첫 번째 목표는 훌륭한 객체를 설계하는 것이 아니라 훌륭한 협력을 설계하는 것이다.
결국 세 가지 관점 모두에서 클래스를 바라볼 수 있으려면 훌륭한 설계가 뒷받침돼야 한다.
