책 표지
읽게 된 계기
친구의 추천으로 읽게 되었으며 결정으로 사서 개인소장하고 싶었다. 최근들어 코드를 짜고 나면 설계가 만족스럽지 못하다는 느낌을 많이 받아서 설계에 관한 책이나 리팩토링에 관한 책을 읽고싶었는데 마침 따끈따끈하고 리뷰가 좋은 '오브젝트' 를 추천받았고 바로 결제했다.
무엇을 정리할지
책을 읽다보면 감명깊게 본 부분이나 핵심적인 내용들이 있다. 정리해놓으면 두고두고 볼 수 있기 때문에 일종의 리스트 형식으로 쭉 편하게 써나가고 싶다. 그리고 책을 읽으며 속으로 느꼈던 점들도 적고싶다.
1장 - 객체, 설계
패러다임
프로그래밍에서의 패러다임은 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다.
프로그래밍 언어와 패러다임을 분리해서 설명할 수 없는 이유는 각 패러다임과 패러다임을 채용하는 언어들이 쓰임새가 다르기 때문이다.
이론 vs 실무
소프트웨어 공학은 건축공학이나 다른 공학에 관한 역사보다 훨씬 짧다. 그렇기 때문에 상대적으로 이론을 정할 수 없는 초기에는 이론보다는 실무가 먼저이고 실무로써 얻는 경험들이나 좀 더 나은 방법들이 이론으로 정립될 수 있다는 주장이다.
'클린코드' 책에서 이런 구절을 본 적이 있다. "자전거 타는 법을 이론으로 100% 이해하는 한이 있더라도 실제로 타면 100% 넘어진다." 위의 말과는 살짝 다르긴 하지만 코드도 결국 짜봐야 자기 자신이 느끼는 나름의 이론이 생겨서 더 빠르게 배울 수 있는 발판이 되는 것 같다.
결합도 - 의존성
A 의 코드를 변경했을 때 B 의 코드도 변경되어야한다. 이 때 A 와 B 는 서로 의존성이 있다고 한다. 즉, 의존성은 어떤 객체가 변경될 때 다른 객체도 변경해야한 다는 사실이 담겨있는 것이다.
의존성을 아예 없애는 것이 정답은 아니다. 의존성이 강한경우에 '결합도(coupling)'이 강하다고 표현하는데 객체와 객체 사이에 결합도는 줄이는것이 변경이 쉬운 유연한 코드를 작성하는 것이 좋다.
캡슐화와 응집도 - 자유도 높이기
캡슐화는 개념적으로나 물리적으로 객체의 세부사항을 감추는것을 말한다. 필요한 인터페이스만 공개하고 불필요한 부분들은 숨겨 객체 내부의 톱니바퀴들을 잘 맞물리게 하는 것이 필요한데 이렇게하면 객체의 응집도를 높일 수 있다.
다른 객체가 어떤 객체의 내부로직까지 알 필요는 없으니 꼭 필요한 인터페이스만 제공하는것이 결합도는 낮추고 응집도는 높여서 꼭 필요한 의존성만 갖게 하는것이 최선의 방법이다.
절차지향과 객체지향의 차이
절차지향은 프로세스와 데이터가 분리되어있다. 하지만 객체지향는 프로세스와 데이터가 결합되어 있다. 객체지향 프로그래밍을 할 때 '자신의 데이터를 스스로 처리하게끔' 하는 것이 핵심이다.
책임의 이동
객체지향에서 책임의 이동(Shift of Responsibility) 이란, 각 객체가 자신이 맡은 일을 스스로 하게끔 분산시키는 것을 말한다. 객체가 어떤 데이터를 가지고 있느냐가 아니라 어떤 책임을 갖게할 것이냐가 핵심이다.
정리
결국 객체사이에 의존성을 최소한으로 갖는다는것은 결합도는 낮추고 응집도를 높이는 것인데 이 때 객체 세부사항을 숨기는 '캡슐화'와 적절한 책임을 부여하는것이 중요하다.