PHP封装里业务规则该写在属性里还是方法里-php教程-PHP中文网

业务规则必须写在方法里，不能塞进属性声明中，因为php属性仅存储数据，不支持执行逻辑，类型声明和readonly只约束类型与可变性，不提供校验入口；应置于__construct()、setter或独立验证方法中。

php封装里业务规则该写在属性里还是方法里

业务规则必须写在方法里，不能塞进属性声明中。

为什么属性里不能放业务规则

PHP 的属性（$var）只是存储数据的容器，不支持执行逻辑。即使你用 PHP 7.4+ 的类型声明（如 public string $email;）或 PHP 8.2+ 的 readonly，它们只约束类型、可变性或是否允许动态属性，**不提供校验入口、不触发回调、不支持条件判断**。

常见错误现象：

试图在属性声明时做格式检查：public string $email = filter_var($input, FILTER_VALIDATE_EMAIL) ?: throw new InvalidArgumentException(); → 语法错误，PHP 不允许在属性默认值中写表达式或语句
把验证逻辑藏在 getter 里但忽略构造阶段：public function getEmail() { return filter_var($this->email, FILTER_VALIDATE_EMAIL) ? $this->email : null; } → 外部早已通过 $user->email = 'xxx'; 写入非法值，getter 只是“事后补救”，状态已脏

业务规则该放在哪些方法里

根据规则触发时机和职责分离原则，优先按以下顺序考虑：

PHP

编写健壮的PHP代码，规避类型转换陷阱、数组怪癖及常见安全漏洞。

下载

__construct()：强制初始化校验。例如邮箱格式、必填字段非空、ID 为正整数等“对象诞生即合法”的规则
__set() 或 setter 方法（如 setEmail()）：控制后续修改。适合需要拦截赋值、转换格式（如 trim、strtolower）、或联动更新其他属性的场景
独立的验证方法（如 isValid() 或 validate()）：当规则复杂、依赖外部服务（如查重）、或需批量校验多个字段时使用，不耦合在赋值流程中

示例（构造 + setter 双保险）：

class User
{
    private string $email;

    public function __construct(string $email)
    {
        $this->setEmail($email); // 复用校验逻辑
    }

    public function setEmail(string $email): void
    {
        if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
            throw new InvalidArgumentException('Invalid email format');
        }
        $this->email = $email;
    }

    public function getEmail(): string
    {
        return $this->email;
    }
}