객체지향를 정확하게 구현하고자 오브젝트 라는 책을 구입하였다. 구입하게 된 계기는 우아한형제들 기술블로그에서 신입 개발자의 적응기를 보았다. 자신의 선배가 추천한 책이라고 하였고, 실제로도 많은 도움을 받았다는 후기를 봤다. 웹서핑을 하며 돌아다니다 오브젝트 책에 관한 후기도 몇 개 보기도 하였고 하여 바로 구입!!
객체지향, 학원에서 수강을 할 때 가장 재미있었던 개념이었다. 객체가 상태(field)와 행동(method)을 갖고 있다! 얼마나 간단한가. 숙제로 나온 구슬치기게임(가위바위보와 같은..)을 자바로 쉽게 구현해보기도 하였고 수업시간 동안 어렵다라는 느낌을 받은 적이 없었다.
그런데 카페주문시스템 프로젝트를 하며 당황했다. 객체의 범위를 어디까지 만들어야하는지 명확한 기준이 세워지지 않았다. 일단 만들어보자! 라는 생각을 하여 객체 하나에 주문클래스를 구현하였고…. 프로젝트가 끝날 때까지 리팩토링을 하지 못한 채 하나의 클래스로 만들어버렸다… :scream: 무려 500줄…. 엄청난 뎁스의 메서드들….. 그때부터였다. 객체지향이 어려운게 책임과 역할을 객체에 잘 분배하기 어렵다는 것임을. 끝까지 내가 쫓아가야 할 존재임을.
이러저러한 이유로 오브젝트를 보게 되었고, 다 읽지 못하였지만 지금까지 받은 느낌은 ‘어떻게 이렇게 쉽게 설명할 수 있을까? 멋있다.. 신기하다..’ 이다. 아직 고급단계의 개발자는 아니지만, 저자의 ‘객체지향’에 대한 고민과 탐구 흐름, 그 결과를 문장 사이사이에서 느낄 수 있다. 한줄 한줄이 깨알같다고나 할까… 조금 더 지나서 읽는다면 더 공감되는 부분이 많을 것 같다.
캡슐화란 변할 수 있는 어떤 것이라도 감추는 것
**파급효과(ripple effect)**를 조심해야 한다.
DiscountCondition을 변경하면 Movie, Screening, Reservation Agency 까지 변경하는 상황이 발생한다.
객체는 역할과 책임을 갖고있다. 상태와 행동은 field와 method로 구현됨.
설계의 무게가 외부로 향해야 한다. 즉, 객체간 협력하는 방법에 대해 고민해야 한다.
낮은 결합도를 만들자
의존성을 낮춰야 한다. 제어 로직이 한 객체 안에 밀집되면 안된다.
이런 문제가 발생하는 이유 ? 데이터 중심의 설계 때문 !