[후기] 객체지향의 사실과 오해

 

객체지향의 사실과 오해 - YES24

여름에 읽었던 책을 회사 팀원들과 스터디를 하게 되면서 한 번 더 읽게 되었습니다.

스터디원들과 책을 읽고 자유롭게 후기를 써보기로 하여, 블로그에 간단하게 후기를 작성합니다.

1장

객체를 지향하라

자바를 사용하면서 클래스를 알게 되었고, 객체는 클래스가 인스턴스화된 것뿐이라 생각했다. 자바와 객체지향에서 객체가 클래스에 의해 생성되니, 클래스가 객체보다 중요하다고 생각을 했던 것 같다.

1장을 읽으면서 객체지향의 핵심은 클래스가 아닌 객체라는 것을 알게 되었다. 클래스는 자바가 객체를 사용하게하려고 지원하는 도구일 뿐임을 알아야 한다. (물론 클래스도 중요하다~)

2장

캡슐화

자바와 스프링으로 백엔드를 개발하면서 무심코 객체로부터 데이터를 직접 꺼내어 사용해왔다. 즉, 객체의 상태를 외부로 가져와 사용한 것이다

이번 장을 읽고 객체의 상태를 직접 꺼내서는 안 되며, 객체에게 행동하도록 해야 된다는 것을 알게 되었다. 객체의 상태는 객체의 행동에 의해서만 바뀌어야 한다.

3장

추상화

영국의 지하철 노선도가 만들어진 과정을 보며 추상화를 어떻게 해야 하는지를 배웠다.

하나의 역에서 다른 역으로 이동해야 하는 목적을 가지는 지하철 승객은 해리 백의 노선도가 추상화가 잘 되었다고 생각했을 것이다. "어디서" 환승을 해야 하는지 쉽게 알 수 있기 때문이다.

그렇다면 스팅모어가 만든 지하철 노선도는 추상화가 잘되지 않을 것일까? 에 대해 생각해보면 지하철 승객의 입장에서는 그럴 수 있을 것이다. 하지만, 지하철 승객이 아닌 지상에서 지하철역을 찾으려 하는 사람들에게는 스팅모어의 지하철 노선도가 추상화가 잘 되었다고 생각했을 것이다.

따라서, 하나의 추상화된 결과가 모든 경우를 만족시킬 수 없다. 목적에 맞게 적절하고 다르게 추상화를 진행해야 한다.

4장

역할, 책임, 협력

과거에 백엔드 개발을 할 때 새로운 비즈니스 요구사항이 생기면 어떠한 데이터가 필요할지 먼저 고민했었다. 데이터가 정해지면 어떻게 데이터를 담고, 갱신할지를 고민하며 클래스를 설계했었다.

이 책을 읽고 위 과정이 잘못되었다는 것을 알게 되었다. 데이터, 즉 상태를 먼저 고민하는 것이 아니라 협력을 먼저 고민해야 한다는 점을 알게 되었다.

비즈니스 요구사항을 코드로 구현하는 과정에서 어떠한 협력이 발생하는지 먼저 파악해야 한다. 어떠한 협력이 발생하는지 파악하고, 협력안에 어떠한 책임이 있으며, 식별된 책임을 어떠한 역할이 수행해야 하는지 충분히 고민해야 한다.

협력, 책임, 역할이 정해지면 역할을 적절한 객체에 부여하여 협력이 잘 이뤄지도록 해야 한다.

5장

묻지 말고 시켜라

나는 요구사항을 구현하는 과정에서 클래스를 만들고 이 클래스에 어떤 메서드가 필요한지 생각해왔다. 5장에서는 '묻지 말고 시켜라'라는 스타일을 제시하는데, 이 스타일은 메시지를 먼저 결정하고 객체가 메시지를 따르게 하는 설계 방식이다. 즉, 메서드를 먼저 결정하고 어떤 객체가 이 메서드를 가질지 정하는 것이다.

 

위 스타일을 준수하면 요구사항을 만족시키기 위해 메시지를 결정하는 시점에 어떤 객체가 메시지를 수신할지 알 수 없으므로 객체의 내부 상태를 볼 수 없게 된다.

 

따라서 메시지를 수신하는 객체의 캡슐화 정도는 높아지고, 송신자와의 결합도는 낮아진다.

 

