전략 패턴....
전략 패턴을 사용하는 가장 큰 이유는 알고리즘의 캡슐화가 아닐까 생각해보면서 정리 시작하자.
전략 패턴
예제 소스
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 | public interface Strategy { public int doOperation(int num1, int num2); } public class OperationAdd implements Strategy{ @Override public int doOperation(int num1, int num2) { return num1 + num2; } } public class OperationSubstract implements Strategy{ @Override public int doOperation(int num1, int num2) { return num1 - num2; } } public class OperationMultiply implements Strategy{ @Override public int doOperation(int num1, int num2) { return num1 * num2; } } public class Context { private Strategy strategy; public Context(Strategy strategy){ this.strategy = strategy; } public int executeStrategy(int num1, int num2){ return strategy.doOperation(num1, num2); } } public class StrategyPatternDemo { public static void main(String[] args) { Context context = new Context(new OperationAdd()); System.out.println("10 + 5 = " + context.executeStrategy(10, 5)); context = new Context(new OperationSubstract()); System.out.println("10 - 5 = " + context.executeStrategy(10, 5)); context = new Context(new OperationMultiply()); System.out.println("10 * 5 = " + context.executeStrategy(10, 5)); } } |
이렇게 전략 패턴은 정해진 알고리즘는 세부 알고리즘이 변하더라도 인터페이스만
사용하면 현제 소스를 수정하지 않는 범위에서 새로운 알고리즘을 적용할 수 있다.
디자인 원칙 1
애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리시킨다.
즉, 코드에 새로운 요구사항이 있을 때마다 바뀌는 부분이 있다면, 그 행동을 바뀌지 않는 다른 부분으로부터 골라내서 분리해야 한다는 것을 알 수 있다.
"바뀌는 부분은 따로 뽑아서 캡슐화시킨다. 그렇게 하면 나중에 바뀌지 않는 부분에는 영향을 미치지 않은 채로 그 부분만 고치거나 확장할 수 있다."
이 개념은 매우 간단하지만 다른 모든 디자인 패턴의 기반을 이루는 원칙이다.
모든 패턴은 '시스템의 일부분을 다른 부분과 독립적으로 변화시킬 수 있는' 방법을 제공하기 위한 것이다.
디자인 원칙 2
구현이 아닌 인터페이스에 맞춰서 프로그래밍한다.
각 행동은 인터페이스로 표현하고 행동을 구현할 때 이런 인터페이스를 구현하도록 한다.
디자인 원칙 3
상속보다는 포함(맴버변수)를 활용한다.
포함을 이용하여 시스템을 만들면 유연성을 크게 향상시킬 수 있다. 단순히 알고리즘군을 별도의 클래스의 집합으로 캡슐화할 수 있도록 만들어주는 것 뿐 아니라, 포함으로 사용하는 객체에서 올바른 행동 인터페이스를 구현하기만 하면 실행시에 행동을 바꿀 수도 있게 해 준다.
클래스 다이어 그램램
전략 패턴 정의 : 알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다. 전략을 활용하면 알고리즘을 사용하는 크라이언트와 독립적으로 알고리즘을 변경할 수 있다.
'디자인패턴' 카테고리의 다른 글
상태 패턴(State Pattern) 소개 (0) | 2024.10.17 |
---|---|
상태 패턴의 응용 사례(State Pattern) (0) | 2024.10.17 |
AOP와 DI 구분 (0) | 2024.09.24 |
퍼사드 패턴(Facade Pattern) (0) | 2014.06.25 |
Adapter Pattern(어답터 패턴) (0) | 2014.06.24 |