2장 정리
프로그래밍을 할때 대부분의 사람들은 어떤 클래스가 필요한지부터 고민한다.
그렇게 클래스를 결정한 후에 클래스에 어떤 속성, 메서드가 필요한지 고민한다.
하지만 이는 객체지향적인 설계와 거리가 멀다.
진정한 객체지향 패러다임으로의 전환은 클래스가 아닌 객체에 초점을 맞출 때에만 얻을 수 있다.
이를 위해서는 다음 두가지에 집중해야 한다.
1. 어떤 클래스가 필요한지를 고민하기 전에 어떤 객체들이 필요한지 고민하라.
- 클래스는 공통적인 상태와 행동을 공유하는 객체들을 추상화한 것이다.
- 따라서 클래스의 윤곽을 잡기 위해서는 어떤 객체들이 어떤 상태와 행동을 가지는지를 먼저 결정해야 한다.
2. 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야 한다.
- 객체지향적으로 생각하고 싶다면 객체를 고립된 존재로 바라보지 말고 협력에 참여하는 협력자로 바라봐야 한다.
- 객체들의 모양과 윤곽이 잡히면 공통된 특성과 상태를 가진 객체들을 타입으로 분류하고, 이 타입을 기반으로 클래스를 구현하라.
시스템의 어떤 기능을 구현하기 위해 서로의 메서드를 호출하며 상호작용하는 것을 협력이라고 한다.
객체는 다른 객체의 인터페이스에 공개된 행동을 수행하도록 요청할 수 있다.
요청을 받은 객체는 자율적인 방법에 따라 요청을 처리한 후 응답한다.
객체가 다른 객체와 상호작용할 수 있는 유일한 방법은 메시지를 전송 하는것 뿐이다.
다른 객체에 요청이 도착할 때 해당 객체가 메시지를 수신했다고 한다.
메시지를 수신한 객체는 스스로의 결정에 따라 자율적으로 메시지를 처리할 방법을 결정하며, 이 방법을 메서드라고 한다.
메시지와 메서드의 구분에서 다형성의 개념이 출발한다.
다형성을 이용하면 컴파일 시점의 의존성과 실행 시점의 의존성이 서로 다를 수 있다.
이를 통해 같은 메시지로도 메시지를 수신한 객체의 타입에 따라 다른 메서드를 실행할 수 있다.
이렇게 코드를 작성한다면 더 유연하고, 쉽게 재사용 할 수 있다.
하지만 이러면 코드를 읽었을 때 이해하기 어려워진다.
이와 같은 의존성의 양면성은 설계가 트레이드오프의 산물이라는 사실을 보여준다.
따라서 객체지향적으로 설계하기 위해서는 이런 유연성과 가독성 사이에서 고민해야한다.
상속은 구현 상속 / 인터페이스 상속으로 분류할 수있다.
구현 상속 - 코드를 재사용하기 위한 목적
인터페이스 상속 - 다형적인 협력을 위해 부모 클래스와 자식 클래스가 인터페이스를 공유하기 위한 목적
상속은 구현 상속이 아니라 인터페이스 상속을 위해 사용해야 한다.
= 코드 재사용이 아닌, 같은 메시지를 수신할 수 있다는걸 뜻하는 의미에서 사용해야한다.
대부분의 사람들은 객체지향 프로그래밍 과정을 클래스 안에 속성과 메서드를 채워넣는 작업이나,
상속을 이용해 코드를 재사용하는 방법 정도로 생각한다.
하지만 이렇게 프로그래밍 관점에 너무 치우쳐서 객체지향을 바라볼 경우 객체 지향의 본질을 놓치기 쉽다.
객체지향이란 객체를 지향하는 것이다.
가장 중요한것은 애플리케이션의 기능을 구현하기 위해 협력에 참여하는 객체들 사이의 상호작용이다.
이런 객체들 사이의 역할, 책임, 협력이라는 본질이 가장 중요하다.
인상깊었던 점
"객체지향이란 단순히 클래스 안에 속성과 메서드를 채워넣는 작업이나 상속을 이용해 코드를 재사용하는게 아니다."
이번 장에선 이 문장이 가장 인상깊었다.
지금껏 객체 지향 프로그래밍에서 상속에 대해 설명할 땐 코드 재사용 측면을 위주로 설명했다.
하지만 이번 장을 읽고 상속은 단순히 코드를 재사용한다는게 중점이 아닌,
다형적인 협력을 위해 부모 클래스와 자식 클래스가 인터페이스를 공유하는 것이라는걸 배울 수 있었다.
앞으로 코드를 작성하기에 앞서, 객체 간의 협력 과정을 메시지 / 메서드로 나눠서 생각하는 습관을 들여봐야 겠다.