抽象工厂模式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：享元模式