Introduction

Design Principles

1. Program to an interface, not an implementation ( 구현이 아니라 interface를 프로그램하라! )

이 디자인 원리는 구현 의존성을 굉장히 줄여준다.
Clients는 interface를 참고하고 구현과는 독립적이다. 이것은 구현은 변화 없이 존재하는 clients마다 독립적으로 다양 할 수 있다는 것을 의미한다. 이것은 여기에서 다루는 일반적인 디자인 패턴의 주제이고 한 시스템이 구현의 관점이 아닌 interface의 관점으로 쓰여진다는 것을 보장한다.
결론적으로 clients는 interface에 의존한다. interface를 다양하게 하는 것은 존재하는 clients를 없앨 수 있다. 그러므로 interface는 신중하게 디자인되어야만 한다.

Figure 1

Figure 1은 전략 디자인 패턴의 예를 보여준다.
Context는 strategy interface를 참조하고 구현과는 독립적이다. 이 구현은 context에 따라 독립적으로 다양해 질 수 있다. 새로운 algorithm이 추가되거나 존재하는 것들을 바꿀 수 있다.

2. Cleanly separate interface ans implementation. ( interface와 구현부를 명백하게 구분하라! )

interface를 디자인 할 때 2가지 상황 중 하나에 놓이게 된다.
(1) internal interface
public할 수 없는 interface를 디자인하는 것이다. 오직 내부적으로만 사용되고 이것의 clients는 통제하에 있다. 내부 interface를 다양하게 하는 것은 존재하는 clients를 바꿀 수 있는 가능성이 있다.
(2) Published interface
public하는 interface를 디자인 하는 것이다.
광범위하게 사용되고 통제하에 있지 않다. interface를 publish할 때 이것을 영원히 지원해야만 한다. published interface를 다양하게 하는 것은 존재하는 clients를 없앨 수 있기 때문헤 항상 불가능 하다. 그래서 interface를 public하는 것은 큰 투자가 필요하다.

Figure 2

Figure 2는 interface디자인의 한 예를 보여준다.
interface(Custom)그리고 구현(Custom1)은 명백하게 구분되어진다.

3. Favor object composition over class inheritance ( 클래스 상속을 통해 객체 결합을 활성화 하라! )

컴파일 시간에 동적으로 행동을 변화시키는 클래스 상속을 사용하라! 클래스 상속은 부모클래스와 서브클래스 사이의 단 한개("is a")의 관계라면 클래스 상속을 사용하라! 어떤 종류의 클래스화를 표혀현하기 원하는 언제든지 어떤 것은 특별화도어지고 어떤 종류는 더 일반화되어질 것이다.
예를 들면, rose는 flower과 단 한개("is a")관계이다. dog도 마찬가지도 aminal과 단 한개("is a")관계이다. 잘 디자인된 "is a"상속의 결과는 클래스들로부터 상속한다. 부모 클래스는 일반적인 행위(behavior)를 구현하고 서브클래스들은 부모클래스로부터 상속하고 특별한 행동을 구현한다.
런타임에 동적으로 행동(behavior)를 변화시키기위해 객체 결합을 사용해라.
객체 결합으로 객체들의 셋을 결합하여 행동들을 런타임 시간에 동적으로 변화시키거나 수행시킬수 있다. 객체 결합은 interface들과 통하여 유일하게 결합할 수 있도록 잘 디자인되어야 할 필요가 있다.

Figure 3

Figure 3는 전략 디자인 패턴을 한 예를 보여준다.
클새스 상속을 통하여 알고리즘을 변화시키는 것 대신에 context는 다른 전략 객체들을 알고리즘에 위임한다.