델파이 모드 프로그래밍의 전략 모드
리우 이
1.1 모드 설명
Strategy 패턴의 목적은 일련의 알고리즘을 정의하고 각 알고리즘을 공통 인터페이스가 있는 독립적인 클래스로 캡슐화하여 서로 교체할 수 있도록 하는 것입니다. 전략 패턴을 사용하면 이를 사용하는 클라이언트와 관계없이 알고리즘 변경이 가능합니다. 전략 패턴을 사용하는 동기와 중요성을 이해하려면 흥미로운 예부터 시작해야 합니다. 자재 관리 시스템에서 아웃바운드 및 인바운드 모듈은 시스템의 핵심 부분입니다(아래 분석을 위해 아웃바운드를 예로 들어 보겠습니다). 객체 지향 프로그래밍 경험이 없는 프로그래머의 경우 아웃바운드 주문의 모든 로직을 클라이언트(아웃렛 주문 인터페이스)에 배치하고 클라이언트에서 조건 분기 문을 사용하여 아웃바운드 주문 유형이 선택되는지 확인하는 경우가 많습니다. 그림 1-1과 같이 다양한 아웃바운드 결제 방법을 선택하기 위해 자재를 빌리거나 손실을 보고합니다. 결과적으로 클라이언트의 코드가 복잡해지고 유지 관리가 어려워집니다. 예를 들어 창고 외부에 새로운 이전 주문 유형을 추가해야 하는 경우 판단 조건을 수정하고 클라이언트를 다시 컴파일하고 게시해야 합니다. 상황이 복잡해질수록 조건부 분기도 많아지고, 프로그램 코드도 점점 더 많아지게 되며, 이로 인해 클라이언트가 커지고 유지 관리가 어려워지며, 상호 영향과 오류가 발생할 가능성도 높아집니다. . 그림 1-1 프로세스 지향적 사고를 바탕으로 설계된 아웃바운드 모듈을 객체지향적 사고로 분석하면 그림 1-과 같이 피킹 리스트, 차입 리스트, 손실 보고서가 아웃바운드 어음의 파생 클래스로 간주될 수 있다. 2 보여줍니다. 이러한 방식으로 아웃바운드 문서는 문서에 대한 공통 인터페이스를 제공하는 문서 기본 클래스 역할을 하며 상속은 하위 클래스에서 다양한 아웃바운드 동작을 구현하는 데 사용됩니다. 이는 실제로 객체 지향의 중요한 개념인 다형성을 활용합니다. 그러나 이 설계에는 환경과 동작이 밀접하게 결합되어 있다는 단점이 여전히 남아 있습니다. 즉, 문서와 특정 발신 알고리즘이 서로 밀접하게 결합되어 있습니다. 강한 결합은 두 가지가 독립적으로 발전하는 것을 방지하여 재사용성과 확장성을 제한합니다. 그림 1-3은 전략 패턴을 사용하여 재설계된 아웃바운드 모듈입니다. 아웃바운드 문서 객체는 아웃바운드 작업 객체(즉, 전략 모드의 Context)를 통해 아웃바운드 정책 객체를 참조한다. 다양한 특정 아웃바운드 전략은 아웃바운드 전략 클래스의 파생 클래스에 의해 구현됩니다. 아웃바운드 문서는 아웃바운드 작업과 문서 스타일에 따라 아웃바운드 결제 방법과 문서 표시 인터페이스를 각각 제공할 수 있습니다. 이러한 방식으로 전략 모드는 아웃바운드 동작과 아웃바운드 문서 환경을 분리하고 아웃바운드 알고리즘의 증가, 감소 또는 수정은 환경과 클라이언트에 영향을 미치지 않습니다. 그림 1-2 객체지향적 사고를 기반으로 설계된 아웃바운드 모듈 그림 1-3 디자인 패턴 사고를 기반으로 설계된 아웃바운드 모듈 전략 패턴의 장점은 알고리즘과 환경이 분리되어 있으며 둘이 독립적으로 진화할 수 있다는 점이다. 알고리즘과 환경 분리의 이점을 더 잘 설명하기 위해 그림 1-4의 설계를 살펴보는 것이 좋습니다. 이 디자인에는 모든 아웃바운드/인바운드 문서를 추상화하고 런타임 중에 문서의 인터페이스와 동작을 동적으로 결합하기 때문에 아웃바운드 및 인바운드 모듈에 대한 개념이 없습니다. 아웃바운드/인바운드 작업 클래스를 통해 다양한 동작 클래스를 유지 관리하고 쿼리하고 구성할 수 있습니다. 추상화된 아웃/인바운드 동작은 다양한 유형의 인바운드 및 아웃바운드 문서 작업을 완료하기 위해 해당 알고리즘을 전략 클래스 형식으로 캡슐화합니다. 이는 분명히 시스템의 재사용성과 확장성을 향상시키고 유지 관리의 어려움을 줄여줍니다. 그림 1-4 전략 패턴의 장점은 알고리즘과 환경이 독립적으로 진화할 수 있다는 점입니다. 전략 패턴은 다음과 같은 상황에 적합하다는 것을 알 수 있습니다. 오직 그들의 행동에서만. 전략 패턴을 사용하면 개체가 여러 동작 중에서 하나의 동작을 동적으로 선택할 수 있습니다. · 목표를 달성하기 위해 여러 대체 알고리즘이 있는 경우(예: 서로 다른 절충안(즉, 서로 다른 전략 적용)을 기반으로 정의하는 알고리즘). 이러한 특정 알고리즘은 추상 알고리즘 클래스의 파생 클래스로 캡슐화될 수 있으며 추상 알고리즘 클래스의 통합 인터페이스를 누릴 수 있습니다. 다형성을 통해 클라이언트는 추상 알고리즘 클래스의 개체를 보유하는 한 특정 알고리즘을 선택할 수 있습니다. · 알고리즘이 클라이언트가 사용할 수 없는 데이터를 사용하는 경우. 전략 패턴을 사용하면 복잡한 알고리즘 관련 데이터 구조가 노출되는 것을 방지할 수 있습니다. 사실 클라이언트는 알고리즘과 관련된 지식이나 데이터를 알 필요가 없습니다. · 클래스 정의에 많은 동작이 있고 여러 조건문을 사용하여 이러한 동작의 선택을 결정하는 경우. 전략 패턴은 이러한 동작을 해당하는 특정 전략 클래스로 전송할 수 있으므로 유지 관리가 어려운 여러 조건 선택을 피하고 객체 지향 프로그래밍 아이디어를 구현할 수 있습니다.
1.2 구조 및 사용법
전략 패턴의 구조는 그림 1-5에 표시되어 있으며 여기에는 다음 참가자가 포함됩니다. · 추상 전략(TStrategy) - 지원되는 모든 알고리즘에 대한 공통 인터페이스를 선언합니다. TContext는 이 인터페이스를 사용하여 TConcreteStrategy에 의해 정의되고 캡슐화된 알고리즘을 호출합니다. · 구체적인 전략(TConcreteStrategy) - 특정 알고리즘이나 동작을 캡슐화합니다. TStrategy 인터페이스를 구현합니다. · 컨텍스트(TContext) – TStrategy에 대한 참조를 보유합니다. 특정 알고리즘이나 동작을 동적으로 구성하려면 TStrategy 인터페이스를 호출하세요. 그림 1-5 전략 패턴의 구조 전략 패턴에서는 선택된 알고리즘이 TStrategy와 TContext의 상호 작용을 통해 구현됩니다. 알고리즘이 호출되면 TContext는 알고리즘에 필요한 모든 데이터를 TStrategy에 전달할 수 있습니다. 또는 TContext가 TStrategy 작업에 대한 매개변수로 자신을 전달할 수 있습니다. TContext가 클라이언트 요청을 TStrategy로 전달할 때 클라이언트는 일반적으로 이러한 방식으로 TConcreteStrategy 객체를 생성하고 TContext에 전달하며 클라이언트는 TContext와만 상호 작용합니다. 일반적으로 클라이언트가 선택할 수 있는 일련의 TConcreteStrategy 클래스가 있습니다. ------------------------------------- ---------------------------
더 많은 관련 기사와 샘플 프로그램 소스 코드는 저자 웹사이트(http://www.liu-yi.net)에서 다운로드할 수 있습니다.
