Command Pattern


1.1. 模式動機

在軟件設計中，我們經常需要向某些對象發送請求，但是並不知道請求的接收者是誰，也不知道被請求的操作是哪個，我們只需在程序運行時指定具體的請求接收者即可，此時，可以使用命令模式來進行設計，使得請求發送者與請求接收者消除彼此之間的耦合，讓對象之間的調用關係更加靈活。
命令模式可以對發送者和接收者完全解耦，發送者與接收者之間沒有直接引用關係，發送請求的對像只需要知道如何發送請求，而不必知道如何完成請求。這就是命令模式的模式動機。

1.2. 模式定義

命令模式(Command Pattern)：將一個請求封裝為一個對象，從而使我們可用不同的請求對客戶進行參數化；對請求排隊或者記錄請求日誌，以及支持可撤銷的操作。命令模式是一種對象行為型模式，其別名為動作(Action)模式或事務(Transaction)模式。

1.3. 模式結構

命令模式包含如下角色：
  • Command: 抽象命令類
  • ConcreteCommand: 具體命令類
  • Invoker: 調用者
  • Receiver: 接收者
  • Client:客戶類


1.4. 時序圖


1.5. 代碼分析

#include <iostream>
#include "ConcreteCommand.h"
#include "Invoker.h"
#include "Receiver.h"

using namespace std ;

int main ( int argc , char * argv [])
{
Receiver * pReceiver = new Receiver (); ConcreteCommand * pCommand = new ConcreteCommand ( pReceiver ); Invoker * pInvoker = new Invoker ( pCommand ); pInvoker -> call (); delete pReceiver ; delete pCommand ; delete pInvoker ; 
return 0 ;
}

////////////////////////////////////////////////// /////////
// Receiver.h
// Implementation of the Class Receiver
// Created on: 07-十月-2014 17:44:02
// Original author: colin
/////// ////////////////////////////////////////////////// //

#if !defined(EA_8E5430BB_0904_4a7d_9A3B_7169586237C8__INCLUDED_)
#define EA_8E5430BB_0904_4a7d_9A3B_7169586237C8__INCLUDED_

class Receiver
{

public :
        Receiver ();
        virtual ~ Receiver ();

        void action ();

};
#endif // !defined(EA_8E5430BB_0904_4a7d_9A3B_7169586237C8__INCLUDED_)
////////////////////////////////////////////////// /////////
// Receiver.cpp
// Implementation of the Class Receiver
// Created on: 07-十月-2014 17:44:02
// Original author: colin
/////// ////////////////////////////////////////////////// //

#include "Receiver.h"
#include <iostream>
using namespace std ;

Receiver :: Receiver (){

}

Receiver ::~ Receiver (){

}

void Receiver :: action (){
        cout << "receiver action." << endl ;
}
////////////////////////////////////////////////// /////////
// ConcreteCommand.h
// Implementation of the Class ConcreteCommand
// Created on: 07-十月-2014 17:44:01
// Original author: colin
/////// ////////////////////////////////////////////////// //

#if !defined(EA_1AE70D53_4868_4e81_A1B8_1088DA355C23__INCLUDED_)
#define EA_1AE70D53_4868_4e81_A1B8_1088DA355C23__INCLUDED_

#include "Command.h"
#include "Receiver.h"

class ConcreteCommand : public Command
{

public :
        ConcreteCommand ( Receiver * pReceiver );
        virtual ~ ConcreteCommand ();
        virtual void execute ();
private :
Receiver * m_pReceiver ;



};
#endif // !defined(EA_1AE70D53_4868_4e81_A1B8_1088DA355C23__INCLUDED_)
////////////////////////////////////////////////// /////////
// ConcreteCommand.cpp
// Implementation of the Class ConcreteCommand
// Created on: 07-十月-2014 17:44:02
// Original author: colin
/////// ////////////////////////////////////////////////// //

#include "ConcreteCommand.h"
#include <iostream>
using namespace std ;


ConcreteCommand :: ConcreteCommand ( Receiver * pReceiver ){
        m_pReceiver = pReceiver ;
}



ConcreteCommand ::~ ConcreteCommand (){

}

void ConcreteCommand :: execute (){
cout << "ConcreteCommand::execute" << endl ; m_pReceiver -> action (); }
////////////////////////////////////////////////// /////////
// Invoker.h
// Implementation of the Class Invoker
// Created on: 07-十月-2014 17:44:02
// Original author: colin
/////// ////////////////////////////////////////////////// //

#if !defined(EA_3DACB62A_0813_4d11_8A82_10BF1FB00D9A__INCLUDED_)
#define EA_3DACB62A_0813_4d11_8A82_10BF1FB00D9A__INCLUDED_

#include "Command.h"

class Invoker
{

public :
Invoker ( Command * pCommand ); virtual ~ Invoker (); void call (); private : Command * m_pCommand ; }; #endif // !defined(EA_3DACB62A_0813_4d11_8A82_10BF1FB00D9A__INCLUDED_)
////////////////////////////////////////////////// /////////
// Invoker.cpp
// Implementation of the Class Invoker
// Created on: 07-十月-2014 17:44:02
// Original author: colin
/////// ////////////////////////////////////////////////// //

