인프런 커뮤니티 질문&답변

뒷부분에 더 자세히 설명해주시는지 모르고 마음이 급해 질문을 남겼습니다 ㅜ 해주신 설명과 뒷부분 강의를 보면서 이해가 됐습니다 ! 좋은 강의 정말 감사드립니다 :)

ttt123님 안녕하세요.

좋은 질문 남겨 주셔서 감사합니다.

현재 코드 구조를 그려보면 아래 그림처럼 Movie는 추상클래스인 DiscountPolicy에만 의존하고 있습니다.

DiscountPolicy의 서브클래스들과 DiscountCondition은 추상클래스인 DiscountPolicy 내부에 숨겨져 있기때문에 Movie의 입장에서는 접근할 수가 없습니다.

다시 말해서 Movie의 입장에서는 DiscountPolicy 추상클래스만 보이고 다른 클래스들은 보이지 않는 것이죠.

이 개념은 캡슐화(Encapsulation)로 연결되며 Discountpolicy 추상클래스만 변경하지 않는다면 Movie는 영향을 받지 않게 됩니다.

결과적으로 DiscountPolicy 클래스를 기준으로 구조를 변경하더라도 Movie에는 영향을 미치지 않는 것이죠.

만약 Movie가 DiscountPolicy와 DiscountCondition 모두에 의존한다면 변경에 의해 더 자주 영향을 받게 되었을 것입니다.

변경의 영향을 최소화하기 위해 DiscountCondition을 DiscountPolicy 뒤로 숨겼다고 생각하시면 될것 같아요.

6-3. 결합도와 6-4. 캡슐화를 보시면 더 깊이 있게 이해하실 수 있으실거에요. 🙂

보시고 궁금한 점 있으면 또 질문 남겨 주세요!

안녕하세요, 인프런 AI 인턴입니다.

ttt123님께서 질문하신 DiscountCondition을 DiscountPolicy 뒤에 숨겨야 하는 이유는 객체지향 설계의 캡슐화와 모듈화를 이해하는 데 중요한 부분입니다.

이유 설명

1. 캡슐화: DiscountPolicy가 DiscountCondition을 숨기는 이유는 내부 구현을 외부로부터 감추어 변경에 의한 영향을 최소화하기 위함입니다. DiscountPolicy가 DiscountCondition과 함께 작동해야 하는 로직이지만, 외부에서는 그 세부 구현을 알 필요가 없습니다. 따라서 외부에서는 DiscountPolicy에만 의존하게 함으로써 내부 구조의 변경이 서비스나 클라이언트 코드에 영향을 미치지 않도록 설계할 수 있습니다.

2. 단일 책임 원칙: DiscountPolicy는 할인 금액을 결정하는 역할을 합니다. DiscountCondition은 할인 여부를 결정해주는 조건을 포함하는 부분입니다. 이들을 하나의 모듈로 묶어 둠으로써 추가적인 할인 조건이 필요할 때도 DiscountPolicy 측면에서 관리하고 수정할 수 있게 됩니다.

3. 유지보수성 향상: 여러 DiscountCondition을 관리하게 되는 상황에서, 각 조건이 변경되어도 그것을 사용하는 클라이언트 코드인 Reservation Service는 영향을 받지 않습니다. 이는 유지보수성을 크게 향상시킵니다.

관련 내용

이와 관련된 구현 및 설계에 대한 더 자세한 설명은 아래의 게시글에서 찾아볼 수 있습니다:
- 영화가 정책을 1개만 갖는데 비해 정책이 다수의 컨디션을 갖는 디자인에 대해

이 질문에서는 한 객체가 다수의 조건들을 가질 때의 설계를 깊이 있게 논의하고 있으며, 어떻게 이러한 설계가 응집도를 유지하면서 다양한 조건을 처리할 수 있는지에 대해 다루고 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.