Chapter 4. 설계 품질과 트레이드오프

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다.

---

협력, 책임, 역할 그리고 설계 품질

 

협력은 객체들 간 메시지를 주고받으며 진행되는 상호작용이다.

 

책임은 객체가 수행하는 행동이다.

 

역할은 책임들의 집합이다.

 

협력, 책임, 역할 할당이 잘 되어야 바람직한 객체 지향 설계가 가능해진다.

 

 

💡 그 중에서도 책임이 잘 할당되는 것이 중요하다.

 

 

🚨 역할은 책임의 집합이기 때문에, 책임의 품질에 의존하게 된다.

 

협력 역시, 책임이 잘 할당되지 못하면 효율적으로 할 수 없게된다.

 

 

❓ 책임을 어떤 식으로 할당해야할까?

 

비슷한 책임끼리 하나의 목적을 위해 협력하는 것 끼리 모아두는 높은 응집도와

 

다른 책임끼리 분리하는 낮은 결합도를 만족하도록 하는 것이 좋다.

 

그래야만, 변경이 일어났을 때 전파되는 영역이 줄어들고 변경 비용을 아낄 수 있다.

 

 

데이터 중심이 아닌 책임 중심 사고

 

데이터를 초점에 맞추어 생각하면 변화에 민감해진다.

 

데이터라는 것은 추상적일 수 없고, 구체적이기 때문이다.

 

또한, 애초에 어떤 데이터를 생각하고 객체간 협력을 생각하게 되면 캡슐화의 원칙이 무너질 수 있다.

 

 

잘 설계한 객체 지향이란?

 

요구사항은 늘 변경되기 마련이므로, 코드의 변경은 피할 수 없다.

 

캡슐화가 가장 중요한 이유는, 변경에 불안정한 부분과 안정적인 부분을 분리해서 통제할 수 있기 때문이다.

 

변경될 수 있는 모든 것들은 캡슐화하여 드러내지 않도록 하는 것이 좋다.

 

💡 높은 응집도와 낮은 결합도는 곧 바람직한 객체 지향 설계임을 의미한다고 했는데 무슨 말일까?

 

변경의 관점에서, 변경이 발생할 때 변경을 수용하기 위해 모듈 전체가 함께 변경된다면 응집도가 높은 것으로 볼 수 있다.

 

또한, 하나의 모듈만 변경된다면 응집도가 높은 것으로 볼 수 있지만 여러 모듈이 변경되어야 한다면 응집도가 분산된 것으로 볼 수 있다.

 

💡 응집도가 높을 수록 변경되는 모듈의 개수는 적어지고, 변경해야할 대상과 범위를 명확하게 할 수 있다.

 

결합도란, 변경이 발생할 때 한 모듈이 다른 모듈에게 변경을 요구하는 정도로 파악할 수 있다.

 

결합도가 높으면 높을수록 한 모듈이 변경을 요청하는 모듈이 많아지므로 변경의 전파가 커짐을 의미한다.

 

 

get, set 메서드는 캡슐화?

public class Movie{
	private Money fee;
    
    public Money getFee(){
    	return fee;
    }
    
    public void setFee(Money fee){
    	this.fee = fee;
    }
}

 

위 코드는 메서드를 거쳐서 객체 내부에 접근할 수 있어서 캡슐화를 지킨 것 처럼 보인다.

 

🚨 하지만, 메서드 이름에서부터 해당 객체가 가진 필드의 이름을 드러내고 있으며, 해당 필드의 타입도 고정되게된다.

 

따라서, fee 타입에 변화가 생기면 해당 메서드를 사용하는 모든 다른 코드들에 변화가 전파될 것이다.

 

 

💡 객체는 자신이 어떤 데이터를 가지고 있는지를 외부에 공개해서는 안된다. 그것이 메서드의 이름이든, 파라미터든, 반환타입이든 말이다.

 

객체는 스스로의 상태를 책임져야 하고, 외부에서는 인터페이스에 정의된 메서드를 통해서만 상태에 접근할 수 있도록 하는 것이 좋다.