1
작업 준비와 실행을 구분하는 디자인 패턴이 있습니까?작업 준비를 실행과 분리하기위한 디자인 패턴이 있습니까?
몇 가지 예 :
- 데이터베이스 쿼리 계획을 수립하고 실행하여 쿼리를 실행합니다.
- 내 응용 프로그램의 경우 진행률 표시 줄을 표시 할 수 있도록 파일 복사를위한 단계적 접근 방식을 구현했습니다. 먼저 파일 복사 작업 목록을 만든 다음 각 작업의 가중치 (파일 크기)에 따라 진행률 막대를 업데이트하는 목록을 반복합니다.
- 또한 일괄 처리 목록을 준비한 다음 데이터를 가져 오는 단계적 접근 방식을 구현했습니다. 그 이유는 복잡성을 줄이기 (다른 배치가 다른 매개 변수를 가짐) 및 메모리 과부하를 방지하기 위해서였습니다 (배치로 가져 오는 최대 데이터 량이 있습니다).
기본 패턴은 개별적으로 실행할 수있는 '작업 항목'으로 작업을 분류하는 '계획자'개체가 있다는 것입니다.
저는 궁금 해서요. 이미 알려진 디자인 패턴이 다른 개발자와 의사 소통하고 설계 개선에 도움이 될 수 있기를 바랍니다.
명령 패턴은 요청을 객체에 캡슐화하고 요청 실행 방법을 지정하지 않습니다. '작업 항목'은 일종의 실제 구현을 나타냅니다. 나는 CompositeCommand 아이디어를 좋아합니다. –
@martijn, 표준 명령에는 "실행"방법이 있습니다. 나는 그들이 당신이 일을하지 않는다는 것을 암시한다고 생각합니다. 나는 그것에 전혀 동의하지 않는다. 본질적으로 명령 패턴은 작업을 캡처하여 선택한 시간에 실행하는 방법입니다. – hvgotcodes
@hvgotcodes 감마의 Command의 Participants 섹션에는 ConcreteCommand가 Receiver 객체와 액션 간의 바인딩을 정의한다고 나와 있습니다. Receiver 오브젝트는 조치와 연관된 조작을 수행하는 f}을 압니다. 따라서 Command의 고전적인 구현에서 ConcreteCommand는 Receiver에서 메서드를 호출하여 Execute()를 구현합니다.이는 ConcreteCommand가 '실제'작업을 수행하지 않는다는 것을 의미합니다. 일반적으로 'Command'는 올바른 패턴으로 느껴지지 않습니다. 객체와 의사 소통하는 것과 관련이 있기 때문에 제가 찾고있는 것이 아닙니다. –