23 디자인 모드, 17 장 : Java 명령 모드
정의 : 요청을 객체로 캡슐화하여 다른 요청, 큐 요청 또는 레코드 요청 로그를 사용하여 클라이언트를 매개 변수화하고 명령 취소 및 복구 기능을 제공 할 수 있습니다.
유형 : 행동 패턴
클래스 다이어그램 :
명령 모드의 구조
이름에서 알 수 있듯이 명령 모드는 명령의 캡슐화입니다. 먼저 명령 모드 클래스 다이어그램의 기본 구조를 살펴 보겠습니다.
명령 클래스 : 실행 해야하는 명령을 선언하는 추상 클래스입니다. 일반적으로, 실행 방법은 명령을 실행하려면 대중에게 게시되어야합니다.
ConcreteCommand 클래스 : 명령 클래스의 구현 클래스는 추상 클래스에서 선언 된 메소드를 구현합니다.
클라이언트 클래스 : 최종 클라이언트 전화 클래스.
위의 세 클래스의 기능은 이해하기 쉬워야합니다. Invoker 클래스 및 리시버 클래스에 중점을 두겠습니다.
Invoker 클래스 : 발신자는 명령을 호출 할 책임이 있습니다.
수신기 클래스 : 수신기는 명령을 수신하고 실행할 책임이 있습니다.
무뚝뚝하게 말하면, 소위 명령 캡슐화는 일련의 작업을 메소드에 작성한 다음 클라이언트에 의해 호출되는 것 이상입니다. 클래스 다이어그램에 반영됩니다. 명령의 캡슐화를 완료하려면 ConcreteCommand 클래스 및 클라이언트 클래스 만 필요합니다. 더 나아가더라도 유연성을 높이기 위해 적절한 추상화를 위해 명령 클래스를 추가 할 수 있습니다. 이 발신자와 수신기의 기능은 무엇입니까?
사실, 당신은 다른 관점에서 생각할 수 있습니다. 다른 사람들이 전화를 걸도록 명령으로 일부 작업을 단순히 캡슐화한다면 어떻게 패턴이라고 할 수 있습니까? 행동 모델로서 명령 모드는 먼저 낮은 커플 링을 달성해야합니다. 커플 링 정도가 낮을 때만 유연성이 향상됩니다. 발신자와 수신자 역할을 추가하는 목적은 정확히 이에 대한 것입니다. 명령 모드의 일반 코드는 다음과 같습니다.
클래스 invoker {private command 명령; public void setcommand (명령 명령) {this.command = 명령; } public void action () {this.command.execute (); }} Abstract Class Command {public Abstract void execute (); } Class ConcreteCommand 확장 명령 {개인 수신기 수신기; Public ConcreteCommand (수신기 수신기) {this.receiver = 수신기; } public void execute () {this.receiver.dosomething (); }} 클래스 수신기 {public void dosomething () {System.out.println ( "수신자-비즈니스 논리 처리"); }} public class client {public static void main (String [] args) {수신기 수신기 = new 수신기 (); 명령 = 새로운 ConcreteCommand (수신기); // 클라이언트는 특정 명령 메소드를 직접 실행합니다 (이 메소드는 클래스 다이어그램과 일치합니다) 명령 .execute (); // 클라이언트는 발신자 invoker = new invoker ()를 통해 명령을 실행합니다. invoker.setCommand (명령); invoker.action (); }}코드를 통해 우리는 호출 할 때 실행 타이밍이 먼저 발신자 클래스, 명령 클래스 및 수신기 클래스임을 알 수 있습니다. 다시 말해, 명령의 실행은 세 단계로 나뉘며 커플 링 정도는 모든 작업을 클래스에 캡슐화하는 것보다 훨씬 낮습니다. 이것은 명령 패턴의 본질입니다. 명령의 발신자와 집행자를 분리하여 양 당사자가 상대방의 운영 방식에 대해 신경 쓰지 않아도됩니다.
명령 모드의 장점과 단점
우선, 명령 모드는 매우 캡슐화됩니다. 각 명령은 캡슐화되고 클라이언트의 경우 명령이 어떻게 실행되는지 모르면 해당 명령이 필요합니다. 예를 들어, 파일 작동 명령 세트가 있습니다. 새 파일을 만들고 파일을 복사하고 파일을 삭제합니다. 이 세 가지 작업이 명령 클래스로 캡슐화되면 클라이언트는이 세 가지 명령 클래스가 있다는 것을 알아야합니다. 명령 클래스에 캡슐화 된 논리는 클라이언트가 알 필요가 없습니다.
둘째, 명령 모드는 확장 성이 양호합니다. 명령 모드에서 수신기 클래스에서의 작업의 가장 기본적인 캡슐화 및 이러한 기본 작업의 명령 클래스 보조 캡슐화. 새 명령을 추가 할 때 명령 클래스의 쓰기는 일반적으로 처음부터 아닙니다. 통화용 수신기 클래스가 많으며 통화를위한 많은 명령 클래스가 있으며 코드는 매우 재사용 가능합니다. 예를 들어, 파일 작업에서 파일을 자르려면 명령을 추가해야하며 파일 복사와 파일을 삭제하는 두 명령 만 결합하면 매우 편리합니다.
마지막으로, 명령 모드의 단점, 즉 많은 명령이 있다면 개발에 두통이 될 것입니다. 특히 많은 간단한 명령은 구현해야 할 코드의 몇 줄에 불과합니다. 명령 모드를 사용하는 경우 명령이 얼마나 간단한 지 걱정할 필요가 없으므로 명령 클래스를 작성하여 캡슐화해야합니다.
명령 모드에 적용 가능한 시나리오
대부분의 요청-응답 모드 함수의 경우 명령 모드를 사용하는 것이 더 적합합니다. 명령 모드 정의에서 알 수 있듯이 명령 모드는 로깅 및 취소 작업과 같은 기능을 구현하는 데 더 편리합니다.
요약
경우에 모드를 사용해야하는지 여부는 모든 개발자에게 매우 얽힌 질문입니다. 때로는 요구 사항의 일부 변화로 인해 특정 설계 패턴이 시스템의 유연성과 확장성에 사용되지만이 예측 가능한 요구 사항은 그렇지 않습니다. 반대로, 많은 예측할 수없는 요구 사항이 왔으며, 디자인 패턴이 코드를 수정할 때 반대 역할을 수행하여 전체 프로젝트 팀이 불만을 제기했습니다. 나는 모든 프로그래머가 그러한 모범을 보인다고 생각합니다. 따라서 민첩한 개발의 원칙에 따라, 우리가 프로그램을 설계 할 때, 현재 요구에 따라 특정 패턴을 사용하지 않고 프로그램을 잘 해결할 수 있다면 설계 패턴을 도입하는 것이 어렵지 않기 때문에 소개해서는 안됩니다. 우리는 그것을 실제로 사용 하고이 설계 패턴을 소개해야 할 때 시스템에서 수행 할 수 있습니다.
명령 모드를 예로 들어보십시오. 우리의 개발에서 요청-응답 모드 함수는 매우 일반적입니다. 일반적으로, 우리는 요청에 대한 응답 작업을 메소드로 캡슐화합니다. 이 캡슐화 된 메소드는 명령 모드라고 할 수는 없지만 명령 모드라고 할 수 있습니다. 명령 모드를 사용하는 경우 발신자와 수신기의 두 역할을 도입해야하기 때문에이 설계를 패턴 높이로 고려해야하는지 여부는 별도로 고려해야합니다. 원래 한 곳에 배치 된 논리는 세 가지 범주로 흩어져 있습니다. 설계 할 때는이 비용이 그만한 가치가 있는지 고려해야합니다.
위는이 기사의 모든 내용입니다. 모든 사람의 학습에 도움이되기를 바랍니다. 모든 사람이 wulin.com을 더 지원하기를 바랍니다.