참고

• is-a보다 has-a가 좋을수 있다
• 상속 보다는 구성을 활용한다 의도
• 동일 계열 알고리즘군을 정의하고 각각을 캡슐화하여 상호 교환해서 사용할 수 있도록 합니다
• 알고리즘을 사용하는 클라이언트와 상관없이 독립적으로 알고리즘을 변경할 수 있게 합니다 동기
• 알고리즘 코드가 분리가 되어있지 않다면 클래스가 복잡해진다
• 때에 따라서 알고리즘이 다르기 때문에 변경이 어렵다
• 새로운 알고리즘을 추가하거나 기존의 것을 다양화하기가 어렵다
• 이런 캡슐화된 알고리즘을 전략이라고 합니다 활용성
• 많은 행동중 하나를 가진 클래스를 구성할 수 있는 방법을 제공합니다
• 알고리즘의 변형이 필요할때 변경할수 있습니다
• 사용자가 몰라야 하는 알고리즘이 있을때 전략 클래스에만 두면 되므로 사용자가 몰라도 됩니다
• 하나의 클래스가 많은 행동을 정의하고, 이런 행동이 다중 조건문의 모습을 취할때 각각을 전략 클래스로 옭겨놓는 것이 좋습니다 참여자
• 스트레티지(컴포지터): 알고리즘 인터페이스
• 컨크리트 스트레티지: 실제 알고리즘
• 컨택스트(컴포지션): 전락에 대한 참조자 관리, 스트레티지의 서브클래스 인스턴스를 갖고 있음으로 구체화합니다 결과
• 동일 계열의 관련 알고리즘군이 생깁니다, 재사용도 가능합니다
• 서브클래싱을 사용하지 않는 대안입니다, 알고리즘을 변형, 이해, 확장이 쉽습니다
• 조건문을 없앨 수 있습니다
• 구현의 선택이 가능합니다, 전략중 하나를 선택하여 사용합니다
• 사용자(프로그램)는 서로 다른 전략을 알아야 합니다
• 전략 객체와 컴포지션 객체 사이에 의사소통 오버헤드가 있습니다, 사용되지 않는 매개변수를 컴포지션이 떠안아야합니다
• 객체 수가 증가합니다, 플라이웨이트를 사용하면 좋습니다