Decorator Pattern

3. 裝飾模式


3.1. 模式動機

一般有兩種方式可以實現給一個類或對象增加行為：
  • 繼承機制，使用繼承機制是給現有類添加功能的一種有效途徑，通過繼承一個現有類可以使得子類在擁有自身方法的同時還擁有父類的方法。但是這種方法是靜態的，用戶不能控制增加行為的方式和時機。
  • 關聯機制，即將一個類的對象嵌入另一個對像中，由另一個對象來決定是否調用嵌入對象的行為以便擴展自己的行為，我們稱這個嵌入的對象為裝飾器(Decorator)


裝飾模式以對客戶透明的方式動態地給一個對象附加上更多的責任，換言之，客戶端並不會覺得對像在裝飾前和裝飾後有什麼不同。裝飾模式可以在不需要創造更多子類的情況下，將對象的功能加以擴展。這就是裝飾模式的模式動機。

3.2. 模式定義

裝飾模式(Decorator Pattern) ：動態地給一個對象增加一些額外的職責(Responsibility)，就增加對像功能來說，裝飾模式比生成子類實現更為靈活。其別名也可以稱為包裝器(Wrapper)，與適配器模式的別名相同，但它們適用於不同的場合。根據翻譯的不同，裝飾模式也有人稱之為“油漆工模式”，它是一種對象結構型模式。

3.3. 模式結構

裝飾模式包含如下角色：
  • Component: 抽象構件
  • ConcreteComponent: 具體構件
  • Decorator: 抽象裝飾類
  • ConcreteDecorator: 具體裝飾類

3.4. 時序圖



3.5. 代碼分析

////////////////////////////////////////////////// /////////
// ConcreteComponent.cpp
// Implementation of the Class ConcreteComponent
// Created on: 03-十月-2014 18:53:00
// Original author: colin
/////// ////////////////////////////////////////////////// //

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


ConcreteComponent :: ConcreteComponent (){

}

ConcreteComponent ::~ ConcreteComponent (){

}

void ConcreteComponent :: operation (){
        cout << "ConcreteComponent's normal operation!" << endl ;
}

////////////////////////////////////////////////// /////////
// ConcreteDecoratorA.h
// Implementation of the Class ConcreteDecoratorA
// Created on: 03-十月-2014 18:53:00
// Original author: colin
/////// ////////////////////////////////////////////////// //

#if !defined(EA_6786B68E_DCE4_44c4_B26D_812F0B3C0382__INCLUDED_)
#define EA_6786B68E_DCE4_44c4_B26D_812F0B3C0382__INCLUDED_

#include "Decorator.h"
#include "Component.h"

class ConcreteDecoratorA : public Decorator
{

public :
        ConcreteDecoratorA ( Component * pcmp );
        virtual ~ ConcreteDecoratorA ();

        void addBehavior ();
        virtual void operation ();

};
#endif // !defined(EA_6786B68E_DCE4_44c4_B26D_812F0B3C0382__INCLUDED_)

////////////////////////////////////////////////// /////////
// ConcreteDecoratorA.cpp
// Implementation of the Class ConcreteDecoratorA
// Created on: 03-十月-2014 18:53:00
// Original author: colin
/////// ////////////////////////////////////////////////// //

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

ConcreteDecoratorA :: ConcreteDecoratorA ( Component * pcmp )
: Decorator ( pcmp )
{

}

ConcreteDecoratorA ::~ ConcreteDecoratorA (){

}

void ConcreteDecoratorA :: addBehavior (){
cout << "addBehavior AAAA" << endl ; } void ConcreteDecoratorA :: operation (){ Decorator :: operation (); addBehavior (); }

3.6. 模式分析

  • 與繼承關係相比，關聯關係的主要優勢在於不會破壞類的封裝性，而且繼承是一種耦合度較大的靜態關係，無法在程序運行時動態擴展。在軟件開發階段，關聯關係雖然不會比繼承關係減少編碼量，但是到了軟件維護階段，由於關聯關係使系統具有較好的松耦合性，因此使得系統更加容易維護。當然，關聯關係的缺點是比繼承關係要創建更多的對象。
  • 使用裝飾模式來實現擴展比繼承更加靈活，它以對客戶透明的方式動態地給一個對象附加更多的責任。裝飾模式可以在不需要創造更多子類的情況下，將對象的功能加以擴展。

3.7. 實例

實例：變形金剛
變形金剛在變形之前是一輛汽車，它可以在陸地上移動。當它變成機器人之後除了能夠在陸地上移動之外，還可以說話；如果需要，它還可以變成飛機，除了在陸地上移動還可以在天空中飛翔。



3.8. 優點

