상속과 코드 재사용

• 재사용 관점에서 상속은 클래스 안에 정의된 인스턴스 변수와 메소드를 자동으로 새로운 클래스에 추가하는 구현 기법이다.
• 혹은 ‘합성’으로 기존 클래스의 인스턴스를 포함시키는 방법이 있다.

상속/ 중복 코드

DRY(Don’t Repeat Yourself) 원칙

• 중복은 변경을 방해한다. 하나의 수정을 여러 번 해야 한다는 것이다.
• 변경 시 코드를 함께 변경해야 한다면 중복이라고 볼 수 있다.
• DRY는 Once and Only Once, Single-Point Control 원칙이라고 한다.

중복 제거

• 객체 지향 프로그래밍 언어는 중복코드를 효과적으로 관리할 수 있는 방법이 있다.

  상속을 이용해서 중복 코드 제거

  • 상속을 이용해서 코드를 재사용 하는 방법이 있다.
  • 물론 상속을 염두하고 설계되지 않은 클래스를 상속해서 사용하는 것은 꽤 까다롭다.
  • 상속을 이용해서 코드를 재사용하기 위해서는 부모 클래스의 개발자가 세웠던 가정이나 추론 과정을 정확하게 이해해야 한다.
  • 그러나 상속 관계로 연결된 자식 클래스가 부모 클래스의 변경에 취약해지는 현상을 취약한 기반 클래스 문제라고 부른다.
  • 취약한 기반 클래스(Fragile Base Class Problem, Brittle Base Class Problem) 문제는 부모 클래스의 작은 변경에 자식은 컴파일 오류와 실행 에러 등의 큰 사이드 이펙트가 발생한다는 것이다.
  • 이는 상속이라는 문맥 안에서 결합도가 초래하는 문제점을 가리키는 문제다.
  • 취약한 기반 클래스 문제는 캡슐화를 약화시키고 결합도를 높인다.
  • 상속은 자식클래스가 부모의 구현 세부 사항에 의존하도록 만들기 때문에 캡슐화를 약화시킨다.
  • 이러한 부분은 상속을 가벼이 생각하면 안되는 부분이다.
  • 객체를 사용하는 이유는 구현과 관련된 세부사항을 퍼블릭 인터페이스 뒤로 캡슐화할 수 있기 때문이다.
  • 캡슐화는 변경에 의한 파급 효과를 제어할 수 있기 때문이다. 그러나 상속을 사용하면 이런 강력함을 반감시킨다.
  • 상속을 원한다면 클래스를 설계화하고 문서화해야 하며, 그렇지 않은 경우를 상속을 금지해야 한다.

    1.2. 불필요한 인터페이스를 상속하는 문제가 있다.

    • 상속을 하면 부모가 구현한 인터페이스를 자식이 필요하지 않아도 구현하게 된다.
    • 이는 단순히 코드 재사용 목적으로 불필요한 오퍼레이션을 구현하도록 강요하는 것이다.

    1.3. 메소드 오버라이딩 문제

    • 부모의 메소드를 그대로 사용할 수 없는 상황에서도 메소드 오버라이딩을 강요 받을 수 있다.

    1.4. 부모 자식 동시 수정 문제

    • 만약 부모에서 구현한 메소드를 자식에서 사용한다고 했을 때, 부모의 기능을 수정하면 자동적으로 자식의 메소드 구현도 변경된다.
    • 이는 불필요한 인터페이스 상속, 메소드 오버라이딩이 아니더라도 부모 클래스의 수정에 대한 파급효과에 자식이 자유롭지 않다는 것을 의미한다.

  1.2. 추상화에 의존

  • 부모 자식이 모두 추상화에 의존하면 결합도를 낮출 수 있다.
  • 추가적으로 코드 중복을 위해서 상속할 때 도입할 원칙이 두 가지가 있다.
    1. 두 메소드가 유사하게 보이면 차이점을 메소드로 추출하자.
    2. 부모 클래스의 코드를 하위로 내리지 않고 자식 클래스의 코드를 상위로 올린다.

  1.3. 차이를 메소드로 추출

  • 변하는 것으로부터 변하지 않는 것을 분리한다. 혹은 변하는 부분을 찾고 이를 캡슐화 한다.

차이에 의한 프로그래밍

• 기존 코드와 다른 부분만을 추가함으로써 애플리케이션 기능을 확장하는 방법을 차이에 의한 프로그래밍(programming by difference)
• 차치에 의한 프로그래밍의 목표는 중복 코드를 제거하고 코드를 재사용하는 것이다.