객체지향의 사실과 오해 7장 정리

본 글은 스터디 내에서 객체지향의 사실과 오해 - 역할, 책임, 협력 관점에서 본 객체지향을 읽고 정리한 글입니다.

---

​

개념 관점: 설계는 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현한다.

 

명세 관점: 인터페이스와 구현을 분리해야 한다.

 

구현 관점: 객체들이 책임을 수행하는 데 필요한 동작하는 코드를 작성하는 것이다.

 

포함 관계 또는 합성 관계: 예시) 메뉴판 타입과 메뉴 항목 타입 간의 관계

 

연관 관계: 한 타입의 인스턴스가 다른 타입의 인스턴스를 포함하지는 않지만, 서로 알고 있어야 할 경우

 

도메인 모델: 소프트웨어가 대상으로 하는 영역인 도메인을 단순화해서 표현한 모델

 

인터페이스 정리하기

 

객체가 수신한 메시지가 객체의 인터페이스를 결정한다.

객체가 어떤 메시지를 수신할 수 있다는 것은 그 객체의 인터페이스 안에 메시지에 해당하는 오퍼레이션이 존재한다.

인터페이스에 포함된 오퍼레이션 역시 외부에서 접근 가능하도록 공용(public)으로 선언돼 있어야 한다.

 

구현하기

 

구현 도중에 객체의 인터페이스가 변경될 수 있다.

협력을 구상하는 단계에 너무 오랜 시간을 쏟지 말고, 최대한 빨리 코드를 구현해서 설계에 이상이 없는지 설계가 구현 가능한지를 판단해야 한다.

 

객체의 속성은 객체의 내부 구현에 속하기 때문에 캡슐화 되어야 한다.

인터페이스를 정하는 단계에서 객체가 어떤 속성을 갖는지, 속성이 어떤 자료 구조로 구현됐는지를 고려하지 않는 것이다.

설계를 간단히 끝내고 최대한 빨리 구현에 돌입하라.

 

코드와 세 가지 관점

코드는 세가지 관점을 모두 제공해야 한다.

 

개념 관점: 소프트웨어 클래스와 도메인 클래스 사이의 간격이 좁으면 좁을수록 기능을 변경하기 위해 뒤적거려야 하는 코드의 양도 줄어든다.

 

명세 관점: 클래스의 인터페이스를 바라본다. 객체의 인터페이스는 수정하기 어렵다. 인터페이스를 통해 구현과 관련된 세부 사항이 드러나지 않도록 해야한다.

 

구현 관점: 클래스의 내부 구현을 바라본다. 메서드의 구현과 속성의 변경은 원칙적으로 외부 객체에게 영향을 미쳐서는 안된다.

 

도메인 개념을 참조하는 이유

도메인 개념 안에서 적절한 객체를 선택하는 것은 도메인에 대한 지식을 기반으로 코드의 구조와 의미를 쉽게 유추할 수 있게 한다.

 

소프트웨어는 항상 변한다.

여러 개의 클래스로 기능을 분할하고 클래스 안에서 인터페이스와 구현을 분리하는 이유는 변경이 발생했을 때 코드를 좀 더 수월하게 수정하기를 바라기 때문이다.

 

인터페이스와 구현을 분리하라

명세 관점은 클래스의 안정적인 측면을 드러내야 한다.

구현 관점은 클래스의 불안정한 측면을 드러내야 한다.