[Object] Chapter01. 객체, 설계

안녕하세요 개발자 문문입니다.

오늘부터 조영호님의 'Object - 코드로 이해하는 객체지향 설계' 책을 보며 공부하겠습니다.

코드가 상당히 많아서 각 장의 핵심 내용만 정리하는 방식으로 진행하겠습니다. 

먼저, 1장 객체, 설계입니다.

 

• 잘못된 설계

- 한 객체에서 외부 객체를 호출하고 외부 객체의 필드들을 사용해서 로직을 구현했다고 가정합니다.

- 한 객체에서 너무 많은 역할을 수행해야 돼서 사용하는 외부 객체의 세부적인 내용들을 전부 기억해야 합니다. (높은 의존성)

- 그렇기 때문에 외부 객체의 내부가 변경되면 이를 사용하는 다른 객체도 변경을 해줘야 합니다.  →  변경에 취약하다.

- 위와 같은 경우를 "결합도가 높다" 라고 말합니다. 

ex) 영화 티켓을 구매하는 상황에 티켓 판매자가 손님의 가방안에서 현금을 꺼내서 티켓을 건네줌. (티켓 판매자가 손님의 지갑에 남아있는 현금까지 계산해야 함)

 

• 개선된 설계

- 외부 객체의 세부적인 내용을 몰라도 사용할 수 있게끔 내부 구현을 노출하지 않고 메서드를 통해서만 접근되도록 합니다. 캡슐화

- 캡슐화를 사용하여 설계를 한다면 연관된 작업만 수행하고 연관없는 작업은 다른 객체에게 위임합니다.

- 위와 같은 경우를 "응집도가 높다" 라고 말합니다.

ex) 티켓 판매자는 손님에게 티켓 금액을 알려주며 현금을 달라고 하고(메서드 호출), 손님이 스스로 가방에서 현금을 꺼내어 건네줌. → 손님이 스스로 계산을 함(객체의 자율성)

 

• 트레이오프

- 개선된 설계가 무조건 옳지는 않습니다.

- 객체의 자율성을 높였더니 결합도가 증가하는 경우도 있습니다.

- 이런 경우에는 자율성을 낮출지, 결합도를 낮출지 선택하여 설계를 해야합니다. 

ex) 티켓 판매자가 관리하는 티켓 객체를 따로 분리했다.

- 이런 경우에 티켓에서 판매액을 계산할 때 손님 객체와 의존(손님이 지불하는 현금)을 하게 된다.

- 원래는 티켓 판매자와 손님만 의존 관계 였으나, 티켓이 티켓 판매자와 손님과 모두 의존하게 되는 상황이 발생한다.

- 티켓의 자율성은 증가했으나, 결합도가 증가되었다.

 

• 객체지향 설계

- 훌륭한 객체지향 설계란 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계를 말합니다.

 

https://github.com/moonjinho99/ObjectStudy/tree/master/src/chapter1

깃허브에 정리해둔 코드입니다.