"오브젝트 책 1장 - 객체 설계" 내용을 읽고 공부한 내용을 정리해보았다.
주제는 유연한 설계로 정했다.
책에서 다룬 예제 코드를 알고있다는 전제로 글을 썼기 때문에
모르는 상태로 읽으시는 분이 계시다면 이해하기 어려울 수도 있다.
유연한 설계를 얻기 위해서는?
클래스 간의 의존성이 깊고,
getter와 setter로 다른 클래스 깊숙이 관여할 수 있으면 설계를 변경하기 힘들다.
그러면 어떻게 해야 객체 사이의 결합도를 낮추고, 변경하기 쉽게 만들 수 있을까?
오브젝트 책에서는 다음과 같이 말하고 있다.
- 객체의 자율성 높이기
- 객체 내부사항을 캡슐화
- 책임의 이동
세 가지 내용을 조금 더 자세하게 알아보자.
자율성과 캡슐화
물론 나중에는 연결되는 흐름으로 이어지긴 하지만
책에서는 자율성과 캡슐화에 대해 내용을 단계별로 나눠서 얘기를 했다.
필자는 자율성과 캡슐화는 결국 한몸(?)이란 것으로 이해했다.
객체가 자율성을 지니려면 결국에는 외부에 getter, setter로 상태 값을 넘겨주는 것을 지양하고
스스로 자신의 상태를 처리할 수 있게 만들어야 한다.
이때 스스로 자신의 상태를 처리하는 메서드 로직을 만드는게 캡슐화인것이다.
책임의 이동
책에서는 절차지향과 객체지향의 근본적인 차이를 만드는 것이 "책임의 이동" 이라고 한다.
Java에서는 MVC 패턴을 자주 사용하기 때문에 MVC 패턴 구조로 설명해보겠다.
💡 참고:
MVC 패턴에서Controller는 프로그램 흐름에 따라 각 객체를 이어주는 역할을 한다.
책에서는Theater클래스가 일종의Controller역할을 한다.
절차지향
수정하기 전 코드에서는 극장에 입장하는 절차(프로세스)를 처리하기 위해
Theater에서 순차적으로 객체를 호출하여 필요한 정보를 얻으며, 필요한 로직을 처리했다.
즉, Theater는 객체에 의존하고 있으며 나머지 클래스는 단지 일종의 데이터 제공 역할을 할 뿐이다.
객체지향의 관점에서 보면 Theater에 과도한 책임이 있는 것으로 보인다.
객체지향
그렇다면 수정 후 코드는 어떠한가?
수정 후 코드에서 Theater는 특정 기능이 필요할 때 객체를 호출하고,
해당 기능에 대한 처리는 객체 스스로 처리한다.
즉, Theater에 집중된 책임이 각각의 책체로 "책임이 이동"된 것이다.
예시 - 로또 미션
위에 설명한 내용은 코드로 이해하는 것이 빠를 것 같다.
이전에 필자가 딱 책에서 말한 "수동적인 객체"와 "절차지향적 사고"로 프로그램을 짰었기 때문에
블로그에 따로 정리해보았다.
글의 TOC 중 "🚫 getter를 지양하기" 내용이 절차지향적 코드에서 객체지향적 코드로 변경한 사례이고,
"⭕️ 객체에 메시지 던지기"가 수동적인 객체에서 자율성을 지닌 객체로 변경된 사례가 되겠다.
자세한 내용은 블로그 글을 참고하기 바란다.
