[오브젝트] 1장 - 객체, 설계

내용 정리: https://github.com/wonyangs/TIL/blob/main/202402/20240222.md

 

1. 개요

오브젝트의 첫 장에서는 객체지향 프로그래밍이란 무엇이고 왜 필요한지를, 티켓 판매 시스템을 예로 들어 설명한다.
주요 키워드로는 "패러다임, 의존성, 결합도, 응집도, 캡슐화"가 언급된다.

처음부터 다소 많은 키워드가 한꺼번에 등장하는 것 같다는 느낌이 들었다.
하지만 저자는 그런 우려를 미리 예측한 듯, 서문에서 아래와 같이 언급한다.

1장 '객체, 설계'에서는 티켓 판매 시스템이라는 간단한 도메인을 예로 들어 책의 전체적인 주제를 함축해서 전달한다. 1장에서 소개하는 용어와 개념들이 이해되지 않더라도 너무 걱정하지 않았으면 한다. 이어지는 장들을 읽다 보면 자연스럽게 1장에서 소개한 내용들이 익숙하게 느껴질 것이다.

 

위 이야기처럼 1장은 하나의 상황을 담은 코드 예시를 제시하고, 객체지향의 목적에 맞게 이를 하나씩 수정해 가며 객체지향이 왜 유용한가를 설명하고 있다.
아직은 예시와 용어들이 직관적으로 와닿지는 않지만, '오브젝트'라는 책이 앞으로 이야기를 할지 알 수 있었다.

2. 패러다임

객체지향을 설명하기 위한 시작점으로 '패러다임'이라는 개념을 다룬다.

 

패러다임은 한 시대의 사회 전체가 공유하는 이론이나 방법 등의 체계를 의미한다.
프로그래밍에서의 패러다임은 개발자 공동체가 사용하는 코딩 스타일 정도로 이해할 수 있다.

 

저자는 패러다임을 통해 개발자들이 비슷한 관점을 공유하고 빠른 의사소통이 가능해짐을 강조한다.

객체지향이라는 패러다임을 공부하는 이유도 여기에 있다.

 

하지만 객체지향이 모든 상황에 대한 유일한 해답은 아니다.

오히려 특정 상황에서는 객체지향이 아닌 다른 패러다임이 더 알맞을 수 있다.

항상 다른 방법론에 대한 유연한 사고를 잃지 않는 것이 중요하다.

 

또한 개발 분야는 상대적으로 새로운 분야이기에 이론이 실무 경험에서 나온다는 이야기가 인상 깊었다.

결국 실무에서 사용되고 검증된 것들이 이론으로 자리 잡는다는 것이다.

어떠한 방법론이 상황에 적합하지 않다면, 그것을 고집스럽게 고수하기보다는 상황에 맞도록 유연하게 적용하는 것이 중요할 것 같다.

3. 의존성과 결합도

의존성(dependency)은 한 객체가 변경될 때 그 객체에 의존하는 다른 객체도 변경될 가능성이 있는 상황을 의미한다.
높은 의존성을 가진 코드는 변경에 취약하다.
한 객체의 구현을 변경되면 이에 의존하는 다른 모든 객체들도 수정해야 하기 때문이다.

이렇게 객체 간 의존성이 강한 경우 결합도(coupling)가 높다고 표현한다.
객체지향 설계의 주요 목표 중 하나는 이러한 결합도를 낮추는 것이다.

4. 캡슐화와 응집도

프로세스(Process)와 데이터(Data)라는 두 가지 키워드가 등장한다.
여기서 데이터는 필요한 정보를 의미하고, 프로세스는 이 데이터를 활용하는 일련의 작업을 가리킨다.

객체지향에서는 데이터와 프로세스를 한 객체 내에 위치하도록 프로그래밍한다.

이것을 캡슐화(encapsulation)라고 한다.
캡슐화는 객체 내부로 세부적인 사항을 숨김으로써, 외부에서는 해당 객체의 데이터에 대해 직접적으로 알 수 없게 만든다.

이를 통해 데이터를 사용하는 부분이 해당 객체 내부로 제한되어, 객체의 자율성이 증가한다.

캡슐화를 통해 객체의 응집도(cohesion)를 높일 수 있다.
응집도가 높은 객체는 자신이 소유한 데이터를 스스로 처리하고 자신과 관련 없는 작업은 다른 객체에게 위임한다.
이렇게 되면 객체는 오직 자신과 밀접하게 연관된 작업만을 수행하게 된다.

결과적으로 객체들 간의 결합도는 낮아진다.
데이터와 관련된 프로세스가 각 객체 내에서 독립적으로 관리되므로, 객체 간의 참조가 줄어들고 의존성이 제거된다.
객체들은 외부의 간섭 없이 메시지를 통해서만 협력하게 된다.

5. 설계는 왜 필요할까?

설계는 변경에 유연하게 대응하는 코드를 작성하기 위해 존재한다.
개발 과정에서 요구사항은 항상 변경되고 코드를 수정하게 된다.

이렇게 불가피하게 발생하는 상황에 대처하기 위해서는 변경에 강한 설계가 필요하다.

이를 위해 객체지향 설계는 캡슐화를 통해 응집도를 높이고 의존성을 제거하여 결합도를 낮추는 방식을 선택했다. 
객체는 자신의 데이터를 책임지게 되고, 객체 간의 의존성을 적절하게 관리하여 변경에 강한 코드를 구현한다.

6. 느낀 점

최근 프로젝트를 마치고 회고 과정에서 한 가지 의문이 생겼다.

설계 단계에서 모든 것을 알 수 없는데, 어떻게 설계를 해야 할까?

1장의 설계에 대한 부분을 읽으면서 이 의문에 대한 단서를 찾게 됐다.

설계란 코드를 배치하는 것이다. 설계는 코드를 작성하는 매 순간 코드를 어떻게 배치할지 결정하는 과정에서 나온다. 설계는 코드작성의 일부이고, 코드를 작성하지 않고서는 검증할 수 없다.

 

즉 설계란 결코 완벽할 수 없고, 그렇기에 객체지향은 변경에 대응한다는 방식으로 접근한 것이다.
프로젝트를 진행하며 생기는 다양한 요구사항 변경에 대응할 수 있는 코드를 작성하는 것이 바로 객체지향의 목적이라는 사실을 깨달았다.

책에 나오는 용어들이 아직은 낯설지만, 내가 가진 궁금증에 대한 답을 찾는 데 도움이 될 것이라는 확신을 가지게 되었다.
객체지향 설계에 필요한 개념들을 알기 위해 계속해서 책을 읽어봐야겠다.