반응형

 

6장

소프트웨어 분야에서 예외가 없는 유일한 규칙은 요구사항이 항상 변경된다는 것이다

6장에서는 다음과 같은 말을 한다. 훌륭한 설계자는 사용자가 만족할 수 있는 훌륭한 기능을 제공하는 동시에 예측 불가능한 요구사항 변경에 유연하게 대처할 수 있는 안정적인 구조를 제공하는 능력을 갖춰야 한다.

 

자바와 스프링으로 백엔드 API를 개발하며 DTO를 사용해왔다. 이전에는 컨트롤러 레이어에서 생성되는 DTO를 서비스 레이어에 그대로 전달하여 사용하곤 했다. 그런데 API 스펙이 변경되면서 DTO도 변경되는 경우가 있었고, 이는 서비스 레이어의 코드를 변경하게 했다. 즉, 많은 코드를 수정해야 했고, 요구사항 변경에 유연하게 대처하지 못했다.

 

이후, 아래 글을 읽고 컨트롤러 레이어와 서비스 레이어에서 사용하는 DTO를 분리하여 사용하기 시작했다. DTO 개수가 증가했지만, 다양한 요구사항 변경에도 코드를 쉽게 리팩토링할 수 있게 되었다. 즉, 요구사항 변경에 유연하게 대처할 수 있게 된 것이다.

잊을만 하면 돌아오는 정산 신병들 | 우아한형제들 기술블로그

 

또 6장에서는 다음과 같은 말을 한다. 좋은 설계는 나중에라도 변경할 수 있는 여지를 남겨 놓는 설계다. 설계를 하는 목적은 나중에 설계하는 것을 허용하는 것이며, 설계의 일차적인 목표는 변경에 소요되는 비용을 낮추는 것이다.

 

자바와 스프링을 공부하고 작은 프로젝트를 진행하면서 설계와 개발을 경험했지만 6장을 읽으면서 아직 갈 길이 멀었다는 생각이 들었다. 화이팅!

7장

인터페이스와 구현을 분리하라

마틴 파울러는 다음과 같이 주장한다. 개념적인 관점과 명세 관점 사이는 그렇게 중요하지 않은 경우가 많지만 명세 관점과 구현 관점을 분리하는 것은 매우 중요하다.

 

7장에서 말하는 명세 관점은 클래스의 인터페이스(public method)를 의미하는데, 이 인터페이스가 변하면 인터페이스를 이용하는 객체에게 영향을 주게 된다. 즉, 객체의 인터페이스는 수정하기 어려우므로, 구현 등으로 인한 변화에 안정적인 인터페이스를 만들어야 한다. 

 

이전에 자바로 작은 숫자야구게임을 만들었는데, MVC 패턴을 적용하기 위해 Model, View, Controller 레이어를 나누었다. 그리고 특정 레이어의 변화가 다른 레이어에 영향을 주지 않도록 하기 위해 반환 타입을 어떻게 할지 고민하곤 했다. 내부 구현이 달라지더라도 외부 객체가 참조하는 인터페이스(반환 타입, 전달인자 등)가 변하지 않는다면, 외부 객체에 주는 영향을 최소화할 수 있을 것으로 생각했기 때문이다.

GitHub - 0xe82de/java-baseball-precourse: 숫자 야구게임 미션을 진행하는 저장소

 

후기의 후기

이번 기회를 통해 '객체지향의 사실과 오해' 책을 한 번 더 읽게 되었다. 처음 읽을 때는 이해가 가지 않거나 와닿지 않는 부분이 많았는데, 이번에는 그래도 조금은 와닿는 부분이 늘어난 것 같다. 추후에 다시 한번 이 책을 읽는다면 더 많은 것들이 와닿지 않을까 한다.

 

책을 읽으며 '객체지향'에 대해 생각해보는 시간을 가지게 되었다. 이 과정에서 과거에 작성한 코드를 고친다면 어떻게 고쳐야 하는지, 객체지향을 잘 다루기 위해 어떤 것을 해야 할지 등의 고민을 했다.

 

결과적으로 객체지향에 대해 조금 더 가까이 다가가는 계기가 되었다. 빨리 속편인 '오브젝트' 책도 읽어야겠다.