OOP관점에서 객체의 생성과 사용을 분리해야하는 이유?

[haeyoon1]

[오브젝트 9장] - p287

메시지를 전송하지 않고 객체를 생성하기만 한다면 아무런 문제가 없었을 것이다. 또는 객체를 생성하지 않고 메시지를 전송하기만 했다면 괜찮았을 것이다. 동일한 클래스 안에서 객체 생성과 사용이라는 두 가지 이질적인 목적을 가진 코드가 공존하는 것이 문제인 것이다.

객체를 생성하는 것도 결국 객체의 책임이 아닌가요?
그렇다면 객체의 생성과 사용을 굳이 분리해야 하는 이유는 무엇일까요?

[Uechann]

객체의 생성과 사용이 무엇인지에 대해 자세히 먼저 생각해볼 수 있을거 같습니다.

객체의 생성

먼저 객체의 생성에서는 그 객체가 생성되기 위한 모든 정보들을 알아야 하고 그 정보들을 담고 있다고 생각할 수 있을거 같습니다.

객체의 사용

객체의 사용은 생성된 객체의 인터페이스를 통해 접근하고 어떤 메시지를 던지고, 어떤 매개변수를 통해 어떤 반환값을 받을 것인지에 대한 정보가 필요하다고 볼 수 있을거 같습니다.

결국 생성과 사용에서는 규모가 커질 경우, 두 책임의 무게가 커진다면 3가지 문제점이 있을거 같습니다.

1. 구체 클래스에 대한 결합도 증가
2. 생성과 사용이 같이 존재한다면 응집도 감소
3. 테스트 용이성 감소

[softmoca]

결합도와 응집도 문제 언급 👍🏻 👍🏻 👍🏻

[koreaioi]

결론

결론: 객체 생성 자체가 문제이기 보다는, 사용할 객체의 구체타입을 내부에서 직접 결정하는 걸 지양해야한다.

• 객체가 협력하는 객체의 구체타입을 알게되어 의존성 증가
• 의존성 증가로 인한 강결합은 확장에 약하다.
• 테스트 용이성 감소 (마이찬 코멘트 참고)

---

사고 흐름

객체를 생성하는 것도 객체의 책임이라 볼 수 있습니다. 다만 여기서 말하는 생성을 조금 자세하게 나누어볼 필요가 있다고 생각합니다.

public Movie(String title, Duration runningTime){
	this.title = title;
	this.runningingTime = runningingTime;
}

객체가 자기 자신의 상태를 초기화하고, 올바른 상태로 만드는 건 객체의 책임입니다. 외부에서 전달받은 title, runningTime을 이용해, 자기 자신의 상태를 올바르게 초기화하고 있으니까요.

1. 생성자 파라미터로 변수나 객체를 전달받는다.
2. 전달받은 내용을 올바르게 자신의 상태로 초기화한다.

그래서 저는 책에서 말하는 "객체의 생성과 사용을 분리하라" 에서

생성에서, title과 runningTime같은 초기화 대상(1번)을 외부로부터 주입받도록 분리하라로 이해했습니다.
또한 우리가 주로 사용하는 생성자 방식도, 위처럼 흔하게 사용하기도 하구요.

---

이에 어긋나는 예시가 협력 객체의 구체타입까지 직접 결정해버리는 경우입니다.

public Movie(String title, Duration runningTime){
	this.title = title;
	this.runningingTime = runningingTime;
	this.discountPolicy = new AmountDiscountPolicy(); // Movie 내부에서 협력할 객체의 구체 타입을 알고있음.
}

만약 AmountDiscountPolicy을 PercentDiscountPolicy로 변경한다면, Movie 내부 코드를 수정해야합니다. 여기서 구체화될 수록 변경에 취약해질 수 있음을 관찰할 수 있습니다.

위에서 드러난 구체화(구체타입 결정)를 다음과 같이, 외부로부터 주입받으면, Movie의 수정 없이, Policy를 변경할 수 있습니다.

public Movie(String title, Duration runningTime, DiscountPolicy policy){
	this.title = title;
	this.runningingTime = runningingTime;
	this.discountPolicy = policy;
}

// new Moive("아이언맨", "160", new AmountDiscountPolicy());
// new Moive("아이언맨", "160", new PercentDiscountPolicy());

여기서 외부로부터 주입받고자, 파라미터로 빼는 것 말고도 주입받고자 하는 대상에 다형성이 적용되어 있어야한다고 생각합니다.
때문에 저자는 이부분에 대해서, "OCP의 핵심은 추상화에 의존하는 것이다." 라고 말하는 것 같구요.

[softmoca]

생성을 2단계로 나누어

생성에서, title과 runningTime같은 초기화 대상(1번)을 외부로부터 주입받도록 분리하라로 이해
하신 전체 전인 사고 과정 저도 매우 동의합니다 ~
해당 디스커션의 킥이라 생각되네요 !
깔끔하게 잘 정리해주셔서 감사해요 송송 ~

[sangjun121]

답변

• 책에서 의도한 내용은, 객체가 의존하고 있는 외부 객체의 생성을 내부가 아닌 외부 주입으로 변경하자.라고 생각합니다.
• 따라서 여기서 말하는 "객체" 사용/이용은 모두 "의존하고 있는 객체"를 의미합니다.

객체 의존을 생성자 인터페이스로 공개하자.

• 여기서 말하는 인터페이스는 외부에 공개된 생성자 시그니처를 의미합니다. 즉, 해당 객체가 의존하고 있는 "구체 클래스"를 생성자 내부에서 new 키워드로 생성하는 것이 아닌, 생성자 인자를 통해 외부에서 주입받는 것이 OCP 측면에서 좋다고 말하고 있습니다.

왜 생성자 시그니처로 공개하는 것이 객체지향적인가?

저는 2가지 이점이 있다고 생각합니다. 바로 외부 의존성 표현과 다형성의 활용 장점입니다.

1. 외부 의존성 표현

• 특정 객체가 어떤 객체에 의존하고 있는지 생성자 시그니처를 통해 표현할 수 있습니다. 이 덕분에 테스트 시점에도 외부 의존성을 분리하고 검증하기 유리하다고 생각합니다.

2. 다형성 활용

• 외부 의존을 구체클래스가 아닌 추상화에 의존할 수 있습니다. 이 또한 요구사항 변경시 변경가능지점을 줄여주는 개방 폐쇄 원칙에 부합하는 설계라고 생각합니다.

[softmoca]

외부 의존성 표현 언급 👍🏻 👍🏻 👍🏻

"변경가능지점" 이라는 단어가 아래 두가지로 읽혀 약간 오해가 생길 수 있을 것 같다고 느껴졌습니다.

• 변경할 수 있는 확장 지점을 줄인다는 뜻
• 변경이 전파되는 지점 / 수정해야 하는 지점을 줄인다는 뜻

"수정해야 하는 코드의 범위를 줄일 수 있다." 와 같이 조금 더 명확하게 표현하는것에 대해 어떻게 생각 하시나요 ?!