裝飾模式的優點:
  • 裝飾模式與繼承關係的目的都是要擴展對象的功能，但是裝飾模式可以提供比繼承更多的靈活性。
  • 可以通過一種動態的方式來擴展一個對象的功能，通過配置文件可以在運行時選擇不同的裝飾器，從而實現不同的行為。
  • 通過使用不同的具體裝飾類以及這些裝飾類的排列組合，可以創造出很多不同行為的組合。可以使用多個具體裝飾類來裝飾同一對象，得到功能更為強大的對象。
  • 具體構件類與具體裝飾類可以獨立變化，用戶可以根據需要增加新的具體構件類和具體裝飾類，在使用時再對其進行組合，原有代碼無須改變，符合“開閉原則”

3.9. 缺點

裝飾模式的缺點:
  • 使用裝飾模式進行系統設計時將產生很多小對象，這些對象的區別在於它們之間相互連接的方式有所不同，而不是它們的類或者屬性值有所不同，同時還將產生很多具體裝飾類。這些裝飾類和小對象的產生將增加系統的複雜度，加大學習與理解的難度。
  • 這種比繼承更加靈活機動的特性，也同時意味著裝飾模式比繼承更加易於出錯，排錯也很困難，對於多次裝飾的對象，調試時尋找錯誤可能需要逐級排查，較為煩瑣。

3.10. 適用環境

在以下情況下可以使用裝飾模式：
  • 在不影響其他對象的情況下，以動態、透明的方式給單個對象添加職責。
  • 需要動態地給一個對象增加功能，這些功能也可以動態地被撤銷。
  • 當不能採用繼承的方式對系統進行擴充或者採用繼承不利於系統擴展和維護時。不能採用繼承的情況主要有兩類：第一類是系統中存在大量獨立的擴展，為支持每一種組合將產生大量的子類，使得子類數目呈爆炸性增長；第二類是因為類定義不能繼承（如final類）.

3.12. 模式擴展

裝飾模式的簡化-需要注意的問題:
  • 一個裝飾類的接口必須與被裝飾類的接口保持相同，對於客戶端來說無論是裝飾之前的對像還是裝飾之後的對像都可以一致對待。
  • 盡量保持具體構件類Component作為一個“輕”類，也就是說不要把太多的邏輯和狀態放在具體構件類中，可以通過裝飾類
對其進行擴展。- 如果只有一個具體構件類而沒有抽象構件類，那麼抽象裝飾類可以作為具體構件類的直接子類。

3.13. 總結

  • 裝飾模式用於動態地給一個對象增加一些額外的職責，就增加對像功能來說，裝飾模式比生成子類實現更為靈活。它是一種對象結構型模式。
  • 裝飾模式包含四個角色：抽象構件定義了對象的接口，可以給這些對象動態增加職責（方法）；具體構件定義了具體的構件對象，實現了在抽象構件中聲明的方法，裝飾器可以給它增加額外的職責（方法）； 抽象裝飾類是抽象構件類的子類，用於給具體構件增加職責，但是具體職責在其子類中實現；具體裝飾類是抽象裝飾類的子類，負責向構件添加新的職責。
  • 使用裝飾模式來實現擴展比繼承更加靈活，它以對客戶透明的方式動態地給一個對象附加更多的責任。裝飾模式可以在不需要創造更多子類的情況下，將對象的功能加以擴展。
  • 裝飾模式的主要優點在於可以提供比繼承更多的靈活性，可以通過一種動態的方式來擴展一個對象的功能，並通過使用不同的具體裝飾類以及這些裝飾類的排列組合，可以創造出很多不同行為的組合，而且具體構件類與具體裝飾類可以獨立變化，用戶可以根據需要增加新的具體構件類和具體裝飾類；其主要缺點在於使用裝飾模式進行系統設計時將產生很多小對象，而且裝飾模式比繼承更加易於出錯，排錯也很困難，對於多次裝飾的對象，調試時尋找錯誤可能需要逐級排查，較為煩瑣。
  • 裝飾模式適用情況包括：在不影響其他對象的情況下，以動態、透明的方式給單個對象添加職責；需要動態地給一個對象增加功能，這些功能也可以動態地被撤銷；當不能採用繼承的方式對系統進行擴充或者採用繼承不利於系統擴展和維護時。
  • 裝飾模式可分為透明裝飾模式和半透明裝飾模式：在透明裝飾模式中，要求客戶端完全針對抽象編程，裝飾模式的透明性要求客戶端程序不應該聲明具體構件類型和具體裝飾類型，而應該全部聲明為抽象構件類型；半透明裝飾模式允許用戶在客戶端聲明具體裝飾者類型的對象，調用在具體裝飾者中新增的方法。



留言

張貼留言

這個網誌中的熱門文章

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...
閱讀完整內容