Early Return vs. 객체지향 설계: 클린 코드의 함정과 진정한 SOLID 원칙

핵심 기술

본 콘텐츠는 클린 코드의 일반적인 기법인 Early Return이 모든 상황에 최적은 아니며, 특히 객체지향 설계와 비즈니스 로직이 복잡하게 얽힐 때 오히려 코드의 가독성과 유지보수성을 해칠 수 있음을 객체지향 설계 원칙에 기반하여 설명합니다.

기술적 세부사항

• Early Return의 오용 사례: 할인 정책이 없는 경우 total을 바로 반환하는 Early Return 코드가 비즈니스 로직(할인 정책 부재)을 getTotal 메서드 내부에 분기시켜 장바구니 클래스의 책임을 모호하게 만드는 문제점을 지적합니다.
• 객체지향 설계 원칙 적용: 할인 정책이 없을 수 있다는 조건 자체가 비즈니스 로직의 일부이며, 이를 null 체크로 처리하는 것은 협력 객체(할인 정책)의 존재 여부까지 책임지는 것으로, 단일 책임 원칙(SRP) 위반임을 설명합니다.
• 변경에 취약한 코드: 새로운 할인 정책(예: X마트 특별세일) 추가 시 기존 if 문의 조건이 복잡해지고, 도메인 정책이 클래스 내부에 하드코딩되는 문제점을 예시로 보여줍니다.
• 개선된 객체지향적 접근: 할인 정책 인터페이스와 이를 구현하는 구체적인 클래스(퍼센트 할인, 천원 할인, 할인 없음)를 분리하고, getDiscountPolicy 함수를 통해 정책 선택 로직을 별도화하여 장바구니 클래스의 getTotal 메서드는 순수하게 총액 계산 역할만 하도록 변경하는 과정을 제시합니다.
• 다형성 활용: 다양한 할인 정책을 할인정책 인터페이스를 통해 추상화하고, 각 구현 클래스가 calculateDiscount 메서드를 오버라이딩하여 다형성을 활용하는 방법을 보여줍니다.
• 책임 분리: 각 할인 정책의 계산은 해당 클래스가, 정책 선택은 별도의 함수가, 총합 계산은 장바구니 클래스가 담당하도록 책임을 명확히 분리하여 개방-폐쇄 원칙(OCP)을 준수하는 구조를 제시합니다.
• Early Return의 올바른 적용: 할인 정책 클래스 내부에서 null이 아닌 유효하지 않은 할인 타입에 대한 예외 처리에 Early Return을 사용하는 것이 더 적합함을 보여줍니다.

개발 임팩트

• 유지보수성 향상: 비즈니스 로직 변경 시 관련 클래스만 수정하거나 새로운 정책 클래스를 추가하여 기존 코드에 미치는 영향을 최소화할 수 있습니다.
• 확장성 증대: 새로운 할인 정책 추가가 용이하며, 객체지향 설계 원칙을 준수하여 코드의 견고성과 유연성을 높입니다.
• 테스트 용이성: 각 할인 정책 클래스가 독립적으로 테스트 가능해져 단위 테스트 작성이 쉬워집니다.
• 코드 가독성 및 명확성: 각 컴포넌트의 역할과 책임이 명확해져 코드 이해도가 높아집니다.

커뮤니티 반응

콘텐츠는 직접적인 커뮤니티 반응을 언급하지 않지만, 'Senior Engineer'의 피드백을 인용하며 실제 개발 현장에서 이러한 코드 리뷰가 이루어짐을 시사합니다. 이는 실무 개발자들이 겪을 수 있는 코드 품질 이슈와 개선 방안에 대한 공감대를 형성합니다.