오브젝트 1장 - 객체, 설계
00. 들어가며
객체지향의 사실과 오해의 저자 조영호님의 3년만의 후속작입니다. 해당 책을 리뷰하면서 실전적인 책이라기보단 작가분의 객체지향적 철학 전달에 중점이 있던 책이라고 말씀드렸었습니다.
해당 책의 서평은 다음에서 읽으실 수 있습니다.
https://rawshrimpsushi.tistory.com/28
그래서 유익하면서도 뭔가 아리송한 느낌은 지울 수 없었습니다. 이 책은 그런 갈증을 한번에 날려주는 책이었습니다. Java Next step처럼 실전적으로 코드를 개선해보며 저자분의 객체지향 철학을 전달 받을 수 있는 아주 좋은 책이었습니다.
그래서 Java Next Step처럼 이 책도 한 단원씩 정리해서 올려보려고 합니다!
1장 – 객체의 자율성을 높여라
객체지향의 사실과 오해에서 데이터 중심으로 설계하지 말고 객체들의 역할과 책임을 중심으로 설계하라고 말씀해주셨는데 그에 대한 파트입니다.
영화관에서 영화표 판매를 한다고 해볼까요. 근데 이벤트를 곁들여서 이벤트에 당첨된 이들은 초대장을 티켓으로 교환한 뒤 공짜로 영화를 볼 수 있고 당첨되지 못한 사람들은 돈을 내고 영화를 감상해야합니다.
그렇다면 Ticket, Invitation 그리고 그걸 담을 Bag, 그 가방을 들고 있는 Audience, 영화표를 판매하는 TicketOffice와 직원 TicketSeller, 그리고 영화를 총괄하는 Theater 객체가 필요하다는 생각이 듭니다.
각 객체에 어떤 데이터들이 필요할 지 먼저 생각하고 설계를 해보면 다음과 같은 클래스 다이어그램이 나옵니다.
해당 코드를 활용하여 영화관 코드를 짠다면?
위 코드의 문제는 무엇일까요? 바로 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재이라는 점입니다. 객체들의 역할과 책임을 중심으로 협력해야하는데 Theater가 지나치게 많은 역할과 책임을 한 채 다른 객체들은 자신의 역할을 하지 못하고 있습니다.
로버트 마틴의 명저 클린 코드에서 언급한 좋은 코드를 위한 조건은
1. 모든 모듈은 제대로 실행되어야 한다.
2. 변경에 용이해야 한다.
3. 이해하기 쉬워야 한다.
입니다.
위 코드는 2번과 3번을 모두 충족시키지 못하고 있습니다. 우선 변경에 매우 취약합니다. Audience와 TicketSeller를 변경할 경우 Theater까지 함께 변경해야 합니다. 그리고 이해하기 어렵습니다. 이 코드를 이해하기 위해서는 Theater뿐만 아니라 Audience, Bag, TicketSeller, TicketOffice 모두를 이해하고 있어야 합니다. 이는 객체 사이의 결합도가 높기 때문에 발생하는 일입니다.
그럼 어떻게 해결하면 좋을까요?
각 객체를 자율적인 존재로, 각 역할과 책임을 다하게 만들어야 한다.
예를 들어 Theater의 enter 함수를 살펴볼까요.
영화관 객체에서 관객의 가방을 확인하고, 해당 표의 ticket을 가져오거나 가방의 잔고를 처리합니다. 하지만 이건 Audience 객체의 자율성을 해치고 있습니다. 현실로 비유해봐도 그렇습니다. 영화관이 마음대로 관객의 초대장을 꺼내고 돈을 가져갈까요? 표를 내거나 돈을 지불하는 일은 아무리봐도 관객의 일입니다. 그럼 해당 코드의 책임을 Audience로 옮기는 게 좋아보입니다. Audience에서도 마찬가지로 가방 객체의 자율성을 해치고 있으며.. 가방도 각 객체의... 이렇게 꼬리를 이으며 각 객체의 역할을 확실히 배정해두록 합시다.
각 객체의 역할을 분리함으로써 서로 몰라도 되는 세부사항을 캡슐화하였고 자율성을 높여 응집도 높은 객체로 구성할 수 있었습니다. 그래서 각 객체 간 의존성을 줄일 수 있었고 이제 각 객체에서 일어나는 변경 사항이 다른 객체에 주는 영향을 최소화할 수 있습니다.
이번 단원의 중요한 개념 : 객체의 자율성. 응집도를 높이고 의존성은 줄여라. 클린 코드 원칙.
모든 코드는 다음 레포지토리에서 확인할 수 있습니다!
https://github.com/SHEOMM/Object