工厂方法模式（Factory Method）

最新推荐文章于 2024-04-19 15:31:43 发布

原创最新推荐文章于 2024-04-19 15:31:43 发布 · 237 阅读

0 ·

CC 4.0 BY-SA版权

PHP设计模式专栏收录该内容

11 篇文章

订阅专栏

本文介绍了工厂方法模式与简单工厂的概念，并通过实例展示了它们在实现数据多文件导出功能中的应用。重点阐述了如何通过抽象工厂和具体工厂的分离，实现对扩展的开放和对修改的封闭，以及如何通过简单工厂解决实际问题，同时强调了软件设计中的开放-封闭原则。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

简单工厂（静态工厂方法）

简单工厂实际上不算一种模式，可以把它叫做一种常用写法。例如我们常用的数据库操作，为了适配不同的数据库引擎，可能分别编写了具体的数据库操作类(当然这些类都实现了统一的接口)：

//统一的操作接口，保证对于外部调用时透明统一的
interface DBInterface
{
	public function connect(Arrat $params=array());
	public function query($sql);
	public function insert($table, $record);
	public function update($table, $record, $where);
	public function delete($table, $where);
}

class MySQL implements DBInterface
{
	//省略具体实现
}

class SqlServer implements DBInterface
{
	//省略具体实现
}

class Sqlite implements DBInterface
{
	//省略具体实现
}

/**
 * 原始的方法每次需要使用数据库的时候都使用if或者switch方法判断配置并实例化需要的数据库操作类
 * 这样代码中就会出现大量重复的代码，那么我们应该将相应的代码迁移到一个统一的类当中，这就是简单工厂了
 */
class DBFactory
{
	//为了调用便利，不需要初始化这个工具类，将方法定义为静态方法
	public static function factory()
	{
		if(GlobalConfig::DBENGINE=='mysql')
		{
			return new MySQL();
		}
		else if(GlobalConfig::DBENGINE=='sqlserver')
		{
			return new SqlServer();
		}
		else if(GlobalConfig::DBENGINE=='sqlite')
		{
			return new Sqlite();
		}
	}
}

//需要使用时
$db = DBFactory::factory();
$db->connect();

简单工厂只是工厂方法模式抽象的一部分，但因为其结构简单而又实用（将复杂的初始化操作封装起来了），在PHP中应用广泛，Zend Framework中随处可见，如Cache、Captcha等。

工厂方法模式

工厂方法模式，是指通过一个类似现实中“工厂”的模式，用来生产我们想要的产品即具体类的实例。通过工厂方法模式，我们先顶一个创建对象的接口（抽象工厂），然后根据具体类）—产品—的实例化推迟到了子类（具体工厂）中实现。那么在我们的项目中如何具体实现呢？

加入我们的茶品需要提供数据导出功能，目前我们提供两种格式的导出：txt和pdf。按照工厂方法模式，我们这样来实现：

/**
 * 抽象工厂
 */
interface ExportFactory
{
	/**
	 * 这里的config用于传入导出的一些需要的特殊配置，与默认配置进行合并，如果是自己在项目框架中使用，除了通过方法传入参数，还可以通过配置文件的方式
	 */
	public function create($config =array());
}

/**
 * txt格式具体工厂
 */
class TxtExportFatory implements ExportFactory
{
	public function create($config = array())
	{
		return new TxtExportHelper($config);
	}
}

/**
 * PDF格式具体工厂
 */
class PDFExportFactory implements ExportFacotry
{
	public function create($config =array())
	{
		return new PDFExportHelper($config);
	}
}

/**
 * 抽象产品
 */
interface  ExportHelper
{
	/**
	 * @param $source 导出数据源
	 */
	public function export($source);
}

/**
 * 具体导出Txt类
 */
class TxtExportHelper implements ExportHelper
{
	private $config;
	
