올바른 명령 설계 패턴 구현을 위해 수신기에 대한 링크가 필요합니까?

Question

Go GoF 디자인 패턴 (wikipedia), ConcreteCommand 인스턴스에 Receiver 인스턴스에 대한 링크 (참조)가 있어야합니까? 다음 명령을 구현했습니다 :

internal class PutBlockOntoBlockCommand : ICommand { 
    private readonly int _srcTower; 
    private readonly int _dstTower; 

    public PutBlockOntoBlockCommand(int srcTower, int dstTower) { 
     _srcTower = srcTower; 
     _dstTower = dstTower; 
    } 

    public void Execute(Robot robot, Construction construction) { 
     robot.MoveBlocks(_srcTower, _dstTower, construction); 
    } 
} 

이 명령은 로봇이 건설 현장에서 블록을 이동하도록 지시합니다. 명령의 인스턴스에 수신자 (로봇)의 인스턴스에 대한 참조가 없다는 점에 유의하십시오. 대신 명령은 Robot의 인스턴스를 제공하여 명령을 실행하기 위해 Invoker (필자의 경우 RobotCommandCenter)에 의존합니다.

나는 명령은 명령이어야하는 것이 만 의도를 캡슐화해야 확신하고 하지 명령의 대상을 지정하는 책임을 져야한다. 내 경우에는 사용자로서 어떤 로봇이 작업을 실행하는 데 사용되는지는 신경 쓰지 않습니다.

제 질문은 : "Command Design Pattern"으로 제시된 구현을 기술적으로 참조 할 수 있습니까?

Answer 1

먼저 디자인 패턴 경찰이 없습니다. 항상 해석이 가능하고 회색 음영으로 색칠합니다. AS를 요청을 캡슐화

:

둘째, 위키 책 :

GoF의 목록과 같은 명령 패턴의 의도에 투자를, 원래 볼륨만큼 좋지 않다 따라서 서로 다른 요청, 대기열 또는 로그 요청을 가진 클라이언트를 매개 변수화하고 실행 취소 작업을 지원할 수 있습니다.

이러한 의도 중 하나라도 충족 시키면 명령 유도체라고 부를 수 있습니다.

원하는 효과를 구현하거나 호출하기위한 논리를 보유하고 있으면 명령으로 알릴 수 있으므로 명령 참조의 소유자가 이러한 세부 정보를 처리 할 필요가 없습니다. 종종 이것은 캡슐화되어 있으므로 목록에 넣고 기본으로 정의 된 일반적인 Execute 메서드를 사용하여 다시 실행 및 실행 취소를 매우 명확하게 수행하는 등 멋진 작업을 수행 할 수 있습니다.

기본 클래스가 실행을 정의하고 호출 코드가 로봇 참조를 모두 전달하면 명령은 있지만 명령의 대상을 변경할 수있는 전략 또는 플라이 웨이 측면이 있습니다. 이것에 대한 사용법을 볼 수 있지만 실행 취소/다시 실행과 같은 일을 희생합니다.