1. Object 리뷰 (1장. 객체, 설계) [2022-01-19]

1단원을 공부하고 드는 소감은
객체지향설계에 대해서 내가 너무 쉽게 생각했다는 것이다.

객체지향 프로그래밍(OOP)를 하고있다고 생각했으나
전혀 그렇지 않았다.

책 내용 중

로버트 마틴이 설명한 객체지향설계의 3가지 핵심사항

1. 코드가 동작해야한다.

2. 코드가 변경에 용이해야한다.

3. 코드로 의사소통이 가능해야한다.

사실 이건 객체지향언어 프로그래밍을 하는 모든 사람들이 알고있고 실천하고 있는 내용들이다.

다만 어떻게 하면 더 좋게 설계하고 유연하게 작성할 수 있을까에 대해서

충분히 도움을 많이 받을 수 있다는 느낌을 받았다.

첫장부터 사실 조금 설렌다 :)

 

첫장에서 Theather 예제를 따라 코딩을 해봤는데

정말 신기한것 같다.

특히 책임의 이동이 중요하다는 것을 배웠다.

객체 스스로가 자율적인 존재이며, 스스로 책임지게끔 코딩을 함으로써

응집도를 높이고 결합도를 줄일 수 있다.

 

설령 일부 내용이 바뀌더라도 

바뀐 내용을 책임지고 있는 객체만 수정해주면 되니

변경에도 용이해진다.

 

또한 이러한 책임들을 분배해서 맡아 처리하기 떄문에

서로간의 의사소통이 가능하며

 

이러한 방식의 코딩은 생산성을 높여준다.

 

이 장에서는 다음을 강조한다.

설계를 어렵게 만드는 것은 의존성이라는 것을 기억하라고 한다.

그리고 이에 대한 해결방법은 불필요한 의존성을 제거함으로써 객체 사이의 결합도를 낮추는 것!

 

기존 코드에서는

극장에서 티켓이 들어있는 가방을 가진 관람객과 티켓 판매를 돕는 판매원을 

티켓 판매소로 끌고와서 가방을 강제로 열고 티켓을 교환한다는 점이 문제였다.

 

이부분을 Audience와 TicketSeller 내부로 감춰 캡슐화하였다.

결과적으로 불필요한 세부사항을 객체 내부로 캡슐화하는 것은 객체의 자율성을 높이고

응집도 높은 객체들의 공동체를 창조할 수 있게 한다.

세부사항을 캡슐화하는 자율적인 객체들이 낮은 결합도와 높은 응집도를 가지고 협력하도록 최소한의 의존성만을 남기는 것이 흘륭한 객체지향 설계다.

 

 

예제에서 Bag과 ticketOffice에 자율성을 부여함으로써

각각의 클래스가 가벼워졌다.

그러나 트레이드 오프라는 말 처럼

 

클래스의 결합도를 낮추고 응집도를 높이는 대신

무엇인가를 지불해야한다. 바로 계층 구조이다.

자율성을 부여 할 수록 코드는 점점 깊어진다.

즉, 복잡해진다는 의미이다.

단순히 어떤 한가지 일을 하더라도

그 일을 처리하기 위해 수많은 클래스들을 참조하는 결과가 생길 수도 있다.

 

책의 저자도 흘륭한 설계는 적절한 트레이드오프의 결과물이라는 사실을 명심하라고 한다.

 

우리가 직관적으로 관람객과 판매자가 각각 자신의 업무를 맡는다고 생각하고 책임을 맡겼을 때

코드를 더욱 이해하기 쉽다. 이유는 실세계에서도 동일하게 적용 될 수 있기에 그러하다.

 

그러나 가방이 스스로 돈을 꺼내서 티켓을 교환하고,

티켓 매표소가 스스로 돈을 받아서 티켓을 교환해주는 것은

무생물도 자율적인 존재로 취급한 것인데, 객체지향의 세계에서는 흔한 일이다.

레베카 워프스브록은 이처럼 능동적이고 자율적인 존재로 소프트웨어 객체를 설계하는 원칙을 가리켜 의인화라고 표현했다.

 

 

[오늘의 핵심 문장]

코드 설계를 할 때 필연적으로 코드 수정을 초래하고, 코드 수정은 버그가 발생 할 가능성을 높인다.

버그의 가장 큰 문제점은 코드를 수정하려는 의지를 꺾는다는 것이다. 코드 수정을 회피하려는 가장 큰 원인은 두려움이다. 그리고 그 두려움은 요구사항 변경으로 인해 버그를 추가할지도 모른다는 불확실성에 기인한다.