抽象工廠模式php

⑴ 怎樣用php實現編輯完美私服的角色數據

最近學習PHP5介面的過程中遇到了困難 ，書中說是實現多重繼承的一種方式，但我依然不知道具體該如何實現。在網上查PHP介面的資料很少，就查了java的，其實基本上都差不多。看完包裝機《澄清Java（介面與繼承）》這篇文章才恍然大悟，原來包裝機我一開始理解就有誤，所謂的多重繼承是指介面繼承類，而不是類繼承介面。
文章中提到了OO的抽象，正如文章中的那句話——"抽象就是抽去像的部分"，很形象，以前想到抽象總是認為很難理解，抽象嘛，哈哈，現在就很容易理解了，這也正是介面和抽象類所要做的事情。
文章中還有很多觀點也讓我受益匪淺，羅列如下：
OO的精髓，我以為，是對對象的抽象。
介面的作用，一言以蔽之，就是標志類的類別（type of class）。把不同類型的類歸於不同的介面，可以更好的管理他們。
繼承的意義也在於抽象，而不是代碼重用。
看完這篇文章，現在基本上理解介面、抽象類、繼承該如何應用了。

原文如下：
澄清Java（介面與繼承） 計算機學院研二的兄弟與我討論Java，一見面，幾個問題全是關於介面，介面有什麼用？為什麼要用介面？什麼時候該使用介面？很慶幸他們不是問我 Java如何連接SQL Server，或者是如何開發J2EE應用，這類問題有殺傷力，避之則吉。今年計算機學院本科有個畢業設計課題是做J2ME，選這個題目的學生在5月末都還在苦著臉研究java.util.*這個包，這個這個……唉。

大多數人認為，介面的意義在於頂替多重繼承。眾所周知Java沒有c++那樣多重繼承的機制，但是卻能夠實作多個介面。其實這樣做是很牽強的，介面和繼承是完全不同的東西，介面沒有能力代替多重繼承，也沒有這個義務。介面的作用，一言以蔽之，就是標志類的類別（type of class）。把不同類型的類歸於不同的介面，可以更好的管理他們。OO的精髓，我以為，是對對象的抽象，最能體現這一點的就是介面。為什麼我們討論設計模式都只針對具備了抽象能力的語言（比如c++、java、c#等），就是因為設計模式所研究的，實際上就是如何合理的去抽象。（cowboy的名言是「抽象就是抽去像的部分」，看似調侃，實乃至理）。

設計模式中最基礎的是工廠模式（Factory），在我最近的一個很簡單的應用中，我想盡量的讓我的程序能夠在多個資料庫間移植，當然，這涉及很多問題，單是如何兼容不同DBMS的SQL就讓人頭痛。我們不妨先把問題簡單化，只考慮如何連接不同的資料庫。

假設我有很多個類，分別是Mysql.java、SQLServer.java、Oracle.java、 DB2.java，他們分別連接不同的資料庫，統一返回一個Connection對象，並且都有一個close方法，用於關閉連接。只需要針對你的 DBMS，選擇不同的類，就可以用了，但是我的用戶他會使用什麼資料庫？我不知道，我希望的是盡量少的修改代碼，就能滿足他的需要。我可以抽象如下介面：
package org.bromon.test;
public interface DB
{
java.sql.Connection openDB(String url,String user,String password);
void close();
}

這個介面只定義兩個方法，沒有任何有實際意義的代碼，具體的代碼由實作這個介面的類來給出，比如Mysql.java：

Package org.bromon.test;
import java.sql.*;
public class Mysql implements DB
{
private String url=」jdbc:mysql:localhost:3306/test」;
private String user=」root」;
private String password=」」;
private Connection conn;
public Connection openDB(url,user,password)
{
//連接資料庫的代碼
}

public void close()
{
//關閉資料庫
}
}

類似的當然還有Oracle.java等等，介面DB給這些類歸了個類，在應用程序中我們這樣定義對象：

org.bromon.test.DB myDB;

使用myDB來操作資料庫，就可以不用管實際上我所使用的是哪個類，這就是所謂的「開-閉」原則。但是問題在於介面是不能實例化的，myDB= new DB()，這樣的代碼是絕對錯誤的，我們只能myDB=new Mysql()或者myDB=new Oracle()。麻煩了，我還是需要指定具體實例化的是哪個類，用了介面跟沒用一樣。所以我們需要一個工廠：

package org.bromon.test;
public class DBFactory
{
public static DB Connection getConn()
{
Return(new Mysql());
}
}

所以實例化的代碼變成：myDB=DBFactory.getConn()；
這就是23種模式中最基礎的普通工廠 (Factory)，工廠類負責具體實例化哪個類，而其他的程序邏輯都是針對DB這個介面進行操作，這就是「針對介面編程」。責任都被推卸給工廠類了，當然你也可以繼續定義工廠介面，繼續把責任上拋，這就演變成抽象工廠(Abstract Factory)。

整個過程中介面不負責任何具體操作，其他的程序要連接資料庫的話，只需要構造一個DB對象就OK，而不管工廠類如何變化。這就是介面的意義----抽象。

繼承的概念不用多說，很好理解。為什麼要繼承呢？因為你想重用代碼？這絕對不是理由，繼承的意義也在於抽象，而不是代碼重用。如果對象A有一個 run()方法，對象B也想有這個方法，所以有人就Class B extends A。這是不經大腦的做法。如果在B中實例化一個A，調用A的Run()方法，是不是可以達到同樣的目的？如下：
Class B
{
A a=new A();
a.run();
}

這就是利用類的聚合來重用代碼，是委派模式的雛形，是GoF一貫倡導的做法。