	public function __construct($config=array())
	{
		$defaultConfig = array(
			'maxsize'=>1024*1024*5,
			'rootdir'=>'./export/',
			'prefix'=>'ex_',
			'coding'=>'UTF-8',
			'linechars'=>100
		);
		$this->config = array_merge($defaultConfig, $config);
	}
	
	public function export($source)
	{
		//具体导出逻辑省略
	}
}

/**
 * 具体导出PDF类
 */
class PDFExportHelper implements ExportHelper
{
	private $config;
	
	public function __construct($config=array())
	{
		$defaultConfig = array(
			'maxsize'=>1024*1024*5,
			'rootdir'=>'./export/',
			'prefix'=>'ex_',
			'width'=>1800,
			'height'=>3200,
			'margin'=>200
		);
		$this->config = array_merge($defaultConfig, $config);
	}
	
	public function export($source)
	{
		//具体导出逻辑省略
	}
}

/**
 * Client调用，假定有一个博客文脏月度的COntroller（MCV）
 */
class NovelController
{
	public function actionView($id)
	{
		//HTML页面显示$id内容
	}
	
	public function actionVote($id)
	{
		//给$id内容投票
	}
	
	public function actionExportTxt($id)
	{
		//导出$id的内容
		$source = $this->modle->getDataByPk($id);//假定调用Model提取数据
		$factory = new TxtExportFactory();
		$this->export($factory);//txt方式完全使用默认配置
	}
	
	public function actionExportPdf($id)
	{
        //导出$id的内容
        $source = $this->modle->getDataByPk($id);//假定调用Model提取数据
        $config = array(
            'width' => 1200,
            'height' => 1800,
        );
        $factory = new PdfExportFactory();
        $this->export($factory, $source, $config);
    }

    //将具体的导出处理独立
    private function export(ExportFactory $factory, $source, $config=array())
    {
        $exportHelper = $factory->create($config);
        $exportHelper->export($source); 
    }

    //省略更多方法
}

实际上，上述“工厂方法模式”完全可以通过“简单工厂”去实现，为什么要抽象出“抽象工厂”和“具体工厂”这两个角色呢？很简单，还是为了更好地实现封装，说道这里不得不说软件设计中的一条重要原则：开放-封闭原则。也就是说，我们的设计应该只对扩展开放（可以通过扩展现有结构实现新的功能），而应该对修改封闭（不应该修改已经有的类和设计）。

那么针对我们封装的这个功能：实现数据的多文件格式导出，如果使用“简单工厂”去实现，例如ExportFactory如下：

class ExportFactory{
    pubic static function create($type){
        switch ($type){
            case 'txt':
                return new TxtExportHelper();
            case 'pdf':
                return new PdfExportHelper();
            default:
                throw new Exception('export type not suppert');
        }
    }
}

如果我们现在的业务扩展，需要实现新的格式Word文档的导出，那么，我们不得不修改上述ExportFactory类，增减一条case语句：

case 'word':
    return new WordExportHelper();</span>

这就表示，我们修改了已有的类ExportFactory。随着业务的不断扩展，我们可能还需要经常修改这个类，来增加诸如mobi格式等等的支持。而且，当case分支越来越多，这个ExportFactory将变得越加难于维护。那如果使用“工厂方法模式”来实现呢，我们就只需要新增WordExportFactory和WordExportHelper这两个类，客户端（Clinet）就可以直接使用了。

可能会有人想，那我新增了两个类不算“修改”吗？我再客户端NovelController中增加对Word格式的处理的调用不算修改吗？对于前者，在软件设计中不能成为修改（没有修改已经有的类和设计结构），而是扩展（通过实现ExportFactory和ExportHelper接口扩展已有的功能）。对于后者，的确是修改，但是这种修改是延迟到了客户端（调用者）的，所以对于我们定义的功能“实现数据的多文件格式导出”并没有修改，而这种延迟对于底层设计者和最终调用者都是有好处的