#include "Invoker.h"
#include <iostream>
using namespace std ;

Invoker :: Invoker ( Command * pCommand ){
        m_pCommand = pCommand ;
}

Invoker ::~ Invoker (){

}

void Invoker :: call (){
cout << "invoker calling" << endl ; m_pCommand -> execute (); }

1.6. 模式分析

命令模式的本質是對命令進行封裝，將發出命令的責任和執行命令的責任分割開。
  • 每一個命令都是一個操作：請求的一方發出請求，要求執行一個操作；接收的一方收到請求，並執行操作。
  • 命令模式允許請求的一方和接收的一方獨立開來，使得請求的一方不必知道接收請求的一方的接口，更不必知道請求是怎麼被接收，以及操作是否被執行、何時被執行，以及是怎麼被執行的。
  • 命令模式使請求本身成為一個對象，這個對象和其他對像一樣可以被存儲和傳遞。
  • 命令模式的關鍵在於引入了抽象命令接口，且發送者針對抽象命令接口編程，只有實現了抽象命令接口的具體命令才能與接收者相關聯。

1.7. 實例

實例一：電視機遙控器
  • 電視機是請求的接收者，遙控器是請求的發送者，遙控器上有一些按鈕，不同的按鈕對應電視機的不同操作。抽象命令角色由一個命令接口來扮演，有三個具體的命令類實現了抽象命令接口，這三個具體命令類分別代表三種操作：打開電視機、關閉電視機和切換頻道。顯然，電視機遙控器就是一個典型的命令模式應用實例。


時序圖:


1.8. 優點

命令模式的優點
  • 降低系統的耦合度。
  • 新的命令可以很容易地加入到系統中。
  • 可以比較容易地設計一個命令隊列和宏命令（組合命令）。
  • 可以方便地實現對請求的Undo和Redo。

1.9. 缺點

命令模式的缺點
  • 使用命令模式可能會導致某些系統有過多的具體命令類。因為針對每一個命令都需要設計一個具體命令類，因此某些系統可能需要大量具體命令類，這將影響命令模式的使用。

1.10. 適用環境

在以下情況下可以使用命令模式：
  • 系統需要將請求調用者和請求接收者解耦，使得調用者和接收者不直接交互。
  • 系統需要在不同的時間指定請求、將請求排隊和執行請求。
  • 系統需要支持命令的撤銷(Undo)操作和恢復(Redo)操作。
  • 系統需要將一組操作組合在一起，即支持宏命令

1.11. 模式應用

很多系統都提供了宏命令功能，如UNIX平台下的Shell編程，可以將多條命令封裝在一個命令對像中，只需要一條簡單的命令即可執行一個命令序列，這也是命令模式的應用實例之一。

1.12. 模式擴展

宏命令又稱為組合命令，它是命令模式和組合模式聯用的產物。
-宏命令也是一個具體命令，不過它包含了對其他命令對象的引用，在調用宏命令的execute()方法時，將遞歸調用它所包含的每個成員命令的execute()方法，一個宏命令的成員對象可以是簡單命令，還可以繼續是宏命令。執行一個宏命令將執行多個具體命令，從而實現對命令的批處理。

1.13. 總結

  • 在命令模式中，將一個請求封裝為一個對象，從而使我們可用不同的請求對客戶進行參數化；對請求排隊或者記錄請求日誌，以及支持可撤銷的操作。命令模式是一種對象行為型模式，其別名為動作模式或事務模式。
  • 命令模式包含四個角色：抽象命令類中聲明了用於執行請求的execute()等方法，通過這些方法可以調用請求接收者的相關操作；具體命令類是抽象命令類的子類，實現了在抽象命令類中聲明的方法，它對應具體的接收者對象，將接收者對象的動作綁定其中；調用者即請求的發送者，又稱為請求者，它通過命令對象來執行請求；接收者執行與請求相關的操作，它具體實現對請求的業務處理。
  • 命令模式的本質是對命令進行封裝，將發出命令的責任和執行命令的責任分割開。命令模式使請求本身成為一個對象，這個對象和其他對像一樣可以被存儲和傳遞。
  • 命令模式的主要優點在於降低系統的耦合度，增加新的命令很方便，而且可以比較容易地設計一個命令隊列和宏命令，並方便地實現對請求的撤銷和恢復；其主要缺點在於可能會導致某些系統有過多的具體命令類。
  • 命令模式適用情況包括：需要將請求調用者和請求接收者解耦，使得調用者和接收者不直接交互；需要在不同的時間指定請求、將請求排隊和執行請求；需要支持命令的撤銷操作和恢復操作，需要將一組操作組合在一起，即支持宏命令。






留言

張貼留言

這個網誌中的熱門文章

Json概述以及python對json的相關操作

