책 <객체지향의 사실과 오해>

책장 정리 중 ··· 메모해놨던 부분을 여기로 옮긴다.

 

<객체지향의 사실과 오해>

조영호, 위키북스

 

---

No object is an island.

• 협력은 요청과 응답으로 구성된다.
• 협력하는 과정 속에서 객체는 역할을 부여받아 어떤 행동을 할 책임을 가진다.
• 중요한 것은 어떤 클래스가 필요한가가 아니라 어떤 객체들이 어떤 메시지를 주고받으며 협력하는가다.

 

All the objects have a state(상태), behavior(행동) and identity(식별자). 

• 상태란 특정 시점에 객체가 가지고 있는 정보의 집합이다.
• 객체는 자율적인 존재임으로 다른 객체의 상태에 직접적으로 접근할 수도, 상태를 변경할 수도 없다.
• 행동이란 외부의 요청 또는 수신된 메세지에 응답하기 위해 동작하고 반응하는 활동이다. 
• 객체가 외부에 노출하는 것은 행동뿐이며, 외부에서 객체에 접근할 수 있는 유일한 방법 역시 행동뿐이다.
• 객체는 어떤 상태에 있더라도 유일하게 식별 가능하다.

 

행동이 상태를 결정한다.

• 초보자들은 먼저 객체에 필요한 상태가 무엇인지를 결정하고 그 상태에 필요한 행동을 결정한다.
• 자율적인 객체는 '어떻게 How' 해야 하는가가 아니라 '무엇 What'을 해야하는지 설명한다.
• 객체지향 설계는 애플리케이션에 필요한 협력을 생각하고, 협력에 참여하는 데 필요한 행동을 생각한 후, 행동을 수행할 객체를 선택하는 방식으로 수행된다. 행동을 결정한 후에야 행동에 필요한 정보가 무엇인지를 고려하게 되며 이 과정에서 필요한 상태가 결정된다.
• 우리의 목적은 현실을 모방하는 것이 아니다. 현실 속에서의 수동적인 존재가 소프트웨어 객체로 구현될 때는 능동적으로 변한다.

 

추상화와 타입

• 구체적인 사물들 간의 공통점은 취하고 차이점은 버려 일반화하고, 중요한 부분을 강조하기 위해 불필요한 세부 사항을 제거함으로써 단순하게 만든다.
• 타입은 데이터가 어떻게 사용되느냐에 관한 것이다. 어떤 데이터에 어떤 연산자를 적용할 수 있느냐가 그 데이터의 타입을 결정한다.
• 객체가 어떤 행동을 하느냐에 따라 객체의 타입이 결정된다. 객체의 내부 표현과는 아무런 상관이 없다. 객체의 내부 표현 방식이 다르더라도 어떤 객체들이 동일하게 행동한다면 그 객체들은 동일한 타입에 속한다.
• 다형성이란 서로 다른 타입의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것을 의미한다.
• 다형성은 메시지 송신자의 관점에서 동일한 역할을 수행하는 다양한 타입의 객체와 협력할 수 있게 한다.

 

객체지향 설계 기법

• 책임 주도 설계 Responsibility-Driven Design
  협력에 필요한 책임들을 식별하고 적합한 객체에게 책임을 할당한다.
• 디자인 패턴 Design Pattern
  전문가들이 이미 식별해놓은 역할, 책임, 협력의 모음
• 테스트 주도 개발 Test-Driven Development
  구체적인 코드를 작성해나가면서 역할, 책임, 협력을 식별하고 피드백 받는 것

 

인터페이스

• 내부 구조나 동작 방식을 몰라도 인터페이스 사용법만 익히면 된다.
• 내부 구조나 동작 방식만을 변경하는 것은 사용자에게 어떤 영향도 미치지 않는다.

 

Matt Weisfeld 세 가지 원칙

1. 좀 더 추상적인 인터페이스
   상세한 수준의 메시지를 보내는 것은 객체을 자율성을 저해한다.
2. 최소 인터페이스
   외부에서 사용할 필요가 없는 인터페이스는 최대한 노출하지 말아야 한다.
3. 인터페이스와 구현 간에 차이가 있다는 점을 인식
   
   

인터페이스와 구현의 차이

• 훌륭한 객체란 구현을 모른 채 인터페이스만 알면 쉽게 상호작용할 수 있는 객체를 의미한다.
• 소프트웨어는 항상 변경된다. 구현은 항상 변경된다.
• 인터페이스는 변경되면 객체 외부에 영향을 미친다.

 

책임이 자율적일수록 적절하게 '추상화'되며, '응집도'가 높아지고, '결합도'가 낮아지며, '캡슐화'가 증진되고, '인터페이스와 구현이 명확이 분리'되며, 설계의 '유연성'과 '재사용성'이 향상된다.

 

 

변경에 유연한 구조 설계

• 미래에 대비하는 가장 좋은 방법은 변경을 예측하는 것이 아니라 변경을 수용할 수 있는 선택의 여지를 설계에 마련해 놓는 것이다.
• '기능'은 사용자가 자신의 목표를 달성하기 위해 사용할 수 있는 시스템의 서비스이다. '구조'는 시스템의 기능을 구현하기 위한 기반으로, 기능 변경을 수용할 수 있도록 안정적이어야 한다.
• 비즈니스 정책이 크게 변경되지 않는 한 시스템의 기능이 변경되더라도 객체 간의 관계는 일정하게 유지된다. 기능적인 요구사항이 변경될 경우 책임과 객체 간의 대응 관계만 수정될 뿐이다