오브젝트 1장. 객체, 설계

[책 스터디][오브젝트] 1장. 객체, 설계

---

본 내용은 오브젝트 책을 보고 공부, 정리한 내용입니다.
본 글에 등장하는 실습 링크는 이곳을 참고해 주세요.

로버트 마틴의 클린 소프트웨어 中 - 소프트웨어 모듈의 목적 세 가지

1. 실행 중 제대로 동작해야 한다.
2. 모듈은 변경을 위해 존재한다. 즉, 변경하기 어려운 모듈은 제대로 동작하더라도 리팩토링할 필요가 있다.
3. 코드를 읽는 사람이 이해하기 편해야 한다. 즉, 코드의 흐름이 상식선에서 예상 가능한 코드여야 한다.

소극장 티켓 판매 구현해보기

실습 링크의 theater/procedural branch 참고

무엇이 문제?

• 로버트 마틴의 소프트웨어 모듈의 목적 세 가지를 대입해보면
  • 실행 중 제대로 동작한다!
  • Theater 클래스는 Audience, Bag, Ticket, TicketOffice 무려 네 개의 클래스에 의존하고 있다. 이 중 하나의 코드가 변경되면, Theater 클래스도 변경되어야 할 확률이 높다.
  • Theater 클래스의 enter()를 보고, 어떤 과정으로 진행되는건지 한 눈에 이해하기 어렵다. 목적1은 만족하지만, 목적 2, 3은 만족하지 못한다.

• 이같은 문제가 발생하는 이유는? “예상을 빗나가는 코드” & “변경에 취약” 하기 때문이다. Theater의 enter() 내부를 살펴보면, Audience와 TicketSeller는 수동적이다. 객체지향 패러다임에서 객체는 자신의 데이터를 자신이 직접 관리해야 한다. 현재 코드는 Theater는 “절차” 를 갖고 있고, 나머지 클래스들은 단지 “데이터” 로써의 역할만 수행하는 절차지향적 패러다임이다.

• 해결 방법
  • 객체가 자율적으로 자신의 데이터를 자신이 관리하게 만들자
    • 캡슐화를 이용해 객체의 데이터를 숨기고, 외부에 인터페이스를 제공하자.
    • 객체의 자율성을 높이면 객체 간 결합도 및 의존성은 낮아지고, 응집도는 상승한다.

  응집도
  객체가 자신과 밀접히 연관된 작업만 수행하고, 그 외 작업은 다른 객체에 일임하는 정도

객체지향 패러다임에 맞게 코드 리팩토링

실습 링크의 theater/object-oriented branch 참고

객체지향 패러다임 설계의 핵심

• 객체의 자율성을 높이자! 자율성을 높인다는 건, 객체가 자신의 데이터를 자신이 직접 관리하는 것이다. 아울러 캡슐화를 통해 외부에는 반드시 필요한 메서드(인터페이스)만 노출하자. 객체의 자율성을 높이면, 객체 간 의존성과 결합도는 낮아지고 응집도는 상승한다. 실세계에서는 수동적인 객체라도, 프로그래밍 세계에서 모든 객체는 자율적이어야 한다. (= 의인화)

• 객체는 자신의 책임(역할)만 관리하고, 그 외 관심사는 다른 객체에게 요청한다.

• 어느 정도 객체지향 패러다임에 맞게 설계를 했다면, 이후부터는 trade-off이다. 객체지향적으로 설계하면 의존성이 항상 낮아지는 것은 아니다. (ex. 예제 코드에서, TicketOffice와 Audience의 의존성이 추가된 상황)

좋은 설계란 오늘 구현할 기능이 제대로 동작하도록 코드를 배치하면서, 내일 있을 변경에 유연하게 대처할 수 있는 설계이다.