[독서] 객체지향의 사실과 오해

책을 읽게된 배경

객체지향 언어의 대표적인 JAVA를 사용하고 있음에도 객체지향이 무엇인지에 대해 고민해봤던 적이 없었던 것 같다.

그래서 그런지 "객체 지향이 무엇인데?" 라는 질문에 나만의 기준을 가지고 제대로 대답할 수 가 없는 것 같다.

 

이 책을 통해서 "객체 지향이 무엇인지" 대해 고민해보고 나만의 기준을 세우는데 도움을 얻고자 읽는다.

단순히 객체 지향을 이해하는 것에 그치지 않고, 왜 객체지향 적인 코드를 작성해야 하는지와 어떻게 작성하는 것이 객체지향적인 코드인지 기준을 잡을 수 있을 것이라 기대한다. 

 

핵심 내용

책을 읽으면서, 내가 중요하다고 생각하는 부분을 중점적으로 정리했다.

 

객체지향이 무엇일까?

• 객체지향은 실세계를 그대로 모방하는 것이 아니라, 새로운 세계를 자율적인 객체들의 협력으로 재창조하는 것이다.
• 객체란 식별 가능한 개체 또는 개념으로 구체적인 사물(자동차)일 수도 있고, 추상적인 개념(시간)일 수도 있다.
• 객체는 식별 가능해야 하며, 상태, 행동 가지며, 객체들은 메시지를 통해 상호작용한다. 
• 객체는 스스로 상태를 책임지고, 외부에서 직접 상태를 조작하지 못하도록 캡슐화한다.

협력, 책임 역할

• 객체지향은 객체 간의 역할, 책임, 협력을 기반으로 작동한다.
• 협력은 시스템이라는 공통 목표를 위해 객체들 간 상호작용이 이뤄지는 과정이다.
• 메시지는 객체 간 소통의 유일한 수단이며, 송신자는 수신자의 내부 처리 방식에 관심을 두지 않는다.
• 객체가 메시지를 받고 처리하는 능력이 책임이며, 이 책임들의 집합이 곧 역할이다.
• 동일한 역할을 가진 객체는 서로 교체 가능(다형성)하며, 시스템은 다형성을 통해 유연성을 확보할 수 있다.

추상화

• 추상하는 복합한 현실을 단순화하고 본질만 남기는 설계 도구이다.
• 객체지향의 핵심은 구체적인 클래스가 아니라 역할과 책임을 중심으로 한 추상화된 모델이다.
• 추상화를 통해 유연하고 변경에 강한 시스템을 설계할 수 있다.
• 타입은 추상화의 결과물이며, 동일한 역할을 수행하는 객체들을 타입(클래스, 인터페이스)으로 묶는다.
• 내부 구현을 감추고 외부에 행동만을 노출하는 캡슐화는 추상화의 핵심이다.

유스케이스와 도메인 모델

• 유스케이스는 사용자와 시스템 간의 상호작용을 시나리오 형태로 정리한 것이다.
• 도메인 모델은 도메인에 존재하는 개념과 그 관계를 이해 관계자들이 모여 개념적으로 정리한 것이다.
• 유스케이스는 요구사항 기능을 수집하는 것에 집중하며, 도메인 모델은 구조를 설계하는 데 집중하다.
• 요구사항은 항상 변화하고 예측할 수 없기 때문에 상대적으로 안정적이고 변화가 적은 도메인 모델 중심으로 설계 해야한다.

적용

• 실제 시스템을 설계할 때 순서
  1. 유스케이스를 통한 요구사항을 정의한다.
  2. 도메인 모델링을 통해 객체 및 객체 관계를 정의한다.
  3. 메시지 파악 후 메시지를 처리할 객체를 선택한다.
  4. 해당 객체에서 처리할 인터페이스 추가하고 필요한 정보(메서드 인자) 추가한다.
  5. 인터페이스 구현한다. 구현 단계에서 객체의 속성들이 정해진다.
• 메시지를 먼저 정의하고, 메시지를 처리할 객체를 찾아내는 방식으로 설계하면 유연한 시스템을 만들 수 있다.
• 객체지향은 상태보다 행동 중심으로 설계하면 변경에 유연하고 확장 가능한 시스템을 만들 수 있다. 

 

책을 통해 배운 점

 

객체지향이란

객체지향은 단순히 클래스를 작성하는 것이 아니다.

객체지향은 공통된 목표(시스템)를 향해 객체 간 역할과 책임을 가지고 메시지를 통해 협력을 하는 것이다.

객체는 자율적으로 상태와 행동을 관리하며, 다른 객체와 협력할 때 메시지를 통해 간접적으로 소통한다.

객체지향의 핵심은 협력, 책임, 역할이다!

 

객체지향적 개발

이 책을 읽기 전에 아래와 같은 순서로 개발했다.

1. 클래스 선언
2. 속성(필드) 정의
3. 메서드 구현

이처럼 클래스와 데이터 중심으로 개발했으며, 또한 하나의 클래스가 너무 커지거나 코드의 길이가 길어질 경우 분리하는 방식으로 설계를 해놔갔다.

이러한 방식은 유연하지 못하고 변경에 취약한 좋지 못한 결과물을 가져다 준다는 것을 알게되었다.

 

메시지를 중심으로 객체를 식별하고 역할, 책임이 뚜렷한 진정한 객체지향적 설계를 실현하기 위한 방법으로 TDD라는 것을 알게 되었다. TDD는 단순히 테스트를 먼저 작성하는 개발 방식이 아니라, 객체의 역할과 책임을 기반으로 설계를 유도하는 개발 방법이라는 것을 알게 되었다.

TDD는 객체 간 협력을 설계하는 데 자연스럽게 집중할 수 있으며, 메시지를 중심으로 객체를 식별하고 필요한 인터페이스를 명확하게 정의할 수 있다. 즉, TDD를 잘 사용하면 객체지향적 코드를 작성하는 데 도움을 준다. 

 

하지만 나는 테스트 코드를 작성하고 있긴 하지만, 대부분 구현 코드를 작성한 후 검증용 테스트를 추가하는 방식이다.

이러한 방식은 TDD의 장점을 온전히 누리기 힘들다.

TDD에 추가적으로 공부할 것은 많지만 이 책을 통해 TDD의 중요성과 전형적인 흐름을 배우게 되어 앞으로 적용해 나갈 예정이다.

TDD 흐름

1. 실패 테스트 작성
2. 테스트를 통과시키키 위한 가장 간단한 코드 작성
3. 리팩토링을 통한 품질 개선

앞으로 이러한 TDD 사이클을 지켜나가면서 개발을 시도해봐야겠다.