[독후감] 오브젝트 - 챕터01

들어가기 앞서 로버트 마틴의 소프트웨어 모듈이 가져야하는 세 가지 기능에 관한 설명을 적고 시작하겠다.

모든 소프트웨어 모듈에는 세 가지 목적이 있다. 첫 번째 목적은 실행 중에 제대로 동작하는 것이다. 이것은 모듈의 존재 이유라고 할 수 있다. 두 번째 목적은 변경을 위해 존재하는 것이다. 대부분의 모듈은 생명주기 동안 변경되기 때문에 간단한 작업만으로도 변경이 가능해야 한다. 변경하기 어려운 모듈은 제대로 동작하더라도 개선해야 한다. 모듈의 세 번째 목적은 코드를 읽는 사람과 의사소통하는 것이다. 모듈은 특별한 훈련 없이도 개발자가 쉽게 읽고 이해할 수 있어야 한다. 읽는 사람과 의소소통할 수 없는 모듈은 개선해야 한다.

정리해보자면

1. 모든 모듈은 제대로 실행돼야 한다.
2. 모든 모듈은 변경이 용이해야 한다.
3. 모든 모듈은 이해하기 쉬워야 한다.

이 세가지를 계속 머리속에 넣어놓길 바란다.

 

또한 책에서 다루고 있는 코드는 각자 책을 읽어보며 실습하길 바란다. 필자는 책에서 코드를 예시로 중요시하는 개념과 이론에 더 초점을 맞출 예정이다.

변경에 취약한 코드

변경하기 어려운 코드에서 볼 것은 객체들 사이의 의존성의 정도이다. 의존성은 변경에 대한 영향을 암시하는데, 의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포되어있다.

 

객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것이다. 그렇기에 객체 사이의 의존성을 완전히 없애는 것은 정답이 아니다.

좋은 객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것이다. 우리의 목표는 애플리케이션의 기능을 구현하는 데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것이다.

 

자율성을 높이자

각 객체의 자율성을 높이지 못한다면 한 객체에 많은 책임이 부여될 수 있다. 이것은 의존성을 높이는 행동이며 변경에 취약한 코드를 만들어내는 일이다. 

만약 한 객체에 많은 책임이 부여된 상태라면 각각의 객체에게 책임을 분산시켜 자율성을 높이자. 

객체를 인터페이스와 구현으로 나누고 인터페이스만을 공개하는 것은 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위해 따라야 하는 가장 기본적인 설계 원칙이다.

 

캡슐화와 응집도

위에서 인터페이스와 구현을 나눈다고 하였다. 이는 객체지향의 핵심 키워드인 캡슐화와 관련이 깊다.

한 객체가 다른 객체의 인터페이스에만 의존하게 됨과 동시에 다른 객체가 인터페이스를 어떤식으로 구현했는지는 모르기 때문이다.

 

밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도가 높다고 말한다. 

자신의 데이터를 스스로 처리하는 자율적인 객체를 만들면 결합도를 낮추며 응집도를 높이게 된다.

 

객체의 응집도를 높이기 위해선 객체 스스로 자신의 데이터를 책임져야 한다. 이것은 객체의 응집도를 높이는 첫 걸음이다.

외부의 간섭을 최대한 배제하고 메시지를 통해서만 협력하는 자율적인 객체들의 공동체를 만드는 것이 훌륭한 객체지향 설계를 얻을 수 있는 지름길이다.

 

절차지향과 객체지향

절차적 프로그래밍의 전형적인 의존성 구조란 모든 처리가 하나의 클래스 안에 위치하고 나머지 클래스는 단지 데이터의 역할만 수행하는 것이다. 이러한 구조의 문제점은 변경에 취약하다는 것이다.

절차적 프로그래밍의 더 큰 문제는 데이터의 변경으로 인한 영향을 지역적으로 고립시키기 어렵다는 것이다. 이는 변경에 취약하며 변경은 버그를 부르고 버그에 대한 두려움은 코드를 변경하기 어렵게 만든다. 

따라서 절차적 프로그래밍은 변경하기 어려운 코드를 양산하는 경향이 있으며, 이를 지양해야 한다.

 

객체지향 프로그래밍은 프로세스와 데이터가 동일한 모듈 내부에 위치하게 된다. 이는 절차지향과 반대되는 점이다.

훌륭한 객체지향 설계의 핵심은 캡슐화를 이용해 의존성을 적절히 관리하여 객체 사이의 결합도를 낮추는 것이다.

일반적으로 객체지향이 절차지향에 비해 변경에 좀 더 유연하다고 말하는 이유가 이것이다.

 

책임의 이동

객체지향과 절차지향의 근본적인 차이를 만드는 것은 책임의 이동이다. 

책에 나오는 절차지향적 코드를 봐보면 Theater에 책임이 집중되어있다. 그에 반해 객체지향은 각 객체에 적절한 책임이 분산되어 있다.

이는 Theater에 집중되었던 책임이 각 객체에 적절하게 이동됐음을 보여준다.

 

설계를 어렵게 만드는 것은 의존성이라는 것을 기억하자. 해결법은 불필요한 의존성을 제거함으로써 객체 사이의 결합도를 낮추는 것이다. 결과적으로 불필요한 세부사항을 객체 내부로 캡슐화하는 것은 객체의 자율성을 높이고 응집도 높은 객체들의 공동체를 창조할 수 있게 한다.