패턴 관련 코드는 아래 링크를 통해 확인 가능합니다.
sample source code

상속만 사용했을 경우의 단점

상속을 사용하면 코드를 재사용할 수 있지만, 실제 코드를 정비를 하는 데에는 어려움이 있을 수 있습니다.
예를 들어, 자식 클래스에서 부모 클래스와 다른 방식으로 method 로직을 수행해야 한다면 상속을 굳이 사용할 필요가 있을까요? code reference

소프트웨어를 만들 때, 나중에 혹시 고쳐야 할 때도 기존 코드에 미치는 영향은 최소한으로 만들면서 작업할 수 있도록 설계를 해야합니다. 그래서 상속을 사용할 때와 인터페이스를 사용할 때를 적절하게 구분할 수 있어야 합니다.

Design Principal 1.
애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리시킨다.

달라지지 않는 부분을 찾아서 나머지 코드에 영향을 주지 않도록 "캡슐화" 합니다. 그러면 코드를 변경하는 과정에서 의도하지 않은 일이 일어나는 것을 줄이면서 시스템의 유연성은 향상시킬 수 있습니다.

상속과 구성 디자인

Design Principal 2.
구현이 아닌 인터페이스에 맞춰서 프로그래밍한다.

1. 바뀌는 부분과 그렇지 않은 부분 분리하기

   • 바뀌는 부분은 인터페이스로 클래스를 분리합니다.
   • 바뀌지 않는 부분은 상속을 사용합니다.

   → 특정 행동을 인터페이스로 분리하였기 때문에 상속하는 클래스에서는 더 이상 이 행동을 구현하는 방법을 고려하지 않아도 됩니다.

2. 바뀌는 부분은 setter 메소드를 포함시켜 프로그램 실행 중에 동적으로 행동을 바꿀 수 있으면 좋을 것 입니다.

상속과 구성 예제

1. 바뀌는 행동과 바뀌지 않는 행동을 구분하여 바뀌는 부분은 인터페이스로 분리하였습니다.
   • 이로써 다른 형식의 객체에서도 Duck을 건드리지 않고 나는 행동(FlyBehavior) 꽥꽥 거리는 행동 (QuackBehavior)을 재사용할 수 있습니다.
   • 가장 중요한 점은 행동을 Duck 클래스에서 정의한 메소드를 써서 구현하지 않고 다른 클래스에 위임한다는 것입니다.
2. 실행 중에 행동을 바꾸고 싶으면 setter 메소드를 통하여 행동을 동적으로 변경합니다.

상속보다 구성

"A는 B이다" 보다 "A에는 B가 있다"가 나을 수 있습니다.

두 클래스를 예제처럼 합치는 것을 구성(Composition)을 이용하는 것이라고 부릅니다.

Disign Principal 3.
상속보다는 구성을 활용한다.

Strategy Pattern에서는 알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만듭니다. 이 패턴을 활용하면 알고리즘을 사용하는 클라이언트와는 독립정으로 알고리즘을 변경할 수 있습니다.