Topic 31 상속세
데이비드 토머스, 앤드류 헌트
느낌표 ! (인상 깊은 문장 | 문맥)
객체 지향 언어로 프로그래밍하는가? 상속을 사용하는가? 그렇다면 멈춰라! 아마 여러분에게 필요한 것은 상속이 아닐 것이다.
p.224
요즘 상속에 관해서 더 공부하고 있는데 흠칫한 대목이다.
상속도 일종의 결합이다.
p.226
상속을 사용하면 코드를 더 간단하게 짤 수 있을 것 같은데 분명한 것은 우선 부모-자식의 결합이 발생한다는 것이다. 마냥 상속이 좋은 코드를 만들어주지 않는다는 것이다.
더는 상속을 쓸 필요가 없게 해 주는 세 가지 기법을 소개하겠다.
- 인터페이스와 프로토콜
- 위임
- 믹스인과 트레이트
p.229
인터페이스와 프로토콜
다형성은 인터페이스로 표현하는 것이 좋다.
p.230
대체로 직접적으로 부모 클래스를 상속 받기보다는 인터페이스로 연결이 되는 것이 decoupling 에 좋은 것 같다.
인터페이스와 프로토콜은 상속 없이도 다형성을 가져다준다.
p.231
꽤 많은 경우 인터페이스가 상속을 대체할 수 있겠다는 생각이 들기도 한다.
위임
상속은 개발자들이 점점 더 메서드가 많은 클래스를 만들도록 유도한다.
p.231
필요없는 메소드가 있는데 이를 다 사용해야하거나 다 사용하지 못하도록 처리를 해줘야하는 상속의 단점 또한 분명하다.
서비스에 위임하라. Has-A 가 Is-A보다 낫다.
p.232
위임으로 다 가지려고 하지 말고 가리키는 것이(Is-A) 낫다고 설명하고 있다.
믹스인, 트세이트, 카테고리, 프로토콜 확장 등
예를 들어 계정이라면 아마 검증을 적용할 수 있는 여러 가지 서로 다른 계층이 있을 것이다.
- 일방향 암호화한 비밀번호가 사용자가 입력한 것과 일치하는지 검증하기
- 계정을 생성할 때 사용자가 입력한 정보 검증하기
- 관리자가 사용자 상세 정보를 변경할 때 입력한 정보 검증하기
- 다른 시스템 커포넌트가 계정에 추가한 정보 검증하기
- 데이터베이스에 저장하기 전에 데이터 일관성 검증하기
흔히 쓰이는 접근 방식은 하나의 클래스에-비즈니스 객체 혹은 영속성 객체의 클래스에-모든 검증을 다 가져다 붙인 후, 상황별로 플래그를 추가해서 적용할 검증 사항을 관리하는 것이다. 별로 이상적이지는 않다. 우리는 믹스인을 사용하여 각 상황에 맞는 전문화된 클래스를 만드는 것이 더 낫다고 생각한다.
class AccountForCustomer extends Account with AccountValidations, AccountCustomerValidations class AccountForAdmin extends Account with AccountValidations, AccountAdminValidationsp.234
필요한 기능만 묶어 사용하는 믹스인을 사용하는 것도 상속을 대체하는 방법 중 하나로 소개하고 있다. 위 소개처럼 검증 로직이 있다면 플래그를 통해 로직을 다르게 사용하기보다는 믹스인을 통해 사용하는 것이 더욱 우아해보인다.
상속이 답인 경우는 드물다
여러분의 상황에 따라 더 나은 방법이 있을 것이다. 타입 정보를 공유하고 싶은 건지, 기능을 더하고 싶은 건지, 메서드를 공유하고 싶은 건지에 따라 다르다. 프로그래밍의 다른 모든 것과 마찬가지로 여러분의 목표를 의도를 가장 잘 드러내는 기법을 사용하는 것이어야 한다. 그리고 정글 전체를 끌어들이지 않도록 조심하라.
p.235
상속이 정말 필요한 경우도 분명 존재하지만 모든 것에 상속을 사용하는 것은 남용으로 오히려 변경 용이성이 떨어질 가능성이 농후하다. 상속을 필요할 때 쓰는 것이 중요하곘다.
Topic 31 느낌
Topic 31 에서는 상속을 잘 사용하도록 또 한 번 더 상속이 정답인지 고민하도록 여러 측면에서 설명하고 있다.