[TIL] 객체지향은 ‘생성’과 ‘사용’의 책임을 분리하는 것에서 시작

전자제품 목록을 출력하는 간단한 커머스 플랫폼 과제를 진행하다가 문득 이런 의문이 들었다.

public class CommerceSystem {
    private List<Product> products = new ArrayList<>();
}

그냥 CommerceSystem 안에서 List<Product>를 직접 생성하면 되는 거 아닌가?

왜 굳이 아래처럼 밖에서 만들어서 전달받는 걸까?

List<Product> products = ...

CommerceSystem system =
        new CommerceSystem(products);

처음에는 명확하게 설명하기 어려웠지만, 곰곰이 생각해 보니 ‘역할 분리’와 관련이 있다는 생각이 들었다.

---

CommerceSystem의 책임은 무엇인가?

객체지향에서는 항상 이런 질문을 던져야 한다.

“이 객체는 무슨 일을 해야 하는가?”

CommerceSystem의 역할은 상품 목록을 이용해서 프로그램을 동작시키는 것이다.

예를 들면,

• 상품 목록 출력
• 사용자 입력 처리
• 선택한 상품에 따른 로직 실행

등을 담당한다.

반대로 상품 목록을 만드는 것은 CommerceSystem의 본질적인 책임이 아니다.

즉, CommerceSystem의 책임은 상품 목록을 ‘사용’하는 것이지, 상품 목록을 ‘생성’하는 것이 아니다.

---

만약 CommerceSystem이 직접 생성한다면?

public class CommerceSystem {
    private List<Product> products = new ArrayList<>();
}

처음에는 별문제 없어 보인다.

하지만 조금만 생각해 보면 CommerceSystem은 너무 많은 일을 하게 된다.

1. List 생성
2. Product 생성
3. 상품 관리
4. 사용자 입력 처리
5. 화면 출력

하나의 객체가 여러 책임을 가지기 시작한다.

결국 CommerceSystem은 상품 관리 시스템이 아니라, 상품 생성 공장 + 상품 관리자 + 화면 관리자가 되어버린다.

객체 하나가 점점 비대해지고, 수정하기 어려워진다.

---

밖에서 주입받으면 무엇이 달라질까?

List<Product> products = ...

CommerceSystem system =
        new CommerceSystem(products);

이렇게 하면 책임이 분리된다.

main

데이터 준비 담당

CommerceSystem

준비된 데이터를 이용해
프로그램을 동작시키는 담당

각자가 자신의 역할만 수행하게 된다.

객체지향은 이런 식으로 객체마다 명확한 책임을 부여하는 방향으로 설계한다.

---

재사용성도 좋아진다

예를 들어 내일 과제가 바뀌었다고 해보자.

기존

전자제품
↓
도서

로 변경되었다.

만약 CommerceSystem 안에

products.add(new Product("Galaxy", ...));
products.add(new Product("iPhone", ...));

같은 코드가 박혀 있다면 CommerceSystem 자체를 수정해야 한다.

하지만 생성자 주입 방식을 사용하면,

List<Product> books = ...

new CommerceSystem(books);

만 하면 된다.

CommerceSystem은 아무것도 수정하지 않는다.

왜냐하면 애초에 이 객체의 관심사는 “전자제품인지, 도서인지”가 아니라, “List를 관리한다.” 뿐이기 때문이다.

---

테스트도 쉬워진다

List<Product> testProducts = new ArrayList<>();
testProducts.add(
        new Product("테스트상품", 1000, "테스트", 1)
);

CommerceSystem system =
        new CommerceSystem(testProducts);

테스트용 데이터만 만들어서 원하는 상황을 쉽게 검증할 수 있다.

객체가 직접 생성하지 않고 외부에서 주입받기 때문에 다양한 데이터를 자유롭게 넣어볼 수 있다.

---

객체지향의 핵심 철학

오늘 가장 크게 깨달은 점은 이것이다.

객체는 필요한 것을 직접 만들어 쓰기보다, 외부로부터 받아서 사용하는 편이 더 유연하다.

그리고 이 생각은 나중에 배우게 될 여러 개념으로 이어진다.

• 결합도를 낮춘다.
• 생성과 사용의 책임을 분리한다.
• 단일 책임 원칙(SRP)에 가까워진다.
• 의존성 주입(DI)의 출발점이다.

“누가 생성해야 하는가?”, “누가 사용해야 하는가?”, “이 객체의 진짜 책임은 무엇인가?” 를 계속 고민하는 것.

그 고민이 객체지향 설계의 시작이라는 것을 배웠다.