1. 객체지향의 사실과 오해

튜터님이 추천해주셔서 읽었는데, 왜 나에게 이 책을 추천했는지 이제야 알 것 같다.

나는 지금껏 디자인 패턴을 사용하거나 구조를 설계할 때 명확한 이유가 없었다. 그냥 멋있어 보였고, 하고 싶어서 썼을 뿐이다. 하지만 이제야 깨달았다. 내가 객체지향을 너무 쉽게 생각했음을..

 

나는 단순히 클래스를 잘 나누고, 화려한 디자인 패턴을 적용하면 그것이 곧 SOLID를 준수한 코드이고 객체지향적인 코드라고 생각했다.
틀린 말은 아니겠지만, 근본이 잘못되었다. 내 코드를 비유하자면, 상체는 비대하고 하체는 앙상한 모습이었다. 기본기도 없이 이것저것 덧붙인 결과, 몸뚱이만 커진 꼴이었다.

 

그렇다면 객체지향의 기본기란 무엇일까?
이 책을 읽고 처음으로 스스로에게 던져본 질문이었다.

 

내가 내린 답은 이것이다. 적절한 객체에 적절한 ‘책임’을 할당하고, 그 객체들 간에 협력적인 구조를 갖추는 것. 그것이 객체지향의 기본이다.

 

예를 들어, 객체 A와 객체 B가 있다고 해보자.

1. 객체 A는 a라는 행동을 담당한다.

2. 객체 B는 b라는 행동을 담당한다.

만약 객체 B가 b를 수행할 때 a도 함께 필요하다면, B는 A의 모든 것을 알아야 할까?

아니다. B는 A가 "a를 할 수 있다는 것" 과, "a를 수행하기 위해 무엇이 필요한지" 정도만 알면 된다.

A가 "어떻게" 그 행동을 하는지, 그 과정에서 또 무슨 과정을 거치는지는 알 필요가 없다.

이처럼 객체 간의 협력은 신뢰를 기반으로 한다. A는 B에게 필요한 정보를 제공하며 협력적이고, B는 A의 내부 구현에는 관여하지 않는다.

이것이 객체지향의 출발점이다.

 

객체지향 코드는 마치 하나의 회사처럼 작동해야 한다.

홍보 부서는 개발 부서가 '우리 서비스를 개발한다는 것'을 알고 있지만, 어떻게 개발하는지는 모른다.

개발부 팀장 김씨가 퇴사하더라도, 홍보부에는 아무 영향이 없다.

하지만 홍보 부서 사람들은 서로가 어떻게 일을 하는지 알고 있다. 팀 내부에서는 서로의 역할을 명확히 이해하고 협력한다.

 

회사의 규모가 커지며 홍보부가 바빠지게 되었고, 홍보를 수행할 대상이 많아졌다.

이럴 때 적용하는 것이 일반화(또는 추상화)이다. 먼저 큰 개념의 인터페이스(추상 클래스)를 통해 홍보부서의 담당자가 해야 하는 일을 정의한다.

그것을 구체화하는(상속받는) 것은 A에 대한 홍보를 수행하는 클래스, B에 대한 홍보를 수행하는 클래스일 것이다.

이런 방식으로 구조를 유연하게 만들 수 있다.

 

그리고 이 회사의 CEO는 코드를 짜는 나 자신이다. 협력적으로 체계를 구성하되 정답은 없다. 내가 내 회사의 구조를 이해하고 자신 있게 설명할 수 있다면, 그것이 곧 정답이다.

하지만 잊지 말아야 할 점이 있다. 오래된 회사는 고인 물만 남기 쉽다.
끊임없이 좋은 설계를 받아들이고, 새로운 아이디어를 수용해야만 발전할 수 있다.

 

책임과 협력을 중심으로, 탄탄한 기본기에 기반한 코드를 작성하는 것.
다른 사람의 의견을 적극적으로 수용하며 시야를 넓히는 것.
멋진 설계는 화려한 기술로 이루어지는 것이 아니다. 기본에 충실하면서도, 문제를 가장 적절하게 해결하는 방식에서 나온다. 나는 그 기본을 놓치지 않는 개발자가 될 것이다.