인프런 커뮤니티 질문&답변
작성한 질문수
[5-1] Screening과 Movie의 의존관계에 대한 궁금증 질문입니다.
해결된 질문
작성
·
14
1
안녕하세요!
추석에 좋은 강의 잘 듣고 있습니다!
5-1 강의 3분 20분초에 보면 Screening은 프로퍼티로 movie를 가지게 되므로 Screening -> Movie의 의존성을 가지게 되는데요
이때 Movie는 내부 구현에서 메서드의 파라미터로 Screening을 받는 구조에서 프로퍼티가 아닌 파라미터지만 Movie -> Screening의 의존이 생긴다고 볼 수 있지 않을까요?
이렇게되면 Screening <-> Movie의 상호의존성이 생긴다고 볼 수 있을거 같은데 이러한 상호 의존도 괜찮나요?
제가 사용하는 언어인 Swift에서는 코드의 양이 조금 늘어나더라도 이 경우 프로퍼티나 파라미터 둘 중에 하나를 프로토콜(인터페이스)로 변경해서 상호 의존성을 끊어주는 방식을 사용하는데 트레이드오프로 생각하고 같은 계층에 속한 모델의 경우 이정도의 상호 의존은 생겨도 놔둘것인지 이러한 중간 객체 추가로 상호의존을 끊을것인지 선택하면 되는걸까요?
답변 2
0
BeePeach님 안녕하세요.
좋은 질문 남겨주셔서 감사합니다. 🙂
말씀하신 것처럼 현재 코드는 Screening과 Movie 사이에 양방향 의존관계가 존재합니다.
추가로 DiscountCondition과 DiscountPolicy까지 함께 보면 의존성이 사이클이 돈다는 사실도 알 수 있습니다.
객체지향 설계는 의존성을 관리하는 것이 핵심이기 때문에 이런 복잡하게 얽힌 의존성이 문제로 보일 수 있습니다.
여기에서 중요한 것은 의존성을 통제하기 위해서는 먼저 변경에 의해 영향을 받는 범위를 결정해야 한다는 점입니다.
만약 두 개의 클래스를 변경에 대해 함께 변경해야 하는 단위로 생각하면 두 클래스 사이의 양방향 의존성은 크게 문제가 되지 않습니다.
오히려 두 클래스 사이의 의존성을 단방향으로 만들기 위해 새로운 추상화를 도입하면 설계가 과도하게 복잡해 지게 됩니다.
만약 두 개의 클래스가 서로 다른 변경 단위라면 이 의존성을 그대로 두면 서로 다른 이유때문에 두 클래스가 항상 함께 변경되기 때문에 두 클래스 사이의 양방향 의존성을 제거하는 것이 합리적입니다.
이 경우에는 새로운 추상화를 추가하더라도 증가한 복잡성을 감수할 수 있습니다.
기계적으로 의존성을 끊어서 전체적인 복잡성을 올리는 것보다는 변경의 범위에 따라 의존성의 정도(다른 말로 결합도라고 부릅니다)를 트레이드오프하는게 실용적입니다.
아래는 다른 분들이 질문하신 내용인데 참고하시면 도움이 되실거에요.
현재 설계에 대한 트레이드오프 과정이 궁금하시다면 아래 글을 읽어보시길 권해드립니다.
두 클래스 사이의 결합도를 낯주는 방향에 대해서는 아래 글을 읽어 보시면 좋습니다.
답변이 되었는지 모르겠네요.
행복한 추석 연휴 보내시고 추가적으로 궁금한 부분이 있으면 또 질문 남겨주세요!
감사합니다. 😄
0
안녕하세요, 인프런 AI 인턴입니다.
BeePeach님께서 제기하신 Screening과 Movie 사이의 상호의존성 문제는 객체지향 설계에서 흔히 다뤄지는 주제로, 이러한 의존성이 시스템의 유연성과 유지보수에 미칠 영향을 고민하게 만듭니다.
상호의존성의 이해
상호의존성: 두 클래스가 서로를 직접 참조하는 구조는 상호의존성을 만들어내며, 이는 객체 간의 결합도를 높입니다. 이러한 높은 결합도는 객체 중 하나의 변경이 다른 객체에 미치는 영향을 증가시키므로 일반적으로 피하는 것이 좋습니다.
의존성 설정:
- Screening이 Movie를 프로퍼티로 가지는 것은 Screening이 Movie에 대한 강한 의존성을 가짐을 의미합니다.
- Movie가 파라미터로 Screening을 받는 것은 직접적이지 않지만, 여전히 의존 관계를 형성합니다.
- Screening이 Movie를 프로퍼티로 가지는 것은 Screening이 Movie에 대한 강한 의존성을 가짐을 의미합니다.
설계 트레이드오프
프로토콜(인터페이스) 활용: Swift에서 제안하신 것처럼 프로토콜을 사용하여 의존성을 역전시키는 방법은 좋은 해결책이 될 수 있습니다. 이 방법을 통해 서로의 구체적인 구현을 알지 않고도 요구되는 동작을 수행할 수 있습니다.
복잡성 증가: 그러나 이러한 설계 변경은 코드의 복잡성을 증가시키고, 다른 문제 해결을 위한 클래스를 추가해야 할 수 있습니다. 이는 코드의 일관성을 탈락시키고, 향후 변경이 필요할 때 더 많은 수정을 요구할 수 있습니다.
같은 계층 내에서의 의존성 허용: 일반적으로, 객체들이 동일한 계층이나 모듈 내에서 꽉 결합되면 실질적인 문제를 야기하지 않는다고 보고 의존성을 허용하기도 합니다. 그러나 이는 시스템의 크기, 유지보수 팀의 규모, 해당 의존성이 주는 이점과 문제를 분석한 후 결정되어야 합니다.
해결 방법
감안할 때, 의존성을 풀기 위한 다양한 방법이 존재할 수 있으며, 프로젝트의 특성, 팀의 문화, 코딩 스타일에 따라 맞춰 적용될 수 있습니다. 이러한 트레이드오프를 잘 판단하여 적절한 방법을 선택하시길 바랍니다.
관련해서 더욱 자세한 논의는 영화 예매 예제에서 결합도 문의드립니다에 대한 기존의 논의를 참고하시면 도움이 될 수 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해 드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.