那麼繼承的意義何在？其實這是歷史原因造成的，最開始的OO語言只有繼承，沒有介面，所以只能以繼承來實現抽象，請一定注意，繼承的本意在於抽象，而非代碼重用（雖然繼承也有這個作用），這是很多Java爛書最嚴重的錯誤之一，它們所造成的陰影，我至今還沒有完全擺脫，壞書害人啊，尤其是入門類的，流毒太大。什麼時候應該使用繼承？只在抽象類中使用，其他情況下盡量不使用。抽象類也是不能實例化的，它僅僅提供一個模版而已，這就很能說明問題。

軟體開發的萬惡之源，一是重復代碼而不是重用代碼，二是爛用繼承，尤以c++程序員為甚。Java中取締多重繼承，目的就是制止爛用繼承，實是非常明智的做法，不過很多人都不理解。Java能夠更好的體現設計，這是讓我入迷的原因之一

⑵ 什麼是抽象工廠

工廠模式定義:提供創建對象的介面.

為何使用?
工廠模式是我們最常用的模式了,著名的Jive論壇 ,就大量使用了工廠模式，工廠模式在Java程序系統可以說是隨處可見。

為什麼工廠模式是如此常用？因為工廠模式就相當於創建實例對象的new，我們經常要根據類Class生成實例對象，如A a=new A() 工廠模式也是用來創建實例對象的，所以以後new時就要多個心眼，是否可以考慮實用工廠模式，雖然這樣做，可能多做一些工作，但會給你系統帶來更大的可擴展性和盡量少的修改量。

我們以類Sample為例， 如果我們要創建Sample的實例對象:

Sample sample=new Sample();

可是，實際情況是，通常我們都要在創建sample實例時做點初始化的工作,比如賦值 查詢資料庫等。

首先，我們想到的是，可以使用Sample的構造函數，這樣生成實例就寫成:

Sample sample=new Sample(參數);

但是，如果創建sample實例時所做的初始化工作不是象賦值這樣簡單的事，可能是很長一段代碼，如果也寫入構造函數中，那你的代碼很難看了（就需要Refactor重整）。

為什麼說代碼很難看，初學者可能沒有這種感覺，我們分析如下，初始化工作如果是很長一段代碼，說明要做的工作很多，將很多工作裝入一個方法中，相當於將很多雞蛋放在一個籃子里，是很危險的，這也是有背於Java面向對象的原則，面向對象的封裝(Encapsulation)和分派(Delegation)告訴我們，盡量將長的代碼分派「切割」成每段，將每段再「封裝」起來(減少段和段之間偶合聯系性)，這樣，就會將風險分散，以後如果需要修改，只要更改每段，不會再發生牽一動百的事情。

在本例中，首先，我們需要將創建實例的工作與使用實例的工作分開, 也就是說，讓創建實例所需要的大量初始化工作從Sample的構造函數中分離出去。

這時我們就需要Factory工廠模式來生成對象了，不能再用上面簡單new Sample(參數)。還有,如果Sample有個繼承如MySample, 按照面向介面編程,我們需要將Sample抽象成一個介面.現在Sample是介面,有兩個子類MySample 和HisSample .我們要實例化他們時,如下:

Sample mysample=new MySample();
Sample hissample=new HisSample();

隨著項目的深入,Sample可能還會"生出很多兒子出來", 那麼我們要對這些兒子一個個實例化,更糟糕的是,可能還要對以前的代碼進行修改:加入後來生出兒子的實例.這在傳統程序中是無法避免的.

但如果你一開始就有意識使用了工廠模式,這些麻煩就沒有了.

工廠方法
你會建立一個專門生產Sample實例的工廠:

public class Factory{

public static Sample creator(int which){

//getClass 產生Sample 一般可使用動態類裝載裝入類。
if (which==1)
return new SampleA();
else if (which==2)
return new SampleB();

}

}

那麼在你的程序中,如果要實例化Sample時.就使用

Sample sampleA=Factory.creator(1);

這樣,在整個就不涉及到Sample的具體子類,達到封裝效果,也就減少錯誤修改的機會,這個原理可以用很通俗的話來比喻:就是具體事情做得越多,越容易范錯誤.這每個做過具體工作的人都深有體會,相反,官做得越高,說出的話越抽象越籠統,范錯誤可能性就越少.好象我們從編程序中也能悟出人生道理?呵呵.

使用工廠方法 要注意幾個角色，首先你要定義產品介面，如上面的Sample,產品介面下有Sample介面的實現類,如SampleA,其次要有一個factory類，用來生成產品Sample，如下圖，最右邊是生產的對象Sample：

進一步稍微復雜一點，就是在工廠類上進行拓展，工廠類也有繼承它的實現類concreteFactory了。

抽象工廠
工廠模式中有: 工廠方法(Factory Method) 抽象工廠(Abstract Factory).

這兩個模式區別在於需要創建對象的復雜程度上。如果我們創建對象的方法變得復雜了,如上面工廠方法中是創建一個對象Sample,如果我們還有新的產品介面Sample2.

這里假設：Sample有兩個concrete類SampleA和SamleB，而Sample2也有兩個concrete類Sample2A和SampleB2

那麼，我們就將上例中Factory變成抽象類,將共同部分封裝在抽象類中,不同部分使用子類實現，下面就是將上例中的Factory拓展成抽象工廠:

public abstract class Factory{

public abstract Sample creator();

public abstract Sample2 creator(String name);

}

public class SimpleFactory extends Factory{

public Sample creator(){
.........
return new SampleA
}

public Sample2 creator(String name){
.........
return new Sample2A
}

}

public class BombFactory extends Factory{

public Sample creator(){
......
return new SampleB
}

public Sample2 creator(String name){
......
return new Sample2B
}

}

從上面看到兩個工廠各自生產出一套Sample和Sample2,也許你會疑問，為什麼我不可以使用兩個工廠方法來分別生產Sample和Sample2?

