Java 디자인 패턴의 명령 패턴 설명 예

명령 모드는 명령을 캡슐화한 것입니다. 명령 모드 클래스 다이어그램의 기본 구조는 아래에 소개되어 있습니다. Java 디자인 모드의 명령 모드 지식에 관심이 있는 친구들은 함께 살펴보세요.

정의: 요청을 An으로 캡슐화합니다. 다양한 요청, 대기열 또는 로그 요청으로 클라이언트를 매개변수화하고 명령에 대한 실행 취소 및 다시 실행 기능을 제공할 수 있는 개체입니다.

유형: 동작 패턴

클래스 다이어그램:

명령 패턴의 구조

이름에서 알 수 있듯이 명령 패턴은 명령의 캡슐화입니다. 먼저 기본 구조를 살펴보겠습니다. 명령 패턴 클래스 다이어그램:

• Command 클래스: 추상 클래스입니다. 클래스는 실행해야 하는 명령을 선언합니다. 일반적으로 명령을 실행하려면 실행 메서드를 외부에 게시해야 합니다.

• ConcreteCommand 클래스: Command 클래스의 구현 클래스로, 추상 클래스에 선언된 메소드를 구현합니다.

• 클라이언트 클래스: 최종 클라이언트 호출 클래스입니다.

위 세 가지 클래스의 기능은 비교적 이해하기 쉬울 것입니다. Invoker 클래스와 Recevier 클래스에 중점을 두겠습니다.

• Invoker 클래스: Invoker, 명령 호출을 담당합니다.

• Receiver 클래스: Receiver 클래스: 명령을 수신하고 실행하는 역할을 담당합니다. 소위 명령 패키징은 일련의 작업을 메서드에 작성하고 클라이언트를 호출할 수 있는 것에 지나지 않습니다. 이는 Concretecommand 클래스와 After 클래스만 필요합니다. 명령 캡슐화를 완료하고 유연성을 높이기 위해 적절한 추상화를 위해 다른 Command 클래스를 추가할 수 있습니다. 이 호출자와 수신자의 기능은 무엇입니까?

사실 다른 각도에서 생각해 볼 수도 있습니다. 단순히 일부 작업을 다른 사람이 호출할 수 있는 명령으로 캡슐화한다면 이를 어떻게 패턴이라고 부를 수 있을까요? 행동 패턴으로서 명령 패턴은 먼저 낮은 결합도를 달성해야 합니다. 낮은 결합도는 유연성을 향상시킬 수 있으며 호출자와 수신자라는 두 가지 역할을 추가하는 목적은 바로 이러한 목적입니다. 명령 모드의 일반적인 코드는 다음과 같습니다.

class Invoker { 
 private Command command; 
 public void setCommand(Command command) { 
  this.command = command; 
 } 
 public void action(){ 
  this.command.execute(); 
 } 
} 
abstract class Command { 
 public abstract void execute(); 
} 
class ConcreteCommand extends Command { 
 private Receiver receiver; 
 public ConcreteCommand(Receiver receiver){ 
  this.receiver = receiver; 
 } 
 public void execute() { 
  this.receiver.doSomething(); 
 } 
} 
class Receiver { 
 public void doSomething(){ 
  System.out.println("接受者-业务逻辑处理"); 
 } 
} 
public class Client { 
 public static void main(String[] args){ 
  Receiver receiver = new Receiver(); 
  Command command = new ConcreteCommand(receiver); 
  //客户端直接执行具体命令方式（此方式与类图相符） 
  command.execute(); 
 
  //客户端通过调用者来执行命令 
  Invoker invoker = new Invoker(); 
  invoker.setCommand(command); 
  invoker.action(); 
 } 
}

코드를 통해 우리가 호출할 때 실행 순서는 먼저 호출자 클래스, 다음 명령 클래스, 마지막으로 수신자 클래스임을 알 수 있습니다. 즉, 명령의 실행은 세 단계로 나뉘며 모든 작업을 클래스로 캡슐화하는 것보다 결합 정도가 훨씬 낮습니다. 이것이 명령 패턴의 본질입니다. 양 당사자는 상대방이 어떻게 작동하는지 신경 쓸 필요가 없습니다.

