객체지향의 사실과 오해 1장 리뷰 - OOP의 핵심

몇달전에 산 책 객체지향의 사실과 오해를 다시 읽으려고 한다

자바를 공부하고 스프링부트를 사용하고 백엔드 개발자를 지망하는 백수로서 객체지향에 대한 깊은 이해가 필요하다고 느꼈다

 

1장 - 협력하는 객체들의 공동체

객체지향을 흔하게 비유하는 문장 "객체지향 프로그래밍은 실세계의 사물을 모방하여 소프트웨어로 옮기는 작업이며, 그 속에서 객체는 실세계에 존재하는 사물의 추상화이다."은 올바르지 않다.

하지만 현실 세계에 대한 비유는 [캡슐화], [모방성], [메시지], [협력], [연결완전성] 등의 객체지향 핵심 개념들을 이해하는 데에 용이하다.

사실 객체지향의 목표는 실세계를 모방하는 것이 아닌 고객과 사용자를 만족시킬 수 있는 새로운 세계를 창조하는 것에 있다.

 

객체지향의 가장 중요한 개념 세 가지는 [역할], [책임], [협력]이다

 

이를 위해 간단한 예시 (책에 나온 커피 주문 예시가 아닌 버스 탑승으로 하겠다)를 빌리자면

• 승객은 원하는 목적지로 이동하기 위해 매표소에서 티켓을 끊는다.
• 매표원은 승객이 가려는 목적지의 배차 여부, 시간 등을 확인하여 티켓을 발행해준다.
• 승객은 발행된 티켓을 가지고 해당 버스 플랫폼으로 이동한다.
• 버스기사는 승객의 티켓이 현재 운행 정보에 맞는지 확인한 후, 맞다면 탑승을 허락하고 아니라면 돌려보낸다.
• 버스 기사는 출발 시각에 맞춰 버스를 운행하고, 목적지에 도달하면 모든 승객을 하차시킨다.

 

이러한 실생활의 예시에서 어떻게 [역할], [책임], [협력]을 도출할 수 있을지 알아보자

승객은 서울에서 대전으로 이동하기 위해 반드시 교통 서비스를 이용해야 한다(걷기를 선택한다면 혼자서도 수행할 수 있지만 이러한 경우는 생각하지 않는다)

또한 버스기사가 자신이 운행하는 버스에 탑승할 손님들에게 일일히 매표를 도와주지도 않고, 매표원도 자신의 창구에서 서비스를 원하는 손님이 오기를 기다려야 한다.

모든 수행 관계속에서 승객, 버스기사, 매표원은 자신이 해결하지 못 하는 일을 다른 사람에게 요청하고, 필요한 정보 및 서비스를 통해 응답한다.

이러한 요청-응답을 통한 협력은 개개인의 능력 밖에 있는 공통의 거대한 문제를 해결할 수 있게 한다.

[승객], [버스기사], [매표원]이라는 역할들은 그 단어에 맞게 협력 관계 속에서만 존재할 수 있다.

 

협력의 핵심은 특정한 책임을 수행하는 역할들 간의 연쇄적인 요청과 응답을 통해 목표를 달성하는 데에 있다.

이는 OOP에서 객체가 자기 자신에게 주어진 역할과 책임을 다하는 동시에 시스템의 목적(애플리케이션의 구현)을 이루기 위한 협력 관계에도 적극적으로 참여한다는 것을 의의와 상통한다.

시스템은 결국 역할과 책임을 수행하는 객체로 분할되고, 시스템의 기능은 객체 간의 연쇄적인 요청과 응답의 흐름으로 구성된 협력으로 구현된다.

[책임]은 객체지향 설계의 품질을 결정하는 가장 중요한 요소이며, 책임이 불분명한 객체는 애플리케이션의 목적을 모호하게 만든다.

 

• 여러 객체가 동일한 역할을 수행할 수 있다
• 역할은 대체 가능성을 의미한다
• 각 객체는 책임을 수행하는 방법은 자율적으로 선택할 수 있다
• 한 객체가 동시에 여러 역할을 수행할 수 있다

 

결국 객체는 애플리케이션의 기능 구현을 위해 존재하고, 기능이란 하나의 객체가 구현하기에 너무 복잡하고 거대하다.

따라서 여러 객체 간의 협력을 통해 기능을 구현해야 한다. 이로 인해 시스템의 품질은 [객체]와 [협력]으로 결정된다.

 

1. 객체는 충분히 '협력적'이어야 한다.

혼자서 모든 것을 처리하려는 God Object는 내부적 복잡도에 의해 자멸하게 된다.

객체 간에는 협력이 필연적으로 존재하게 된다. 이는 객체가 수동적임을 존재임을 의미하는 것이 아니다.

다른 객체의 요청에 응답할 뿐, 그 내부 방식과 응답 여부 또한 객체 자체에 달려있다.

 

2. 객체는 충분히 '자율적'이어야 한다.

객체 공동체에 속한 객체들은 공동의 목표를 달성하기 위해 협력에 참여하지만 스스로의 결정과 판단에 따라 행동하는 자율적인 존재다.

다른 객체와 조화롭게 협력하는 동시에(개방적) 협력하는 방법을 스스로 결정할 수 있어야(자율적) 객체지향적 설계를 했다고 말할 수 있다.

 

객체가 협력에 참여하는 과정 속에서 스스로 판단하고 결정하는 자율적인 존재가 되기 위해서는, 자신에게 필요한 상태와 행동을 함께 지녀야 한다.

[자율성]은 객체의 사적인 부분은 외부로의 접근을 차단하고, 허락된 수단을 통해서만 접근할 수 있음을 의미한다. 이로써 외부에서는 객체가 무엇을 수행하는지 알 수 있지만, 어떻게 수행하는 지는 알 수 없게 된다.

 

한 객체가 다른 객체에게 요청하는 것을 '메시지를 전송한다', 다른 객체로부터 요청을 받는 것을 '메시지를 수신한다'라고 말한다.

수신자는 수신된 메시지를 이해할 수 있는지 여부를 판단한 후, 자신만의 로직에 따라 메시지를 처리한다.

이처럼 객체가 메시지를 처리하는 방식을 메서드라고 한다.

외부의 요청을 처리하는 메시지와 구체적인 방법인 메서드의 분리(OOP에서 실행 시간에 수행할 메서드를 선택할 수 있다는 점)은 협력에 참여하는 객체들 간의 자율성을 높인다.

 

결과적으로,

• 객체지향이란 시스템을 상호 작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해 시스템을 분할하는 방법
• 자율적인 객체란 상태와 행위를 함께 지니며 스스로 자기 자신을 책임지는 객체
• 객체는 시스템의 행위를 구현하기 위해 다른 객체와 협력한다. 각 객체는 협력 내에서 정해진 역할을 수행하며 역할은 관련된 책임의 집합이다.
• 객체는 다른 객체와 협력하기 위해 메시지를 전송하고, 메시지를 수신한 객체는 메시지를 처리하는 데 적합한 메서드를 자율적으로 선택한다.

 

객체지향의 핵심은 클래스가 아니다. 지나치게 클래스를 강조하는 PL적 관점은 객체의 캡슐화를 저해하고 클래스를 서로 강하게 결합시킨다.