抽象工厂模式在PHP中适合封装成套出现、相互依赖的对象，如RedisCache+RedisLock、AlipayClient+AlipayNotifyHandler、PdoQueryBuilder+PdoConnection；核心是定义抽象接口与具体工厂类，确保对象族一致性，避免混搭与状态不一致。
抽象工厂模式在PHP中适合封装哪些对象？
当项目里存在多组「成套出现、相互依赖」的对象时，抽象工厂才真正有用。比如：不同环境下的缓存驱动（RedisCache + RedisLock）、不同支付网关的客户端与回调处理器（AlipayClient + AlipayNotifyHandler）、或不同数据库的查询构建器与连接器（PdoQueryBuilder + PdoConnection）。如果只是单个类要复用，用工厂方法或依赖注入就够了，硬套抽象工厂反而增加复杂度。
怎么写一个最小可行的抽象工厂？
核心是定义两个层级：抽象接口 + 具体工厂类。不推荐直接 new 实例，也不该把配置逻辑塞进工厂内部。
- 先定义一组接口，比如
CacheInterface和LockInterface，明确它们的契约 - 再写具体实现，如
RedisCache和RedisLock，确保它们能协同工作 - 最后实现抽象工厂接口
CacheFactoryInterface，并提供具体工厂如RedisCacheFactory - 工厂类本身不持有状态，只负责返回一对匹配的实例；构造参数应仅限必要依赖（如
$redisClient），而非一堆配置数组
示例关键结构：
interface CacheFactoryInterface
{
public function createCache(): CacheInterface;
public function createLock(): LockInterface;
}
class RedisCacheFactory implements CacheFactoryInterface
{
private RedisClient $client;
public function __construct(RedisClient $client)
{
$this->client = $client;
}
public function createCache(): CacheInterface
{
return new RedisCache($this->client);
}
public function createLock(): LockInterface
{
return new RedisLock($this->client);
}
}
为什么抽象工厂容易被误用？
常见踩坑点集中在三处：
立即学习“PHP免费学习笔记（深入）”；
- 把「只是名字相似」的类强行归为一族，比如把
Logger和Mailer塞进同一个工厂——它们没有协作关系，也不共享上下文，纯属命名巧合 - 工厂类承担了配置解析、环境判断、甚至连接池管理等职责，导致它越来越重，违背「创建职责单一」原则
- 过度设计：项目只有一种缓存实现（比如固定用 Redis），却提前抽象出
MemcachedCacheFactory和FileCacheFactory，结果这些代码永远不被执行，还增加了维护负担
真正需要抽象工厂的信号是：你已经在多个地方重复 new 一对强关联对象，并且已经观察到它们的组合方式开始出现分歧（比如测试用 mock 对象、生产用真实对象）。
和依赖注入容器比，抽象工厂解决什么独特问题？
依赖注入容器（如 Laravel 的 Container 或 Symfony 的 ServiceContainer）擅长管理「单个对象生命周期」，但对「对象族的一致性」无能为力。抽象工厂补的就是这个缺口：
- 容器可以帮你拿到一个
CacheInterface，但它无法保证你同时拿到的LockInterface是同一套实现（比如都是 Redis 版） - 当你需要切换整套基础设施（从 Redis 切到 Memcached），只需替换工厂实例，不用逐个修改服务注册逻辑
- 工厂可封装「创建时的隐式约束」，例如
RedisCacheFactory内部强制使用同一个RedisClient实例，避免连接泄漏或状态不一致
所以别把它当成“高级 new”，而是当成「保障对象协作契约的边界」——这个边界一旦模糊，抽象工厂就退化成一堆难以测试的静态工厂函数。
