12장. 상속과 코드 재사용: 객체지향의 마법 같은 도구

상속과 코드 재사용: 객체지향의 마법 같은 도구

반복되는 코드, 이제 그만! 상속을 제대로 이해하면 코드 재사용은 물론 유지보수까지 훨씬 쉬워집니다.

안녕하세요, 개발자 여러분! 오늘은 객체지향 프로그래밍에서 가장 흥미롭고도 논쟁이 많은 주제 중 하나인 '상속'에 대해 이야기해보려고 해요. 저도 처음에는 상속이 마치 편법처럼 느껴지기도 했습니다. 그냥 코드를 복붙하지 않고 위 클래스를 참조한다는 게... 뭐랄까, 약간 뭔가 감이 안 잡히는 그런 느낌이랄까요? 그런데 실제로 팀 프로젝트를 진행하면서 상속의 진가를 느끼게 됐습니다. 중복된 코드를 줄이고, 기능을 확장하고, 유지보수성을 높이는 데 상속만큼 강력한 무기가 없더라고요. 그래서 오늘은 이 '상속'을 어떻게 잘 활용해서 '코드 재사용'이라는 고급 기술까지 이어질 수 있는지, 그 방법을 공유해보려 합니다. 바로 시작할게요!

목차

상속의 기본 개념 상속을 적용해야 할 시점 상속을 활용한 코드 재사용 상속 vs 컴포지션: 언제 무엇을? 상속의 함정과 안티패턴 상속 코드의 리팩토링 전략

상속의 기본 개념

상속(inheritance)은 객체지향 프로그래밍의 꽃이라고 불립니다. 기본 클래스(부모 클래스)의 속성과 메서드를 하위 클래스(자식 클래스)에게 물려주는 기능이죠. 이걸 잘 활용하면 반복되는 코드를 줄이고, 공통 기능을 한 곳에서 관리할 수 있어서 유지보수도 쉬워집니다. 예를 들어, 'Animal'이라는 클래스를 만든 후 'Dog', 'Cat', 'Bird'가 이 클래스를 상속받는 구조를 생각해볼 수 있죠. 상속의 핵심은 재사용과 확장성이에요. 기존 기능을 그대로 활용하면서 필요한 부분만 오버라이딩(override)해서 새로운 기능을 추가하거나 기존 기능을 변경할 수 있거든요. 물론 '무분별한 상속'은 코드를 복잡하게 만들 수 있어서 주의가 필요해요.

상속을 적용해야 할 시점

모든 경우에 상속을 쓰는 건 절대 금물이에요. 상속은 ‘is-a 관계’가 분명할 때만 사용하는 게 좋아요. 그렇다면 언제 상속이 진가를 발휘할까요? 아래 표를 참고해 보세요.

상황	상속 사용 여부
공통 기능이 여러 클래스에서 반복될 경우	✅ 상속 사용 권장
자식 클래스가 부모 클래스의 의미를 완전히 포함할 경우	✅ 상속 적합
단지 기능을 재사용하려는 목적만 있는 경우	❌ 컴포지션 권장

상속을 활용한 코드 재사용

상속을 제대로 활용하면 코드 재사용이 극대화됩니다. 제가 예전에 만든 게임 프로젝트에서는 'Character'라는 상위 클래스에 이동, 공격 등의 공통 기능을 넣고, 각각 'Knight', 'Wizard', 'Archer' 클래스에서 특화된 기능만 추가했어요. 그 결과, 버그 수정이 필요한 경우에도 상위 클래스만 고치면 되니까 정말 편하더라고요. 상속을 활용한 코드 재사용의 장점을 정리하면 다음과 같아요.

• 중복 코드 제거로 개발 시간 단축
• 유지보수 효율성 향상 (한 곳만 수정해도 전체 반영)
• 일관된 기능 구현으로 품질 향상

상속 vs 컴포지션: 언제 무엇을?

