Spring의 OOP를 제대로 이해하기 위해 OOP스럽지 않은 사례에 대해 먼저 학습한다.

강의 내 사이트 링크

• Rod johnson, "Spring Framework: The Origins of a Project and a Name", Spring, https://spring.io/blog/2006/11/09/spring-framework-the-origins-of-a-project-and-a-name  (accessed December 18, 2022)

보강 설명

Q. PriceCalculator라는 도메인 서비스보다 Cashier라는 도메인으로 만드는 게 좋다는 말이 맞는 건가요?

A. 네, 적어도 저는 그렇게 생각합니다.

• PriceCalculator라고 부르면 가격 계산만을 하겠다는 의미입니다. 그렇게 되면 사실상 유의미한 객체가 만들어지는 게 아니라고 봅니다. 함수를 랩핑하는 클래스들이 무수히 생겨날 뿐이고요.
• 그렇게 되면 사실상 절차 지향 프로그래밍과 다를 게 없습니다. 나중에 가서는 *"기존 서비스랑 다른 게 뭐지?"*라는 생각이 드실 거에요.
• 요점은 도메인 영역을 풍부하게 만들라는 것입니다. 그리고 강의의 목적은 스프링에 잘못 적힌 절차 지향적 코드를 객체 지향적으로 만드는 것입니다.
• 근데 또 단일 책임 원칙에 따르면, 역할은 분리가 되어야 하는 게 맞습니다. 그래서 PriceCalculator처럼 가는 것도 나쁘지 않습니다.
• 그러한 이유로 이는 사실상 호불호의 영역입니다.

설계는 트레이드 오프가 항상 있고, 정답이 정해져 있지 않습니다. 따라서 이렇게 혼란스러운 상황에서 사용할 수 있는 가장 확실한 명제는 이겁니다.

"구조적으로 테스트하기 쉬운 코드면 무슨 코드든 좋다."

• --

Q. 도매인 서비스도 빈으로 만드는 게 맞나요?