루비로 배우는 객체지향 디자인
처음 구매 했을때는 주변 루비 개발자분들이 좋은책 이라고 해서 구매했지만 막상 읽지를 않고 책장에 꽃혀있던 책을 블로그 포스팅을 위해 꺼내서 읽었습니다.
작성은 각 장에서 깨달은 내용을 적으려고 합니다. 총 9장 인데 각 장의 내용이 묵직해서 쓰려고 하니 조금 길어지는 경향이 있어 한장한장 나눴습니다.
책 제목은 루비지만 꼭 루비가 아니더라도 객체지향 디자인을 원하는 사람에게는 좋은 책이고 최근 컴포넌트 잘 나누기 등 여러 곳에서 쓰이는 기본 지식이기에 재대로 정리해보고 싶습니다.
1. 객체지향 디자인
이 세상을 객체지향적으로 본다는건 세상을 이미 정해진 절차들의 묶음으로 생각하지 않고 객체가 서로 주고 받는 메세지들의 연쇄로 생각하고 봐야한다.
객체지향 어플리케이션은 각 객체가 주고 받는 메세지를 통해 구성되어 있는데 이러한 발신과 수신을 통해 객체가 서로에 대해 어느정도 알게 되는데 이 관계가 의존성을 만들어내 하나의 객체를 수정하면 그와 의존성이 묶인 객체들을 수정해야하고 이때문에 어플리케이션의 수정이 어려워진다.
따라서 객체지향 디자인은 이러한 의존성을 관리하는 것이 주 목표다.
관리에 대한 원칙으로 디자인 원칙이라는 것이 있는데 아래와 같다.
- 단일 책임
- 개방-폐쇄
- 리스코프 치환
- 인터페이스 분리
- 의존성 역전
하지만 잊어서는 안되는 부분이 존재한다.
객체지향 디자인은 필요할 수도 필요하지 않을 수도 있다.
만약 여기에 평생 바뀌지 않는 소프트웨어가 있다면 객체지향 디자인은 사실상 필요가 없다. 그것이 소프트웨어를 개발하기 위한 최적의 방법이 아닐 수 있기 때문이다.
그럼에도 객체지향 디자인을 알아야 하는 이유는 미래를 대비해 가능한 여러가지 선택지를 만들어 놓기 위해서다.
한번에 모든 항목을 디자인 할 수는 없다. 작은 코드 조각을 보여줌으로써 처음 고객이 원했던 소프트웨어와 다른 진정으로 원하는 소프트웨어의 모습이 만들어지고 이때 객체지향 디자인으로 만들어둔 여러가지 선택지는 개발에 주어진 시간 안에서 최적의 구현 비용을 만드는데 도움을 주기 때문에 객제지향 디자인은 필요하다.
객체지향 디자인을 통해 만들어진 객체지향 어플리케이션에 대한 수량화를 하기 위한 노력들이 존재했었는데 이때의 기준은 “전체적인 클래스의 크기, 클래스가 다른 클래스와 얽혀있는 정도, 상속 관계의 높이와 너비, 메세지 전송이 유발하는 실행 횟수 등"이 있다. (ruby metrics)
흔히 알려진 디자인 패턴은 “객체지향 소프트웨어 디자인에서 명확한 문제를 처리하는 간단하고도 우아한 해결책"이라고 보면 좋다. 하지만 이것도 단점이 존재하는데 디자인 패턴에 대한 오용이 있다.
디자인 패턴에 대한 오용은 간단하게 해결되어야 했을 문제를 복잡하고 혼란스럽게 만들 수 있다.
객체지향 디자인에서도 실패하는 경우가 있는데 이는 2가지 케이스를 볼 수 있다
- 디자인 자체가 부족한 경우, 어플리케이션을 못만드는건 아니지만 붕괴의 씨앗을 품은 어플리케이션이 만들어진다.
- 지나치게 디자인 하는 경우, 나쁜 의도로 지나치게 디자인 하는 일은 없다. 좋은 의도로 디자인 했는데 그 디자인이 지나치게 많을 뿐인 경우에는 자신이 만들어둔 혹은 팀원이 만들어둔 디자인 속에서 나오기 힘들어진다.
마지막으로 구현에 타협을 해서 하드 코딩을 하거나 뒤를 생각하지 않고 구현한다면 이는 결국 기술적으로 빚을 지는 것이고 이 기술적 부채는 언젠가 이자와 함께 묵직한 빚이 되어 돌아오게 된다.