4장 정리
협력은 애플리케이션의 기능을 구현하기 위해 메시지를 주고 받는 객체들 사이의 상호작용이다.
책임은 객체가 다른 객체와 협력하기 위해 수행하는 행동이다.
역할은 대체 가능한 책임의 집합이다.
설계는 변경을 위해 존재하고 변경에는 어떤 식으로든 비용이 발생한다.
훌륭한 설계란 합리적인 비용안에서 변경을 수용할 수 있는 구조를 만드는 것이다.
이는 곧 응집도가 높고 서로 느슨하게 결합돼 있음을 의미한다.
객체지향 설계란 올바른 객체에 올바른 책임을 할당하면서, 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동이다.
객체의 상태가 아닌, 객체의 행동에 초점을 맞추면 결합도와 응집도를 합리적인 수준으로 맞출 수 있다.
객체를 단순한 데이터의 집합으로 바라보는 시각은 객체의 내부 구현을 퍼블릭 인터페이스에 노출시키므로 변경에 취약해진다.
따라서 객체의 행동, 즉 책임에 초점을 맞추면 객체 사이의 상호작용으로 설계 중심을 이동시키고,
결합도가 낮고 응집도가 높으며 내부 구현을 효과적으로 캡슐화하는 객체들을 창조할 수 있는 기반을 제공한다.
객체의 상태는 구현에 속하며, 구현은 불안정하기 때문에 변하기 쉽다.
상태를 객체 분할의 중심축으로 삼으면 구현에 관한 세부사항이 객체의 인터페이스에 스며들어 캡슐화의 원칙이 무너진다.
캡슐화
객체지향에서는 상태와 행동을 하나의 객체 안에 모아 내부 구현을 외부로부터 감춘다.
이처럼 외부에서 알 필요 없는 부분을 감춤으로써 대상을 단순화하는 추상화 기법을 캡슐화라고 한다.
캡슐화를 통해 변경 가능성이 높은 부분인 구현은 내부에 숨기고 상대적으로 안정적인 부분인 인터페이스를 외부에 공개한다.
외부에서는 인터페이스에만 의존하도록 관계를 설정하여 변경에 대한 파급효과를 줄일 수 있다.
설계는 변경을 위해 존재하고, 불안정한 부분과 안정적인 부분을 분리해서 변경의 영향을 통제하는 캡슐화는
객체지향 설계에서 매우 중요한 요소이다.
응집도와 결합도
응집도는 모듈에 포함된 내부 요소들이 연관돼 있는 정도를 나타낸다.
결합도는 의존성의 정도를 나타내며, 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타낸다.
이 둘은 변경과 관련 요소이며, 캡슐화를 지킬수록 모듈 내의 응집도는 높아지고 모듈간의 결합도는 낮아진다.
데이터 중심 설계의 문제점
데이터 중심 설계는 설계를 시작하는 처음부터 데이터를 정해두기 때문에 너무 이른 시기에 내부 구현에 초점을 맞춘다.
데이터와 기능을 분리하는 절차적 방식은 상태와 행동을 하나의 단위로 캡슐화하는 객체지향 패러다임에 반한다.
데이터에 초점을 둔 설계는 getter, setter 를 퍼블릭 인터페이스로 열어놓게 되어 내부 구현이 인터페이스로 스며든다.
이는 캡슐화를 저해하게 되며, 결국 변경에 취약한 설계로 이어진다.
따라서 객체에게 스스로 자신의 데이터를 책임지게 만들어야한다.
캡슐화의 진정한 의미란 변하는 어떤 것이든 감추는 것이다. 그것이 무엇이든 구현과 관련된 것이라면 감춰야한다.
인상깊었던 점
"객체지향 설계란 올바른 객체에 올바른 책임을 할당하면서, 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동이다."
이번 장은 이 문장에 대한 설명이었던것 같다. 그 중 캡슐화 파트 부분이 인상깊었다.
캡슐화라고 하면 "내부 구현을 숨긴다" 정도로 생각했지만, 변경 가능성이 높은 구현을 숨기고 상대적으로 안정적인 인터페이스를 외부에 공개하는 추상화 기법 이라는 좀 더 나은 답변을 할 수 있을것 같다.
이 책을 읽으면서 객체지향 프로그래밍이란 무엇인가 라는 질문에 대해 어떻게 정리할지 생각해보고 있다.
완독 후에 기존에 정리했던 OOP 와 이 책을 읽고 난 후에 다시 정리한 OOP 내용을 비교해보면 재미있을것 같다.