PHP 8.2的只读类Readonly Classes如何增强数据模型？结合工厂模式使用-php教程-PHP中文网

php 8.2 只读类强制属性不可变，需在构造函数中完成全部初始化，配合工厂模式可实现“构造即终态”；工厂负责参数校验、转换与补全，确保只读约束下状态完整且可靠。

php 8.2的只读类readonly classes如何增强数据模型？结合工厂模式使用

PHP 8.2 的只读类本身不增强数据模型的业务能力，它只强制约束「属性不可变」这一层语义。是否增强，取决于你如何用——尤其是和工厂模式配合时，能真正把“构造即终态”这个契约落地。

只读类为什么不能直接 new 出来就完事？

只读类的属性必须在构造函数中完成初始化，且之后任何赋值都会触发 Cannot modify readonly property 错误。这意味着：

不能靠 setter 或后期赋值补全状态
所有依赖项必须在实例化前就位（比如从配置、请求、数据库查出的原始数据）
若字段有默认值或可选逻辑（如空字符串转 null），必须在构造函数里处理干净，不能留到外面改

这倒逼你把对象构建逻辑前置、显式化——正好是工厂模式的强项。

工厂函数怎么配合 readonly class 避免属性漏初始化？

工厂函数不是为了“多写一层”，而是为了集中校验、转换、补全。只读类拒绝运行时修改，所以工厂得在 new 前把所有参数准备好。

例如 DTO 场景：

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

readonly class UserDto
{
    public function __construct(
        public string $id,
        public string $email,
        public ?string $nickname,
        public int $status,
    ) {}
}
<p>function makeUserDto(array $raw): UserDto
{
// 工厂负责兜底：字段缺失、类型转换、业务规则
return new UserDto(
id: $raw['id'] ?? throw new InvalidArgumentException('id required'),
email: filter_var($raw['email'], FILTER_VALIDATE_EMAIL) ?? throw new InvalidArgumentException('invalid email'),
nickname: $raw['nickname'] ?? null,
status: (int)($raw['status'] ?? 1),
);
}
</p>

构造参数全是 required，工厂必须显式传入每个值，否则 PHP 会报错（Missing argument）
工厂里做类型校验、空值处理、异常抛出，比让只读类自己扛更清晰
调用方不用关心哪些字段可空、哪些要过滤——这些契约全由工厂封装

继承链里工厂怎么分层？

只读类支持继承，但子类也必须声明为 readonly，且不能继承自非只读父类。这意味着工厂也要对应分层，不能混用。

父类工厂只负责父类字段，子类工厂调用父类工厂 + 补充子类字段
不要试图用一个通用工厂 new 所有只读子类——字段集不同，构造签名必然不同
如果父类是非只读的（比如带公共 setter 的基类），它不能被只读类继承；反过来，只读类也不能被普通类继承

典型错误：

// ❌ 报错：Cannot extend readonly class from non-readonly class
class BaseUser { }
readonly class AdminUser extends BaseUser { } // 编译失败
<p>// ✅ 正确：父类也 readonly，工厂各自独立
readonly class User { public function <strong>construct(public string $name) {} }
readonly class AdminUser extends User { public function </strong>construct(string $name, public string $role) { parent::__construct($name); } }</p><p>function makeUser(array $data): User { /<em> ... </em>/ }
function makeAdminUser(array $data): AdminUser { /<em> ... </em>/ }
</p>

容易忽略的边界：只读类里的引用类型还是可变的

readonly 只冻结属性本身的赋值行为，不递归冻结属性值内部状态。比如 public array $tags 是只读的，但你可以执行 $user->tags[] = 'vip' —— 这不会报错，因为没改 $tags 这个变量，只是在它指向的数组里追加元素。

如果需要真正不可变，得用 ImmutableArray 这类封装，或在工厂里返回 array_values() 后的副本
对象类型同理：public DateTimeInterface $createdAt 是只读的，但 $user->createdAt->modify('+1 day') 依然合法（只要它是可变的 DateTime 实例）
工厂里最好用 new DateTimeImmutable(...) 替代 new DateTime(...)，从源头切断副作用

只读类的威力不在语法糖，而在它迫使你把“状态何时确定、由谁确定、如何验证”这些隐含逻辑，全部推到构造那一刻——而工厂，就是那个最合适的守门人。