인프런 커뮤니티 질문&답변
작성한 질문수
6-1. 변경과 설계 마지막 추상화 관련 질문 입니다.
해결된 질문
작성
·
10
1
안녕하세요.
이번에 설계의 관점에서의 배움을 위해 강의를 듣고 있습니다.
실 생활(영화) 의 예시로 알려주셔서 이해하고, 생각해보는데 도움이 되고 있습니다.
6-1 강의 마지막에 추상화를 변경이 일어날 것을 미리 추측하여 만들지 말고 간단하게 하는 것이 좀더 나은것 같다고 이야기 해주셨는데요.
이부분에 대해서 현 영화의 예시로 본다면,
할인 정책이 만약 정액재 (금액 할인) 정책만 존재한다면
정책 인터페이스를 만들 필요 없이 금액 정책 클래스만 만들어 활용하는게 더 좋다는 의미로 이해했습니다.
이렇게 말씀해주신 이유를 생각해보았는데, 추상화를 활용해 message 만 일치한다면 다양한 방식의 정책을 동적으로 활용할 수 있다는 장점이 있습니다.
다만 코드의 동작 분석에 있어 실제 runtime 단계에서 어떤 구현체가 사용되는지 확인 해야 하는 어려움이 있기 때문에 위와 같이 말씀 에 동의할 수 있는거 같습니다.
만약, 변경이 일어날 것을 추측이 아닌 실제로 일어나게 된다면 최소 몇개의 변경이 있어야 ( Ex ) 정책이 3개 ) 추상화를 하는게 좋다는 강사님만의 기준이 있을까요??
답변 2
0
이상민님 안녕하세요.
좋은 질문 남겨 주셔서 감사합니다.
언제 추상화를 도입할 것인가에 대한 절대적인 법칙이 없다보니 이 질문에 대해 명확하게 몇번이라고 말씀 드리는게 꽤나 조심스러운데요
어떤 부분이 지속적으로 변경될 것이라는 확신이 없다면 추상화를 최대한 늦게 도입하는게 좋다는 부분에 대해 동의한다고 말씀하셨으니 조금은 부담없이 제 기준을 말씀드려 볼게요. 🙂
일반적으로 프로그래밍에서 반복적으로 발생하는 문제에 대한 기본적인 가이드는 “3의 규칙(Rule of three)”을 따르는 것입니다.
만약 유사한 역할, 책임, 협력이 세번 발생한다면 이를 공통의 디자인 패턴으로 만들 것을 고려합니다.
만약 서로 다른 도메인에 적용할 수 있는 코드가 있다면 프레임워크로 만들 것을 고려합니다.
만약 세번째로 유사한 코드를 중복시키고 있다면 중복을 제거해서 새로운 추상화를 만듭니다.
하지만 앞에서 말씀드린 것처럼 설계에는 절대적인 법칙이 없기때문에 이 규칙을 맹목적으로 따를 필요는 없고 상황에 따라 유연하게 결정하시면 됩니다.
만약 어떤 코드가 한 두달 사이에 연속적으로 변경되고 있고 사업적으로도 당분간 해당 부분에 대해 다양한 방식을 시도해 보려는 방향성이 잡혀 있다면 두번째 변경이라고 하더라도 추상화를 도입하는게 유리한 경우가 있습니다.
어차피 변경이 일어난다면 최대한 빨리 추상화를 도입해서 불필요한 중복 코드가 늘어나는 것을 방지하는게 유리하기 때문입니다.
반대로 어떤 부분이 몇년에 한번 발생한다면 세번째라고 하더라도 추상화를 추가하지 않을 때도 있습니다.
이 경우에는 세번째로 수정했다고 해서 네번째 변경이 반드시 일어난다고 확신하기가 어렵고 해당 로직을 리팩터링하고 테스트한 후에 재배포하는 우선순위가 그렇게 높지 않은 경우입니다.
하지만 자주 변경되지 않지만 여러 코드에서 사용되기 때문에 코드를 자주 읽어야 한다면 추상화를 도입해서 의미를 명확하게 만드는게 좋은 경우도 있습니다.
결론적으로 추상화를 도입할 때의 영향과 비용을 판단하는게 중요합니다.
코드를 리팩터링하는게 문제가 아니라 기존 코드를 다시 테스트하고, QA를 통과하는 비용이 상대적으로 클 때가 있기 때문입니다.
3의 규칙은 가이드일 뿐이기 때문에 결국 변경이 발생할 때의 영향을 감수할만한 지, 변경이 자주 일어나는지, 의미를 명확하게 하는데 리소스를 쓸 필요가 있는지에 따라 추상화를 도입하는 시점은 달라지게 됩니다.
개인적으로 추상화를 추가하는 비용 대비 이익을 확신하기 애매하다면 그 부분은 중요하지 않은 부분일 것이기 때문에 우선 순위가 높은 작업이 있다면 일단 두는 편입니다.
답변이 되었는지 모르겠네요.
감사합니다. 😊
0
안녕하세요, 인프런 AI 인턴입니다.
이상민님께서 제기하신 질문은 객체 지향 설계에서 추상화를 언제 도입해야 하는지에 대한 매우 중요한 고민입니다. 이는 개발자들이 흔히 맞닥뜨리는 문제로, 추상화는 코드의 유연성과 확장성을 확보하는 데 중요한 역할을 하지만, 이는 불필요한 복잡성을 추가할 수도 있습니다.
강사의 설명 요약
조영호 강사님께서는 추상화를 통해 코드의 유연성을 높이는 것에 대해 항상 긍정적이지만, 불필요한 추상화는 오히려 복잡성을 증가시킬 수 있음을 강조합니다. 6-1. 변경과 설계 강의에서는 추상화를 도입하는 시점을 명확히 하기 위해 현재 알고 있는 요구 사항에 집중할 것을 강조하며, 장기적인 변화까지 너무 앞서 고려하는 방식은 피할 것을 권장하고 있습니다.
최소 몇 개의 정책이 존재해야 하는가
추상화를 도입하기 위한 구체적인 수치는 사실 프로젝트의 성격이나 팀의 설계 원칙에 따라 다를 수 있습니다. 그러나 일반적으로 다음과 같은 원칙을 고려할 수 있습니다:
현재 요구사항을 충족하는가: 현재 당면한 문제를 해결하기에 충분히 유연한 구조가 아닌지 확인합니다.
변화의 가능성: 미래의 변화가 예측되거나 이미 변경의 징후가 여러 차례 있었다면, 추상화 고려. 예를 들어, 이미 여러 할인 정책이 제안되거나 사용되고 있다면(3개 이상), 인터페이스 도입을 고려할 수 있습니다.
개발의 직관성: 팀 내 대부분의 개발자가 불필요한 복잡성을 줄이고 향후 변경에 쉽게 대응할 수 있는지를 평가해야 합니다.
추상화 도입의 적정 시점은 정해진 수치보다 요구된 기능의 변화 빈도와 복잡성을 고려하는 것이 중요합니다. 많은 개발자들이 최소 2~3개의 유사한 기능별 요구가 있을 때 인터페이스와 같은 추상화를 고려하기 시작합니다.
추상화와 관련된 유사한 질문은 이 링크에서 확인할 수 있습니다. 영화 예제를 관통하여 다양한 상황에 대한 설계를 다루고 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해 드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.