圖片
什麼是json： JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。易於人閱讀和編寫。同時也易於機器解析和生成。它基於JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一個子集。JSON採用完全獨立於語言的文本格式，但是也使用了類似於C語言家族的習慣（包括C, C++, C#, Java, JavaScript, Perl, Python等）。這些特性使JSON成為理想的數據交換語言。 JSON建構於兩種結構： “名稱/值”對的集合（A collection of name/value pairs）。不同的語言中，它被理解為對象（object），紀錄（record），結構（struct），字典（dictionary），哈希表（hash table），有鍵列表（keyed list），或者關聯數組（associative array）。 值的有序列表（An ordered list of values）。在大部分語言中，它被理解為數組（array）。 這些都是常見的數據結構。事實上大部分現代計算機語言都以某種形式支持它們。這使得一種數據格式在同樣基於這些結構的編程語言之間交換成為可能。 jso官方說 ​​明參見：http://json.org/ Python操作json的標準api庫參考：http://docs.python.org/library/json.html 對簡單數據類型的encoding 和decoding： 使用簡單的json.dumps方法對簡單數據類型進行編碼，例如： import json obj = [[ 1 , 2 , 3 ], 123 , 123.123 , 'abc' ,{ 'key1' :( 1 , 2 , 3 ), 'key2' :( 4 , 5 , 6 )}] encodedjson = json.dumps(obj) print repr (obj) print encodedjson 輸出： [[1, 2, 3], 123, 123.123, 'abc', {'ke...
閱讀完整內容

Docker容器日誌查看與清理

1. 問題 docker容器日誌導致主機磁盤空間滿了。 docker logs -f container_name 劈裡啪啦一大堆，很佔用空間，不用的日誌可以清理掉了。  2. 解決方法 2.1 找出Docker容器日誌 在linux上，容器日誌一般存放在 /var/lib/docker/containers/container_id/ 下面，查看各個日誌文件大小的腳本docker_log_size.sh，內容如下： #!/bin/sh echo "======== docker containers logs file size ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs do ls -lh $log done # chmod +x docker_log_size.sh # ./docker_log_size.sh 2.2 清理Docker容器日誌（治標） 如果docker容器正在運行，那麼使用 rm -rf 方式刪除日誌後，通過 df -h 會發現磁盤空間並沒有釋放。 原因是在Linux或者Unix系統中，通過 rm -rf 或者文件管理器刪除文件，將會從文件系統的目錄結構上解除鏈接（unlink）。 如果文件是被打開的（有一個進程正在使用），那麼進程將仍然可以讀取該文件，磁盤空間也一直被佔用。 正確姿勢是 cat /dev/null > *-json.log ，當然你也可以通過 rm -rf 刪除後重啟docker。 接下來，提供一個日誌清理腳本 clean_docker_log.sh ，內容如下： #!/bin/sh echo "======== start clean docker containers logs ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs d...
閱讀完整內容

利用 Keepalived 提供 VIP

Keepalived 是一種基於 VRRP 協定實現的高可靠 Web 服務方案，用於防止單點故障問題。因此一個 Web 服務運作至少會擁有兩台伺服器執行 Keepalived，一台作為 master，一台作為 backup，並提供一個虛擬 IP（VIP），master 會定期發送特定訊息給 backup 伺服器，當 backup 沒收到 master 訊息時，表示 master 已故障，這時候 backup 會接管 VIP，繼續提供服務，來確保服務的高可靠性。 VRRP VRRP（Virtual Router Redundancy Protocol，虛擬路由器備援協定），是一個提供備援路由器來解決單點故障問題的協定，該協定有兩個重要概念： * VRRP 路由器與虛擬路由器：VRRP 路由器是表示運作 VRRP 的路由器，是一個實體裝置，而虛擬路由器是指由 VRRP 建立的邏輯路由器。一組 VRRP 路由器協同運作，並一起構成一台虛擬路由器，該虛擬路由對外提供一個唯一固定的 IP 與 MAC 位址的邏輯路由器。 * 主控制路由器（master）與備援路由器（backup）：主要是在一組 VRRP 中的兩種互斥角色。一個 VRRP 群組中只能擁有一台是 master，但可以有多個 backup 路由器。 VRRP 協定使用選擇策略從路由器群組挑選一台作為 master 來負責 ARP 與轉送 IP 封包，群組中其他路由器則作為 backup 的角色處理等待狀態。當由於某種原因造成 master 故障時，backup 會在幾秒內成為 master 繼續提供服務，該階段不用改變任何 IP 與 MAC 位址。 Keepalived 節點配置 IP ADDRESS ROLE 172.16.1.101 vip 172.16.1.102 master 172.16.1.103 backup 安裝與設定 這 ubuntu 14.04 LTS Server 中已經內建了 Keepalived 可以透過 apt-get 來安裝： $ sudo apt-get install -y keepalived 也可以透過 source code 進行安裝，流程如下： $ sudo apt-get install build-essential libssl-dev $ wge...
閱讀完整內容