객체지향의 사실과 오해(2)

4장. 역할, 책임, 협력 🚢

책임

  책임은 객체지향 설계의 품질을 결정하는 가장 중요한 요소이다. 객체지향 설계의 예술은 적절한 객체에게 적절한 책임을 할당하는 데 있다.

  설계를 시작하는 초반에는 어떤 객체가 어떤 책임을 가지고 어떤 방식으로 서로 협력해야 하는지에 대한 개요를 아는 것만으로도 충분하다. 책임과 협력의 구조가 자리를 잡기 전까지는 책임을 구현하는 방법에 대한 고민을 잠시 뒤로 미뤄두자.

역할

  어떤 객체가 수행하는 책임의 집합은 객체가 협력 안에서 수행하는 역할을 암시한다.

  역할은 재사용 가능하고 유연한 객체지향 설계를 낳는 매우 중요한 구성요소이다.

  역할의 개념을 사용하면 유사한 협력을 추상화할 수 있다. 그리고 다양한 객체들이 협력에 참여할 수 있기 때문에 협력이 좀 더 유연해지며 다양한 객체들이 동일한 협력에 참여할 수 있어서 재사용성이 높아진다. 그래서 역할은 객체지향 설계의 단순성(simplicity), 유연성(flexibility), 재사용성(reusability)을 뒷받침하는 핵심 개념이다.

 

5장. 책임과 메시지 📂

메시지

  메시지는 송신자와 수신자 사이의 결합도를 낮춤으로써 설계를 유연하고, 확장 가능하고, 재사용 가능하게 만든다.

What/Who 사이클

  객체 사이의 협력 관계를 설계하기 위해서는 '어떤 행위(what)'를 수행할 것인지를 결정한 후에 '누가(who)' 그 행위를 수행할 것인지를 결정해야 한다. 여기서 '어떤 행위'가 바로 메시지다.

  객체가 어떤 메시지를 수신하고 처리할 수 있느냐가 객체의 책임을 결정한다. 책임-주도 설계 방법에서는 What/Who 사이클에 따라 협력에 참여할 객체를 결정하기 전에 협력에 필요한 메시지를 먼저 결정한다. 메시지가 결정된 후에야 메시지를 수신할 후보를 선택하는 것으로 초점이 이동한다.

객체의 인터페이스 세 가지 원칙

1. 좀 더 추상적인 인터페이스
     지나치게 상세한 수준의 메시지를 보내는 것은 객체의 자율성을 저해한다.
2. 최소 인터페이스
     외부에서 사용할 필요가 없는 인터페이스는 최대한 노출하지 말라. 이렇게 하면 객체의 내부를 수정하더라도 외부에 미치는 영향을 최소화할 수 있다.
3. 인터페이스와 구현 간에 차이가 있다는 점을 인식
     '인터페이스와 구현의 분리(separation of interface and implementation) 원칙'은 변경을 관리하기 위한 것이다. 인터페이스와 구현을 분리한다는 것은 변경될 만한 부분을 객체의 내부에 꽁꽁 숨겨 놓는다는 것을 의미한다.

책임의 자율성이 협력의 품질을 결정한다.

1. 자율적인 책임은 협력을 단순하게 만든다.
     자율적인 책임은 세부적인 사항들을 무시하고 의도를 드러내는 하나의 문장으로 표현함으로써 협력을 단순하게 만든다. - 추상화
2. 자율적인 책임은 모자 장수의 외부와 내부를 명확하게 분리한다.
     요청하는 객체가 몰라도 되는 사적인 부분이 객체 내부로 캡슐화되기 때문에 인터페이스와 구현이 분리된다.
3. 책임이 자율적일 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않는다.
     변경의 파급효과가 객체 내부로 캡슐화되기 때문에 두 객체 간의 결합도가 낮아진다.
4. 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다. 
     설계가 유연해지고 재사용성이 높아진다.
5. 객체가 수행하는 책임들이 자율적일수록 객체의 역할을 이해하기 쉬워진다.
     책임이 자율적일수록 객체의 응집도를 높은 상태로 유지하기가 쉬워진다.

 

6장. 객체 지도 🌍

구조

  객체지향은 객체의 구조에 집중하고 기능이 객체의 구조를 따르게 만든다. 시스템 기능은 더 작은 책임으로 분할되고 적절한 객체에게 분배되기 때문에 기능이 변경되더라도 객체 간의 구조는 그대로 유지된다.

 

7장. 함께 모으기 ⛳

  해당 장에서는 커피 전문점에서 커피를 주문하는 과정을 객체지향 관점에서 설계해 보고 이를 '개념 관점', '명세 관점', '구현 관점'에서 살펴본다.

• 개념 관점(Conceptual Perspective)
  개념관점에서 설계는 도메인 안에 존재하는 개념과 개념 사이의 관계를 표현한다.
• 명세 관점(Specification Perspective)
  명세 관점은 도메인의 개념이 아니라 실제 소프트웨어 안에서 살아 숨 쉬는 객체들의 책임에 초점을 맞추게 된다.
• 구현 관점(Implementation Perspective)
  구현 관점의 초점은 객체들이 책임을 수행하는 데 필요한 동작하는 코드를 작성하는 것이다. 

 

 

해당 글은 '객체지향의 사실과 오해 - 조영호 (위키북스)'를 읽고 작성한 것입니다.