객체지향 설계에서 가장 많이 나오는 토론 주제 중 하나가 바로 이거예요. 상속을 사용할까, 컴포지션을 사용할까? 상속은 구조적으로 코드가 간결해지고 빠르게 구현할 수 있다는 장점이 있지만, 너무 깊게 사용하면 코드가 꼬이기 시작하죠. 반면, 컴포지션은 유연성과 확장성이 좋아요. 제가 겪은 실무 사례 중 하나는 '로그 기록 기능'이었는데요, 이걸 상속으로 구현하려다 보니 각 클래스가 로그 클래스까지 상속받아야 해서 의존성이 너무 많아졌어요. 그래서 결국 컴포지션으로 바꿨고, 결과적으로 더 깔끔하고 테스트도 쉬워졌어요. 결론은? 'is-a' 관계면 상속, 'has-a' 관계면 컴포지션입니다. 이 원칙만 잘 지켜도 많은 문제가 해결돼요.

상속의 함정과 안티패턴

상속은 강력한 도구지만, 그만큼 잘못 사용했을 때 리스크도 커요. 대표적인 상속 안티패턴을 표로 정리해볼게요. 혹시 여러분도 이런 실수 하고 있진 않나요?

안티패턴	문제점
다중 상속	충돌 가능성과 의도 파악이 어려움
깊은 상속 구조	가독성과 유지보수성이 크게 떨어짐
부적절한 공통 클래스 생성	실제로는 연관이 없는 클래스들이 강제로 묶임

상속 코드의 리팩토링 전략

상속 구조가 복잡해지거나 불필요하게 얽혀 있으면, 반드시 리팩토링을 고려해야 합니다. 저는 보통 아래와 같은 전략을 사용해요.

• 공통 기능은 별도 유틸 클래스로 분리
• 상속보다 컴포지션 적용 가능성 검토
• 추상 클래스보단 인터페이스로 유연하게 구성

Q 상속과 인터페이스의 가장 큰 차이점은 무엇인가요?

상속은 구현을 물려주고, 인터페이스는 '무엇을 해야 하는지'를 명시합니다. 즉, 인터페이스는 계약에 가깝습니다.

Q 상속은 무조건 코드 재사용에 유리한가요?

아니요. 상황에 따라 컴포지션이 더 나은 선택일 수 있어요. 유연성과 유지보수성을 고려해야 합니다.

Q 부모 클래스의 메서드는 꼭 오버라이딩해야 하나요?

그럴 필요는 없습니다. 필요할 경우에만 오버라이딩하면 됩니다.

Q 다중 상속은 왜 피해야 하나요?

여러 부모로부터 상속받다 보면 메서드 충돌이나 구조의 혼란이 생기기 쉽기 때문입니다.

Q 상속 없이도 코드 재사용이 가능한가요?

물론입니다. 컴포지션, 위임, 유틸 클래스 등의 방식으로도 충분히 코드 재사용이 가능합니다.

Q 상속을 하면 캡슐화가 깨지지 않나요?

그럴 가능성도 있습니다. protected 접근 제어자를 적절히 사용하고 상속 구조를 단순하게 유지하는 것이 중요합니다.

상속과 코드 재사용에 대해 이렇게 깊이 들여다보니, 처음엔 당연하게 여겼던 개념들도 새롭게 보이지 않으세요? 저도 글을 쓰면서 다시 한 번 기본기를 돌아보게 되었답니다. 상속은 강력한 도구이지만, 적절하게 써야 그 힘을 발휘합니다. 컴포지션과의 균형, 그리고 올바른 리팩토링 전략까지 고민한다면 여러분의 코드도 한층 더 정교해질 거예요. 혹시 여러분만의 상속 활용 팁이 있다면 댓글로 공유해 주세요. 우리 같이 더 좋은 코드를 만들어봐요! 💜

객체지향, 상속, 코드 재사용, 컴포지션, 리팩토링, 인터페이스, 자바, 클래스 설계, 오버라이딩, 디자인 패턴