Simple Factory Pattern

1. 簡單工廠模式( Simple Factory Pattern )

1.1. 模式動機

考慮一個簡單的軟件應用場景，一個軟件系統可以提供多個外觀不同的按鈕（如圓形按鈕、矩形按鈕、菱形按鈕等）， 這些按鈕都源自同一個基類，不過在繼承基類後不同的子類修改了部分屬性從而使得它們可以呈現不同的外觀，如果我們希望在使用這些按鈕時，不需要知道這些具體按鈕類的名字，只需要知道表示該按鈕類的一個參數，並提供一個調用方便的方法，把該參數傳入方法即可返回一個相應的按鈕對象，此時，就可以使用簡單工廠模式。

1.2. 模式定義

簡單工廠模式(Simple Factory Pattern)：又稱為靜態工廠方法(Static Factory Method)模式，它屬於類創建型模式。在簡單工廠模式中，可以根據參數的不同返回不同類的實例。簡單工廠模式專門定義一個類來負責創建其他類的實例，被創建的實例通常都具有共同的父類。

1.3. 模式結構

簡單工廠模式包含如下角色：
  • Factory：工廠角色
    工廠角色負責實現創建所有實例的內部邏輯
  • Product：抽象產品角色
    抽象產品角色是所創建的所有對象的父類，負責描述所有實例所共有的公共接口
  • ConcreteProduct：具體產品角色
    具體產品角色是創建目標，所有創建的對像都充當這個角色的某個具體類的實例。


1.4. 時序圖

1.5. 代碼分析

////////////////////////////////////////////////// /////////
// Factory.cpp
// Implementation of the Class Factory
// Created on: 01-十月-2014 18:41:33
// Original author: colin
/////// ////////////////////////////////////////////////// //

#include "Factory.h"
#include "ConcreteProductA.h"
#include "ConcreteProductB.h"
Product * Factory :: createProduct ( string proname ){
if ( "A" == proname ) { return new ConcreteProductA (); } else if ( "B" == proname ) { return new ConcreteProductB (); } return NULL ; }


1.6. 模式分析

  • 將對象的創建和對象本身業務處理分離可以降低系統的耦合度，使得兩者修改起來都相對容易。
  • 在調用工廠類的工廠方法時，由於工廠方法是靜態方法，使用起來很方便，可通過類名直接調用，而且只需要傳入一個簡單的參數即可，在實際開發中，還可以在調用時將所傳入的參數保存在XML等格式的配置文件中，修改參數時無須修改任何源代碼。
  • 簡單工廠模式最大的問題在於工廠類的職責相對過重，增加新的產品需要修改工廠類的判斷邏輯，這一點與開閉原則是相違背的。
  • 簡單工廠模式的要點在於：當你需要什麼，只需要傳入一個正確的參數，就可以獲取你所需要的對象，而無須知道其創建細節。

1.7. 實例

(略）

1.8. 簡單工廠模式的優點

  • 工廠類含有必要的判斷邏輯，可以決定在什麼時候創建哪一個產品類的實例，客戶端可以免除直接創建產品對象的責任，而僅僅“消費”產品；簡單工廠模式通過這種做法實現了對責任的分割，它提供了專門的工廠類用於創建對象。
  • 客戶端無須知道所創建的具體產品類的類名，只需要知道具體產品類所對應的參數即可，對於一些複雜的類名，通過簡單工廠模式可以減少使用者的記憶量。
  • 通過引入配置文件，可以在不修改任何客戶端代碼的情況下更換和增加新的具體產品類，在一定程度上提高了系統的靈活性。

1.9. 簡單工廠模式的缺點

  • 由於工廠類集中了所有產品創建邏輯，一旦不能正常工作，整個系統都要受到影響。
  • 使用簡單工廠模式將會增加系統中類的個數，在一定程序上增加了系統的複雜度和理解難度。
  • 系統擴展困難，一旦添加新產品就不得不修改工廠邏輯，在產品類型較多時，有可能造成工廠邏輯過於復雜，不利於系統的擴展和維護。
  • 簡單工廠模式由於使用了靜態工廠方法，造成工廠角色無法形成基於繼承的等級結構。

1.10. 適用環境

在以下情況下可以使用簡單工廠模式：
  • 工廠類負責創建的對像比較少：由於創建的對象較少，不會造成工廠方法中的業務邏輯太過複雜。
  • 客戶端只知道傳入工廠類的參數，對於如何創建對像不關心：客戶端既不需要關心創建細節，甚至連類名都不需要記住，只需要知道類型所對應的參數。

1.11. 模式應用

  1. JDK類庫中廣泛使用了簡單工廠模式，如工具類java.text.DateFormat，它用於格式化一個本地日期或者時間。
public final static DateFormat getDateInstance ();
public final static DateFormat getDateInstance ( int style );
public final static DateFormat getDateInstance ( int style , Locale
locale );

  1. Java加密技術
獲取不同加密算法的密鑰生成器:
KeyGenerator keyGen = KeyGenerator . getInstance ( "DESede" );

創建密碼器:
Cipher cp = Cipher . getInstance ( "DESede" );


1.12. 總結

  • 創建型模式對類的實例化過程進行了抽象，能夠將對象的創建與對象的使用過程分離。
  • 簡單工廠模式又稱為靜態工廠方法模式，它屬於類創建型模式。在簡單工廠模式中，可以根據參數的不同返回不同類的實例。簡單工廠模式專門定義一個類來負責創建其他類的實例，被創建的實例通常都具有共同的父類。
  • 簡單工廠模式包含三個角色：工廠角色負責實現創建所有實例的內部邏輯；抽象產品角色是所創建的所有對象的父類，負責描述所有實例所共有的公共接口；具體產品角色是創建目標，所有創建的對像都充當這個角色的某個具體類的實例。
  • 簡單工廠模式的要點在於：當你需要什麼，只需要傳入一個正確的參數，就可以獲取你所需要的對象，而無須知道其創建細節。
  • 簡單工廠模式最大的優點在於實現對象的創建和對象的使用分離，將對象的創建交給專門的工廠類負責，但是其最大的缺點在於工廠類不夠靈活，增加新的具體產品需要修改工廠類的判斷邏輯代碼，而且產品較多時，工廠方法代碼將會非常複雜。
  • 簡單工廠模式適用情況包括：工廠類負責創建的對像比較少；客戶端只知道傳入工廠類的參數，對於如何創建對像不關心。


留言

張貼留言

這個網誌中的熱門文章

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