抽象工廠還有另外一個關鍵要點，是因為 SimpleFactory內，生產Sample和生產Sample2的方法之間有一定聯系，所以才要將這兩個方法捆綁在一個類中，這個工廠類有其本身特徵，也許製造過程是統一的，比如：製造工藝比較簡單，所以名稱叫SimpleFactory。

在實際應用中，工廠方法用得比較多一些，而且是和動態類裝入器組合在一起應用，

舉例

我們以Jive的ForumFactory為例，這個例子在前面的Singleton模式中我們討論過，現在再討論其工廠模式:

public abstract class ForumFactory {

private static Object initLock = new Object();
private static String className = "com.jivesoftware.forum.database.DbForumFactory";
private static ForumFactory factory = null;

public static ForumFactory getInstance(Authorization authorization) {
//If no valid authorization passed in, return null.
if (authorization == null) {
return null;
}
//以下使用了Singleton 單態模式
if (factory == null) {
synchronized(initLock) {
if (factory == null) {
......

try {
//動態轉載類
Class c = Class.forName(className);
factory = (ForumFactory)c.newInstance();
}
catch (Exception e) {
return null;
}
}
}
}

//Now, 返回 proxy.用來限制授權對forum的訪問
return new ForumFactoryProxy(authorization, factory,
factory.getPermissions(authorization));
}

//真正創建forum的方法由繼承forumfactory的子類去完成.
public abstract Forum createForum(String name, String description)
throws UnauthorizedException, ForumAlreadyExistsException;

....

}

因為現在的Jive是通過資料庫系統存放論壇帖子等內容數據,如果希望更改為通過文件系統實現,這個工廠方法ForumFactory就提供了提供動態介面:

private static String className = "com.jivesoftware.forum.database.DbForumFactory";

你可以使用自己開發的創建forum的方法代替com.jivesoftware.forum.database.DbForumFactory就可以.

在上面的一段代碼中一共用了三種模式,除了工廠模式外,還有Singleton單態模式,以及proxy模式,proxy模式主要用來授權用戶對forum的訪問,因為訪問forum有兩種人:一個是注冊用戶 一個是遊客guest,那麼那麼相應的許可權就不一樣,而且這個許可權是貫穿整個系統的,因此建立一個proxy,類似網關的概念,可以很好的達到這個效果.

看看Java寵物店中的CatalogDAOFactory:

