[헤드퍼스트 디자인패턴](1) 전략패턴

 

소프트웨어를 고칠 때 기존 코드에 미치는 영향을 최소한으로 줄이면서 작업할 수 있는 방법이 있다면 정말 행복하지 않을까요?

 

디자인 원칙

애플리케이션에서 달라지는 부분을 찾아내고 달라지지 않는 부분과 분리한다

 

바뀌는 부분은 따로 뽑아서 캡슐화 한다. 그러면 나중에 바뀌지 않는 부분에는 영향을 미치지 않고 그 부분만 고치거나 확장할 수 있다.

 

디자인 원칙

구현보다는 인터페이스에 맞춰서 프로그래밍한다

 

핵심은 실제 실행 시에 쓰이는 객체가 코드에 고정되지 않도록 상위 형식 (supertype)에 맞춰 프로그래밍 해서 다형성을 활용해야 한다는 점에 있습니다.

 

인터페이스 다형성 캡슐화 로 만들면 프로그램이 변화에 되게 유연해 진다.

 

이런 식으로 두 클래스를 합치는 것을 구성(composition)을 이용한다. 라고 부릅니다.

 

 

디자인 원칙

상속보다는 구성을 활용한다

 

구성을 활용해서 시스템을 만들면 유연성을 크게 향상시킬 수 있습니다.

• 단순한 알고리즘군을 별도의 클래스 집합으로 캡슐화 할 수 있습니다.
• 구성 요소로 사용하는 객체에서 올바른 행동 인터페이스를 구현하기만 하면 실행 시에 행동을 바꿀 수도 있습니다.
• 구성은 여러 디자인 패턴에서 쓰이며, 이 책 전반에 걸쳐서 구성의 장단점을 배웁니다.

 

---

 

첫 번째 디자인 패턴: 전략패턴

 

알고리즘군을 정의하고 캡슐화해서 각각의 알고리즘군을 수정해서 쓸 수 있게 해줍니다.

전략패턴을 사용하면 클라이언트로부터 알고리즘을 분리해서 독립적으로 변경할 수 있습니다.

 

FlyBehavior 와 QuackBehavior 로 분리해서 독립적으로 변경할 수 있게 한다.

- 애플리케이션에서 달라지는 부분을 찾아내고 달라지지 않는 부분과 분리한다
- 구현보다는 인터페이스에 맞춰서 프로그래밍한다
- 상속보다는 구성을 활용한다

 

---

 

기존에 Service 인터페이스를 만들고, ServiceImpl 이라는 구현 클래스를 만들어서 따로 구현하는 방식의 개발방식을 무분별하게(이해하지 못한 상태에서) 따라서 사용하고는 했다.

 

사실상 이렇게 구현하는 이유는 Service에 추가사항이 생겼을 때 기존의 코드에 영향을 주지 않은채 추가하기 위하였다는 것을 알게 되었다.

 

물론 실제 SI 개발 환경에서는 무분별하게 인터페이스와 Impl로 덮혀있고 그 관계가 1:1 일 때가 99% 인거 같긴하다.

 

이 패턴을 활용하여 실제로 개발할 때, 데이터 인터페이스를 만들고, 각각의 압축된 데이터와 압축되지 않은 데이터 클래스를 구현하여, 데이터가 압축되었는지 여부에 상관없이 동일한 프로세스를 거칠 수 있게 구현할 수 있었다.