명령 모드의 장점과 단점

우선 명령 모드는 캡슐화가 잘되어 있습니다. 클라이언트의 경우 어떤 기능이 필요한 경우 별도의 작업 없이 해당 명령을 호출할 수 있습니다. 명령이 어떻게 실행되는지 알 수 있습니다. 예를 들어, 새 파일 생성, 파일 복사, 파일 삭제 등의 파일 작업 명령 집합이 있습니다. 이 세 가지 작업이 명령 클래스에 캡슐화되면 클라이언트는 이 세 가지 명령 클래스가 있다는 것만 알면 됩니다. 명령 클래스에 캡슐화된 논리는 클라이언트가 알 필요가 없습니다. 둘째, 명령 모드에서는 확장성이 매우 뛰어납니다. 일반적으로 수신기 클래스는 가장 기본적인 작업을 캡슐화하고, 명령 클래스는 새 명령이 추가될 때 이러한 기본 작업을 다시 캡슐화합니다. 명령 클래스는 일반적으로 처음부터 시작되지 않습니다. 호출할 수신자 클래스가 많고 코드 재사용성이 매우 좋습니다. 예를 들어, 파일 작업 중에 파일을 잘라내는 명령을 추가해야 하는 경우 파일 복사 및 파일 삭제라는 두 가지 명령만 결합하면 매우 편리합니다.

마지막으로 명령어 모드의 단점, 즉 명령어가 많으면 개발이 골치아픈 점에 대해 말씀드리겠습니다. 특히, 명령 모드를 사용하면 아무리 간단한 명령이라도 이를 캡슐화하는 명령 클래스를 작성해야 합니다.

명령 모드의 적용 가능한 시나리오

대부분의 요청-응답 모드 기능의 경우 명령 모드를 사용하는 것이 더 적합합니다. 명령 모드 정의에서 알 수 있듯이 명령 모드는 로깅과 같은 기능을 구현하는 데 더 적합합니다. 작업을 취소하는 것이 편리합니다.

요약

底 한 번, 한 번, 이것은 모든 개발자에게 매우 얽힌 문제입니다. 때로는 수요의 변화가 예상되어 시스템의 유연성과 확장성을 위해 특정 디자인 패턴을 사용하지만, 반대로 코드를 수정하면 예상치 못한 수요가 발생하는 경우가 많습니다. 사용된 디자인 패턴은 반대 효과를 가져서 전체 프로젝트 팀이 불평하게 만들었습니다. 나는 모든 프로그래머가 그러한 예를 접했다고 믿습니다. 따라서 애자일 개발의 원칙에 입각하여 프로그램을 설계할 때, 현재의 필요에 따라 특정 패턴을 사용하지 않고도 잘 해결할 수 있다면 도입하지 않는 것이 좋습니다. 디자인 도입이 어렵지 않기 때문입니다. 패턴을 사용하면 시스템을 개선하고 실제로 사용해야 할 때 이 디자인 패턴을 도입할 수 있습니다.来 명령 모드를 사용합니다. 우리 개발에서는 요청-응답 모드의 기능이 매우 일반적입니다. 일반적으로 요청의 응답 작업을 메서드로 캡슐화하지만 명령 모드에서는 캡슐화하지 않습니다. 이 설계를 패턴 수준으로 끌어올릴 것인지는 별도로 고려해야 한다. 왜냐하면 명령 패턴을 사용하면 호출자와 수신자라는 두 가지 역할이 도입되고 원래 한 곳에 있던 로직이 분산되기 때문이다. 세 가지 등급으로 나누어 디자인할 때 비용이 그만한 가치가 있는지 고려해야 합니다.

위 내용은 Java 디자인 패턴의 명령 패턴 설명 예의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!