public class CatalogDAOFactory {

/**

* 本方法制定一個特別的子類來實現DAO模式。
* 具體子類定義是在J2EE的部署描述器中。
*/

public static CatalogDAO getDAO() throws CatalogDAOSysException {

CatalogDAO catDao = null;

try {

InitialContext ic = new InitialContext();
//動態裝入CATALOG_DAO_CLASS
//可以定義自己的CATALOG_DAO_CLASS，從而在無需變更太多代碼
//的前提下，完成系統的巨大變更。

String className =(String) ic.lookup(JNDINames.CATALOG_DAO_CLASS);

catDao = (CatalogDAO) Class.forName(className).newInstance();

} catch (NamingException ne) {

throw new CatalogDAOSysException("
CatalogDAOFactory.getDAO: NamingException while
getting DAO type : \n" + ne.getMessage());

} catch (Exception se) {

throw new CatalogDAOSysException("
CatalogDAOFactory.getDAO: Exception while getting
DAO type : \n" + se.getMessage());

}

return catDao;

}

}

CatalogDAOFactory是典型的工廠方法，catDao是通過動態類裝入器className獲得CatalogDAOFactory具體實現子類，這個實現子類在Java寵物店是用來操作catalog資料庫，用戶可以根據資料庫的類型不同，定製自己的具體實現子類，將自己的子類名給與CATALOG_DAO_CLASS變數就可以。

由此可見，工廠方法確實為系統結構提供了非常靈活強大的動態擴展機制，只要我們更換一下具體的工廠方法，系統其他地方無需一點變換，就有可能將系統功能進行改頭換面的變化。

設計模式如何在具體項目中應用見《Java實用系統開發指南》

文章地址:
http://www.jdon.com/designpatterns/designpattern_factory.htm
http://zh.wikipedia.org/wiki/%E6%8A%BD%E8%B1%A1%E5%B7%A5%E5%8E%82%E6%A8%A1%E5%BC%8F
http://www.cnblogs.com/yuyijq/archive/2007/10/06/915185.html

⑶ 工廠模式,簡單工廠模式,抽象工廠模式三者有什麼區別

工廠模式、簡單工廠模式、抽象工廠模式三者的區別：

1、創建對象不同。創建對象時，「工廠模式」使用Factory模式替代使用new創建對象；「簡單工廠模式」使用fw模式建立對象；「抽象工廠模式」則使用迭代模式創建對象。

(3)抽象工廠模式php擴展閱讀

編程使用「工廠模式」的優缺點：

1、優點：

方便擴展演算法，比如增加一個開根號的功能，我們只要繼續繼承運算類就行了，同時客戶端也就是使用者不知道具體的實現細節，只要給出相關標示符，工廠函數就馬上給他創建一個他想要的實體就行了。減少了使用者和功能開發者之間的耦合度。

2、缺點：

在進行擴展的時候，我們要更改工廠函數裡面的那個分支語句Switch，這樣便破壞了OCP，而且當有多級結構繼承的時候，簡單工廠就會因為只能對應平行一層記得繼承，不得不使得好多類繼承同一個介面，然後得到A*B這么多的工廠實體可能，工廠函數很難維護。

⑷ 設計模式（二）：簡單工廠，工廠和抽象工廠的區別

首先來看看這兩者的定義區別：工廠模式：定義一個用於創建對象的借口，讓子類決定實例化哪一個類抽象工廠模式：為創建一組相關或相互依賴的對象提供一個介面，而且無需指定他們的具體類個人覺得這個區別在於產品，如果產品單一，最合適用工廠模式，但是如果有多個業務品種、業務分類時，通過抽象工廠模式產生需要的對象是一種非常好的解決方式。再通俗深化理解下：工廠模式針對的是一個產品等級結構 ，抽象工廠模式針對的是面向多個產品等級結構的。再來看看工廠方法模式與抽象工廠模式對比：

⑸ PHP中幾種常見的開發模式

單例模式

• $_instance必須聲明為靜態的私有變數

• 構造函數和析構函數必須聲明為私有,防止外部程序new 類從而失去單例模式的意義

• getInstance()方法必須設置為公有的,必須調用此方法 以返回實例的一個引用

• ::操作符只能訪問靜態變數和靜態函數

• new對象都會消耗內存

• 使用場景:最常用的地方是資料庫連接。

• 使用單例模式生成一個對象後， 該對象可以被其它眾多對象所使用。

• 私有的__clone()方法防止克隆對象

單例模式，使某個類的對象僅允許創建一個。構造函數private修飾，
申明一個static getInstance方法，在該方法里創建該對象的實例。如果該實例已經存在，則不創建。比如只需要創建一個資料庫連接。

工廠模式

工廠模式，工廠方法或者類生成對象，而不是在代碼中直接new。
使用工廠模式，可以避免當改變某個類的名字或者方法之後，在調用這個類的所有的代碼中都修改它的名字或者參數。

• * 如果某個類在很多的文件中都new ClassName()，那麼萬一這個類的名字


• * 發生變更或者參數發生變化，如果不使用工廠模式，就需要修改每一個PHP


• * 代碼，使用了工廠模式之後，只需要修改工廠類或者方法就可以了。



注冊模式

注冊模式，解決全局共享和交換對象。已經創建好的對象，掛在到某個全局可以使用的數組上，在需要使用的時候，直接從該數組上獲取即可。將對象注冊到全局的樹上。任何地方直接去訪問。

• 
  

策略模式

策略模式，將一組特定的行為和演算法封裝成類，以適應某些特定的上下文環境。
eg：假如有一個電商網站系統，針對男性女性用戶要各自跳轉到不同的商品類目，並且所有的廣告位展示不同的廣告。在傳統的代碼中，都是在系統中加入各種if else的判斷，硬編碼的方式。如果有一天增加了一種用戶，就需要改寫代碼。使用策略模式，如果新增加一種用戶類型，只需要增加一種策略就可以。其他所有的地方只需要使用不同的策略就可以。
首先聲明策略的介面文件，約定了策略的包含的行為。然後，定義各個具體的策略實現類。

執行結果圖：

總結：
通過以上方式，可以發現，在不同用戶登錄時顯示不同的內容，但是解決了在顯示時的硬編碼的問題。如果要增加一種策略，只需要增加一種策略實現類，然後在入口文件中執行判斷，傳入這個類即可。實現了解耦。
實現依賴倒置和控制反轉（有待理解）
通過介面的方式，使得類和類之間不直接依賴。在使用該類的時候，才動態的傳入該介面的一個實現類。如果要替換某個類，只需要提供一個實現了該介面的實現類，通過修改一行代碼即可完成替換。

觀察者模式

1：觀察者模式(Observer)，當一個對象狀態發生變化時，依賴它的對象全部會收到通知，並自動更新。
2：場景:一個事件發生後，要執行一連串更新操作。傳統的編程方式，就是在事件的代碼之後直接加入處理的邏輯。當更新的邏輯增多之後，代碼會變得難以維護。這種方式是耦合的，侵入式的，增加新的邏輯需要修改事件的主體代碼。
3：觀察者模式實現了低耦合，非侵入式的通知與更新機制。
定義一個事件觸發抽象類。

當某個事件發生後，需要執行的邏輯增多時，可以以松耦合的方式去增刪邏輯。也就是代碼中的紅色部分，只需要定義一個實現了觀察者介面的類，實現復雜的邏輯，然後在紅色的部分加上一行代碼即可。這樣實現了低耦合。

裝飾器模式

1：裝飾器模式，可以動態的添加修改類的功能
2：一個類提供了一項功能，如果要在修改並添加額外的功能，傳統的編程模式，需要寫一個子類繼承它，並重寫實現類的方法
3：使用裝飾器模式，僅需要在運行時添加一個裝飾器對象即可實現，可以實現最大額靈活性。

⑹ 軟體開發中的抽象工廠模式是什麼呢

抽象工廠模式（Abstract Factory Pattern）隸屬於設計模式中的創建型模式，用於產品族的構建。抽象工廠是所有形態的工廠模式中最為抽象和最具一般性的一種形態。抽象工廠是指當有多個抽象角色時使用的一種工廠模式。抽象工廠模式可以向客戶端提供一個介面，使客戶端在不必指定產品的具體情況下，創建多個產品族中的產品對象。
工廠模式中的每一個形態都是針對一定問題的解決方案，工廠方法針對的是多個產品系列結構；而抽象工廠模式針對的是多個產品族結構，一個產品族內有多個產品系列。
抽象工廠模式相對於工廠方法模式來說，就是工廠方法模式是針對一個產品系列的，而抽象工廠模式是針對多個產品系列的，即工廠方法模式是一個產品系列一個工廠類，而抽象工廠模式是多個產品系列一個工廠類。在抽象工廠模式中，客戶端不再負責對象的創建，而是把這個責任丟給了具體的工廠類，客戶端只負責對對象的調用，從而明確了各個類的職責。並且當一系列相互關聯的產品被設計到一個工廠類里後，客戶端的調用將會變得非常簡單，而且，如果要更換這一系列的產品，則只需要更換一個工廠類即可。

⑺ 在抽象工廠模式中怎樣使用memcached緩存數據

一、Memcached簡介
memcached 常被用來加速應用程序的處理，在這里，我們將著重於介紹將它部署於應用程序和環境中的最佳實踐。這包括應該存儲或不應存儲哪些、如何處理數據的靈活分布以 及如何調節用來更新 memcached 和所存儲數據的方法。我們還將介紹對高可用性的解決方案的支持，比如 IBM WebSphere® eXtreme Scale。
所有的應用程序，特別是很多 web 應用程序都需要優化它們訪問客戶機和將信息返回至客戶機的速度。可是，通常，返回的都是相同的信息。從數據源（資料庫或文件系統）載入數據十分低效，若是每次想要訪問該信息時都運行相同的查詢，就尤顯低效。
雖然很多 web 伺服器都可被配置成使用緩存發回信息，但那與大多數應用程序的動態特性無法相適。而這正是 memcached 的用武之地。它提供了一個通用的內存存儲器，可保存任何東西，包括本地語言的對象，這就讓您可以存儲各種各樣的信息並可以從諸多的應用程序和環境訪問這些信息。
二、基礎知識
memcached 是一個開源項目，旨在利用多個伺服器內的多餘 RAM 來充當一個可存放經常被訪問信息的內存緩存。這里的關鍵是使用了術語緩存：memcached 為載入自他處的信息提供的是內存中的暫時存儲。
比如，考慮這樣一個典型的基於 web 的應用程序。即便是一個動態網站可能也會有一些組件或信息常量是貫穿頁面整個生命周期的。在一個博客站點內，針對單個 blog post 的類別列表不大可能在頁面查看間經常性地變更。每次都通過一個對資料庫的查詢載入此信息相對比較昂貴，特別是在數據沒有更改的情況下，就更是如此。從圖 1 可以看到一個博客站點內可被緩存的頁面分區。
圖1.一個典型的博客頁面內的可緩存元素

將這種結構放在 blog 站點的其他元素，poster 信息、注釋 — 設置 blog post 本身 — 進行推斷，可以看出為了顯示主頁的內容很可能需要發生 10-20 次資料庫查詢和格式化。 每天對數百甚至數千的的頁面查看重復此過程，那麼您的伺服器和應用程序執行的查詢要遠遠多於為了顯示頁面內容所需執行的查詢。
通過使用 memcached，可以將載入自資料庫的格式化信息存儲為一種可直接用在 Web 頁面上的格式。並且由於信息是從 RAM 而不是通過資料庫和其他處理從磁碟載入的，所以對信息的訪問幾乎是瞬時的。
再強調一下，memcached 是一個用來存儲常用信息的緩存，有了它，您便無需從緩慢的資源，比如磁碟或資料庫，載入並處理信息了。
對 memcached 的介面是通過網路連接提供的。這意味著您可以在多個客戶機間共享單個的 memcached 伺服器（或多個伺服器，如本文稍後所示的）。這個網路介面非常迅速，並且為了改善性能，伺服器會故意不支持身份驗證或安全性通信。但這不應限制部署選項。 memcached 伺服器應該存在於您網路的內部。網路介面的實用性以及可以部署多個 memcached 實例的簡便性讓您可以使用多個機器上的多餘 RAM 來提高您緩存的整體大小。
三、存儲方法
memcached 的存儲方法是一個簡單的鍵/值對，類似於很多語言內的散列或關聯數組。通過提供鍵和值來將信息存儲到 memcached 內，通過按特定的鍵請求信息來恢復信息。
信息會無限期地保留在緩存內，除非發生如下的情況：
為緩存分配的內存耗盡 — 在這種情況下，memcached 使用 LRU（最近最少使用）方法從此緩存刪除條目。最近未曾使用的條目會從此緩存中先刪除，最舊的最先訪問。
條目被明確刪除 — 總是可以從此緩存內刪除條目。
條目過期失效 — 各條目均有一個有效的期限以便針對此鍵存儲的信息在過於陳舊時可從緩存中清除這些條目。
上述這些情況可以與您應用程序的邏輯綜合使用以便確保緩存內的信息是最新的。有了這些基礎知識後，讓我們來看看在應用程序內如何能最好地利用 memcached。
四、何時使用memcached？
在使用 memcached 改進應用程序性能時，可以對一些關鍵的過程和步驟進行修改。
在載入信息時，典型的場景如圖 2 所示。
圖2.載入要顯示的信息的典型順序

一般而言，這些步驟是：
執行一個或多個查詢來從資料庫載入信息
格式化適合於顯示（或進一步處理）的信息
使用或顯示格式化了的數據
在使用 memcached 時，為配合這個緩存，可對應用程序的邏輯進行稍許修改：
盡量從緩存載入信息
如果存在，使用信息的被緩存版本
如果它不存在：
執行一個或多個查詢來從資料庫載入信息
格式化適合於顯示或進一步處理的信息
將信息存儲到緩存內
使用格式化了的數據
圖 3 是對這些步驟的總結。
圖3.在使用memcached時載入適合於顯示的信息

數據載入成為了至多三個步驟的一個過程，從緩存載入數據或從資料庫（視情況而定）載入數據並存儲在緩存內。
當這個過程首次發生時，數據將正常地從資料庫或其他數據源載入，然後再存儲到 memcached 內。當下一次訪問此信息時，它就會從 memcached 拉出，而不是從資料庫載入，節省了時間和 CPU 循環。
問題的另一個方面是要確保如果更改了要存儲在 memcached 內的信息，在更新後端信息的同時還要更新 memcached 的版本。這會讓圖 4 內所示的這個典型順序發生稍許變化，如 圖 5 所示。
圖4.在一個典型的應用程序內更新或存儲數據

圖 5 顯示了使用 memcached 後發生了變化的流程。
圖5.在使用memcached時更新或存儲數據

比如，仍以博客站點為例，在博客系統更新資料庫內的類別列表時，更新應該遵循如下順序：
更新資料庫內的類別列表
格式化信息
將信息存儲到 memcached 內
將信息返回至客戶機
memcached 內的存儲操作是原子的，所以信息的更新不會讓客戶機只獲得部分數據；它們獲得的或者是老版本，或者是新版本。
對於大多數應用程序，這兩個操作是您惟一需要注意的。在訪問他人使用的數據時，它會自動被添加到這個緩存內，而且如果對該數據進行了更改，此緩存內也會自動進行更新。
五、鍵、名稱空間和值
memcached 另一個需要重點考慮的因素是如何組織和命名存儲在緩存內的這些數據。從之前博客站點的例子中，不難看出需要使用一種一致的命名結構以便您能載入博客類別、歷史和其他信息，然後再在載入信息（並更新緩存）時或者在更新數據（同樣也要更新緩存）時使用。
使用的何種具體的命名系統特定於應用程序，但通常可以使用一種與現有應用程序類似的結構，並且這種結構很可能基於某種惟一識別符。當從資料庫拉出信息或在整理信息集時，就會發生這種情況。
以 blog post 為例，可以在一個具有鍵 category-list 的項中存儲類別列表。與此 post ID 對應的單個 post，比如 blogpost-29 相關的值都可以使用，而該項的注釋則可以存儲在 blogcomments-29內，其中 29 就是這個 blog post 的 ID。這樣一來， 您就可以將各種各樣的信息存儲在緩存內，使用不同的前綴來標識這些信息。
memcached 鍵/值存儲的簡便性（以及安全性的缺乏）意味著如果您想要在使用同一個 memcached 伺服器的同時支持多個應用程序，那麼就可以考慮使用其他格式的量詞來標識數據屬於某種特定的應用程序。比如，可以添加像 blogapp:blogpost-29 這樣的應用程序前綴。這些鍵是沒有格式的，所以可以使用任何字元串作為鍵的名稱。
在存儲值的方面，應該確保存儲在緩存內的信息適合於您的應用程序。比如，對於這個博客系統，您可能想要存儲被博客應用程序使用的對象以便格式化博客信息，而不是原始的 HTML。如果同一個基礎結構用在應用程序內的多個地方，這一點更具實用性。
大多數語言的介面，包括 Java™、Perl、PHP 等，都能串列化語言對象以便存儲在 memcached 內。這就讓您可以存儲並隨後從內存存儲恢復全部對象，而不是在您的應用程序內手動重構它們。 很多對象，或它們使用的結構，都基於某種散列或數組結構。對於跨語言的環境，比如在 JSP 環境和 JavaScript 環境間共享相同信息，可以使用一種架構中立的格式，比如 JavaScript Object Notation (JSON) 甚或 XML。
六、填充並使用memcached
作為一種開源產品以及一種最初開發用來工作於現有開源環境內的產品，memcached 受大量環境和平台支持。與 memcached 伺服器通信的介面有很多，並常常具有針對所有語言的多個實現。參見參考資料 以獲得常用的庫和工具箱。
要列出所有受支持的介面和環境不太可能，但它們均支持 memcached 協議提供的基礎 API。這些描述已經被簡化並應用在不同語言的上下文內，在這些語言中，使用不同的值可指示錯誤。主要的函數有：
get(key) — 從存儲了特定鍵的 memcached 獲得信息。 如果鍵不存在，就返回錯誤。
set(key, value [, expiry]) — 使用緩存內的標識符鍵存儲這個特定的值。如果鍵已經存在，那麼它就會被更新。期滿時間的單位為秒，並且如果值小於 30 天 (30*24*60*60)，那麼就用作相對時間，如果值大於 30 天，那麼就用作絕對時間 (epoch)。
add(key, value [, expiry]) — 如果鍵不存在就將這個鍵添加到緩存內，如果鍵已經存在就返回錯誤。如果您想要顯式地添加一個新鍵而又不會因它已經存在而更新它，那麼這個函數將十分有用。
replace(key, value [, expiry]) — 更新此特定鍵的值，如果鍵不存在就返回一個錯誤。
delete(key [, time]) — 從緩存中刪除此鍵/值對。如果您提供一個時間，那麼添加具有此鍵的一個新值就會被阻塞這個特定的時期。超時讓您可以確保此值總是可以重新讀取自您的數據中心。
incr(key [, value]) — 為特定的鍵增 1 或特定的值。只適用於數值。
decr(key [, value]) — 為特定的鍵減 1 或特定的值，只適用於數值。
flush_all — 讓緩存內的所有當前條目無效（或到期失效）。
比如，在 Perl 內，基本 set 操作可以如清單 1 所示的那樣處理。

清單 1. Perl 內的基本 set 操作

use Cache::Memcached;

my $cache = new Cache::Memcached {
'servers' => [
'localhost:11211',
],
};

$cache->set('mykey', 'myvalue');

Ruby 內的相同的基本操作如清單 2 所示。

清單 2. Ruby 內的基本 set 操作

require 'memcache'
memc = MemCache::new '192.168.0.100:11211'

memc["mykey"] = "myvalue"

在兩個例子中可以看到相同的基本結構：設置 memcached 伺服器，然後分配或設置值。其他的介面也可用，包括適合於 Java 技術的那些介面，讓您可以在 WebSphere 應用程序內使用 memcached。memcached 介面類允許將 Java 對象直接序列化到 memcached 以便於存儲和載入復雜的結構。當在像 WebSphere 這樣的環境內進行部署時，有兩個事情非常重要：服務的彈性（在 memcached 不可用時如何做）以及如何提高緩存存儲量來改進在使用多個應用程序伺服器或在使用像 WebSphere eXtreme Scale 這樣的環境時的性能。我們接下來就來看看這兩個問題。
七、彈性和可用性
有關 memcached 最常見的一個問題是：「若緩存不可用了，會發生什麼情況呢？」正如之前章節中明示的，緩存內的信息不應該成為信息的的惟一資源。必須要能夠從其他位置載入存儲在緩存內的數據。
雖然，無法從緩存訪問信息將會減緩應用程序的性能，但它不應該阻止應用程序的運轉。可能會發生這樣幾個場景：
如果 memcached 服務宕掉，應用程序應該回退到從原始數據源載入信息並對信息進行顯示所需的格式化。此應用程序還應繼續嘗試在 memcached 內載入和存儲信息。
一旦 memcached 伺服器恢復可用，應用程序就應該自動嘗試存儲數據。沒有必要強制重載已緩存了的數據，可以使用標準的訪問來用信息載入和填充緩存。最終，緩存將會被最常用的數據重新填充。
再次重申，memcached 是信息的緩存但並非惟一的數據源。memcached 伺服器不可用不應該是應用程序的終結，雖然這意味著在 memcached 伺服器恢復正常之前性能會有所降低。實際上，memcached 伺服器相對簡單，並且雖然不是絕對無故障的，但它的簡單性的結果就是它很少會出錯。
八、分配緩存
memcached 伺服器只是網路上針對一些鍵存儲值的一個緩存。如果有多台機器，那麼很自然地會想要在所有多餘機器上設置一個 memcached 的實例來提供一個超大的聯網 RAM 緩存存儲。
有了這個想法後，還有一種想當然是需要使用某種分配或復制機制來在機器之間復制鍵/值對。這種方式的問題是如果這么做反而會減少可用的 RAM 緩存，而不是增加。如圖 6 所示，可以看出這里有三個應用程序伺服器，每個伺服器都可以訪問一個 memcached 實例。
圖6.多重memcached實例的不正確使用

盡管每個 memcached 實例都是 1 GB 的大小（產生 3 GB 的 RAM 緩存），但如果每個應用程序伺服器只有其自己的緩存（或者在 memcached 之間存在著數據的復制），那麼整個安裝也仍只能有 1 GB 的緩存在每個實例間復制。
由於 memcached 通過一個網路介面提供信息，因此單個的客戶機可以從它所能訪問的任何一個 memcached 實例訪問數據。如果數據沒有跨每個實例被復制，那麼最終在每個應用程序伺服器上，就可以有 3 GB 的 RAM 緩存可用，如圖 7 所示。
圖7.多重memcached實例的正確使用

這個方法的問題是選擇哪個伺服器來儲存鍵/值對，以及當想要重新獲得一個值時，如何決定要與哪個 memcached 伺服器對話。問題的解決方案就是忽略復雜的東西，比如查找表，或是寄望 memcached 伺服器來為您處理這個過程。而 memcached 客戶機則必須要力求簡單。
memcached 客戶機不必決定此信息，它只需對在存儲信息時指定的鍵使用一個簡單的散列演算法。當想要從一列 memcached 伺服器存儲或獲取信息時，memcached 客戶機就會用一個一致的散列演算法從這個鍵獲取一個數值。舉個例子，鍵 mykey 被轉換成數值 23875 。是保存還是獲取信息無關緊要，這個鍵將總是被用作惟一標識符來從 memcached 伺服器載入，因此在本例中，「mykey」 散列轉化後對應的值總是 23875。
如果有兩個伺服器，那麼 memcached 客戶機將對這個數值進行一個簡單的運算（例如，系數）來決定它應將此值存儲在第一個還是第二個配置了的 memcached 實例上。
當存儲一個值時，客戶機會從這個鍵確定出散列值以及它原來存儲在哪個伺服器上。當獲取一個值時，客戶機會從這個鍵確定出相同的散列值並會選擇相同的伺服器來獲取信息。
如果在每個應用程序伺服器上使用的是相同的伺服器列表（並且順序相同），那麼當需要保存或檢索同一個鍵時，每個應用程序伺服器都將選擇同一個 伺服器。現在，在這個例子中，有 3GB 的 memcached 空間可以共享，而不是同一個 1 GB 的空間的復制，這就帶來了更多的可用緩存，並很有可能會提高有多個用戶情況下的應用程序的性能。
九、如何能不使用memcached？
盡管 memcached 很簡單，但 memcached 實例有時候還是會被不正確地使用。
memcached不是一個資料庫
最常見的 memcached 誤用就是把它用作一個數據存儲，而不是一個緩存。memcached 的首要目的就是加快數據的響應時間，否則數據從其他數據源構建或恢復需要很長時間。一個典型的例子就是從一個資料庫中恢復信息，特別是在信息顯示給用戶前 需要對信息進行格式化或處理的時候。Memcached 被設計用來將信息存儲在內存中以避免每次在數據需要恢復時重復執行相同的任務。
切不可將 memcached 用作運行應用程序所需信息的惟一信息源；數據應總是可以從其他信息源獲取。此外，要記住 memcached 只是一個鍵/值的存儲。不能在數據上執行查詢，或者對內容進行迭代來提取信息。應該使用它來存儲數據塊或對象以備批量使用。
不要緩存資料庫行或文件
雖然可以使用 memcached 存儲載入自資料庫的數據行，但這實際上是查詢緩存，並且大多數資料庫都提供各自的查詢緩存的機制。其他的對象，比如文件系統的圖像或文件的情況與此相同。很多應用程序和 web 伺服器針對此類工作已經有了一些很好的解決方案。
如果在載入和格式化後，使用它來存儲全部信息塊，就可以從 memcached 獲得更多的實用工具和性能上的改善。仍以我們的博客站點為例，存儲信息的最佳點是在將博客類別格式化為對象，甚至是在格式化成 HTML 後。博客頁面的構造可通過從 memcached 載入各個組件（比如 blog post、category list、post history 等）並將完成的 HTML 寫回至客戶機實現。
memcached並不安全
為了確保最佳性能，memcached 並未提供任何形式的安全性，沒有身份驗證，也沒有加密。這意味著對 memcached 伺服器的訪問應該這么處理：一是通過將它們放到應用程序部署環境相同的私有側，二是如果安全性是必須的，那麼就使用 UNIX® socket 並只允許當前主機上的應用程序訪問此 memcached 伺服器。
這多少犧牲了一些靈活性和彈性，以及跨網路上的多台機器共享 RAM 緩存的能力，但這是在目前的情況下確保 memcached 數據安全性的惟一一種解決方案。
十、不要限制自己
除了不應該使用 memcached 實例的情況外，memcached 的靈活性不應忽視。由於 memcached 與應用程序處於相同的架構水平，所以很容易集成並連接到它。並且更改應用程序以便利用 memcached 也並不復雜。此外，由於 memcached 只是一個緩存，所以在出現問題時它不會停止應用程序的執行。如果使用正確的話，它所做的是減輕其餘伺服器基礎設施的負載（減少對資料庫和數據源的讀操 作），這意味著無需更多的硬體就可以支持更多的客戶機。
但請記住，它僅僅是個緩存！
結束語
在本文中，我們了解了 memcached 以及如何最佳地使用它。我們看到了信息如何存儲、如何選擇合理的鍵以及如何選擇要存儲的信息。我們還討論了所有 memcached 用戶都要遇到的一些關鍵的部署問題，包括多伺服器的使用、當 memcached 實例消亡時該怎麼做，以及（也許最為重要的）在哪些情況下不能使用 memcached。
作為一種開源的應用程序並且是目的簡單而直白的應用程序，memcached 的功能和實用性均來自於這種簡單性。通過為信息提供巨大的 RAM 存儲空間、讓它在網路上可用，然後再讓它可通過各種不同的介面和語言訪問到，memcached 可被集成到多種多樣的安裝和環境中。

⑻ 你熟悉的設計模式有哪些寫出單例模式的實現代碼

23個設計模式：

根據目的設計模式可以分為創造模式，結構模式和行為模式，創建模式用於處理對象的創建。結構模式用於處理類或對象的組合。

行為模式用於描述類或對象如何交互以及如何分配職責，創建模式用於處理對象的創建。主要包括以下五種設計模式：

工廠方法模式（）

抽象工廠模式（AbstractFactoryPattern）

建造者模式（BuilderPattern）

原型模式（PrototypePattern）

單例模式（SingletonPattern）

結構模式用於處理類或對象的組合，包括以下七個設計模式：

適配器模式（AdapterPattern）

橋接模式（BridgePattern）

組合模式（CompositePattern）

裝飾者模式（DecoratorPattern）

外觀模式（FacadePattern）

享元模式（FlyweightPattern）

代理模式（ProxyPattern）

行為模式描述類或對象如何交互以及它們如何分配職責。它由以下11種設計模式組成：

責任鏈模式（Chain的ResponsibilityPattern）

命令模式（CommandPattern）

解釋器模式（InterpreterPattern）

迭代器模式（IteratorPattern）

中介者模式（MediatorPattern）

備忘錄模式（MementoPattern）

觀察者模式（ObserverPattern）

狀態模式（StatePattern）

策略模式（StrategyPattern）

模板方法模式（TemplateMethodPattern）

訪問者模式（VisitorPattern）

單例模式實現1：

公共類Singleton｛

類共享實例對象

私有靜態單例；單例＝零；

／／私有構造函數

私有Singleton（）｛

系統。出去了。這是單例！！）；

｝

／／獲取單例方法

公共同步靜態單例getInstance（）｛

／／確定共享對象是否為空，如何空一個新對象

If（singleton＝＝null）｛

singleton＝newsingleton（）；

｝

返回單例。

｝

｝

單例模式實現2：

公共類Singleton｛

類共享實例對象實例化

＝newSingleton（）；

／／私有構造函數

私有Singleton（）｛

系統：出去了，這是單例！！）；

｝

／／獲取單例方法

公共靜態單例getInstance（）｛

直接返回共享對象

返回單例。

｝

｝

(8)抽象工廠模式php擴展閱讀：

注意事項：

設計模式主要分三個類型：創建型和行為型。

Singleton：確保一個類只有一個實例，並為其提供一個全局訪問點

AbstractFactory：提供一個介面，用於創建一系列相關或相互依賴的對象，而無需指定它們的具體類。

FactoryMethod：定義一個用於創建對象的介面，並讓子類決定實例化哪個類。工廠方法將類的實例化延遲到子類。

Builder：將復雜對象的構造與其表示分離，使相同的構造過程可以創建不同的表示。

Prototype：指定要使用Prototype實例創建的對象的類型，並復制該原型來創建一個新對象。

Composite：將對象組合成樹狀結構，以表示整體各部分之間的關系。組合使用戶一致地使用單個對象和組合對象。

Facade：為子系統fa中的一組介面提供一致的介面。Ade提供了一個高級介面，使子系統更易於使用。

Proxy：為其他對象提供一個代理，以控制對該對象的訪問

Adapter：將一個介面類轉換為客戶想要的另一個介面類。適配器模式使那些由於介面不兼容而無法一起工作的類一起工作。

Decrator：式比子類化更靈活，可以為對象動態添加一些額外的職責。

Bridge：模式將抽象部分與其實現部分分離，以便它們可以獨立地更改。

Flyweight：享元模式