책임 주도 설계
-
데이터보다 행동을 먼저 결정하라
'이 객체가 수행해야 하는 책임은 무엇인가'를 결정한 후에
'데이터를 처리하는 데 필요한 오퍼레이션은 무엇인가'를 결정한다. -
협력이라는 문맥 안에서 책임을 결정하라
메시지를 전송하는 클라이언트의 의도에 적합한 책임을 할당해야 한다.
객체가 메시지를 선택하는 것이 아니라 메시지가 객체를 선택하게 해야 한다.
GRASP 패턴
"General Responsibility Assignment Software Pattern(일반적인 책임 할당을 위한 소프트웨어 패턴)"
객체에게 책임을 할당할 때 지침으로 삼을 수 있는 원칙들의 집합을 패턴 형식으로 정리한 것이다.
설계 시작 전, 도메인에 대한 개략적인 모습을 그려보는 것이 유용
따라서, 어떤 책임을 할당해야 할 때 먼저 고민해야 하는 유력한 후보는 도메인 개념이다.
정보 전문가에게 책임을 할당하라
- 책임을 수행할 정보를 알고 있는 객체에게 책임을 할당하는 것
GRASP에서는 이를 INFORMATION EXPERT(정보 전문가) 패턴이라고 부른다.
높은 응집도와 낮은 결합도
객체에 책임을 할당할 때 항상 고려해야 하는 기본 원리다. 책임을 할당할 수 있는 다양한 대안드링 존재한다면응집도와 결랍도의 측면에서 더 나은 대안을 선택하는 것이 좋다. 다시 말해 두 협력 패턴 중에서 높은 응집도와 낮은 결합도를 얻을 수 있는 설계가 있다면 그 설계를 선택해야 한다는 것이다.
GRASP에서는 이를 LOW COUPLING(낮은 결합도) 패턴과 HIGH COHESION(높은 응집도) 패턴 이라고 부른다.
창조자에게 객체 생성 책임을 할당하라
GRASP의 CREATEOR(창조자) 패턴은 객체를 생성할 책임을 어떤 객체에게 할당할지에 대한 지침을 제공한다.
낮은 응집도를 해결하기 위해서는 변경의 이유에 따라 클래스를 분리해야 한다.
코드를 통해 변경의 이유를 파악할 수 있는 방법
- 인스턴스 변수가 초기화되는 시점을 살펴보기
함께 초기화되는 속성을 기준으로 코드를 분리해야 함.
- 메서드들이 인스턴스 변수를 사용하는 방식을 살펴보기
속성 그룹과 해당 그룹에 접근하는 메서드 그룹을 기준으로 코드를 분리해야 함.
책임 주도 설계의 대안
겉으로 보이는 동작은 바꾸지 않은 채 내부 구조를 변경하는 것을 리펙터링 (Refactoring)
메서드 응집도
긴 메서드는 다양한 측면에서 코드의 유지보수에 부정적인 영향을 미치게 된다.
- 어떤 일을 수행하는지 한눈에 파악하기 어렵기에, 코드를 전체적으로 이해하는데 너무 많은 시간이 걸린다.
- 하나의 메서드 안에서 너무 많은 직업을 처리하기 때문에 변경이 필요할 때 수정해야 할 부분을 찾기 어렵다.
- 메서드 내부의 일부 로직만 수정하더라도 메서드의 나머지 부분에서 버그가 발생할 확률이 높다.
- 로직의 일부만 재사용하는 것이 불가능하다.
- 코드를 재사용하는 유일한 방법은 원하는 코드를 복사해서 붙여 넣는 것뿐이므로 코드 중복을 초래하기 쉽다.
긴 메서드는 응집도가 낮기 때문에 이해하기도 어렵고 재사용하기도 어려우며 변경하기도 어렵다.
이를 몬스터 메서드 라고 부른다.
객체를 자율적으로 만들자
자신이 소유하고 있는 데이터를 자기 스스로 처리하도록 만드는 것이 자율적인 객체를 만드는 지름길이다.
따라서 메서드가 사용하는 데이터를 저장하고 있는 클래스로 메서드를 이동시키면 된다.
캡슐화, 결합도, 응집도를 이해하고 훌륭한 객체지향 원칙을 적용하기 위해 노력한다면 책임 주도 설계 방법을 단계적으로 따르지 않더라도 유연하고 깔끔한 코드를 얻을 수 있을 것이다.
