Drupal约束插件为何需与验证器分为独立类？

我正在自学Drupal应用中的约束验证器，目前对该模式的一个方面存在疑惑。Drupal 10弃用了为#upload_validators提供函数回调的旧方法，转而推荐使用Constraint插件。按要求需分别创建约束插件类和对应的验证器类：

约束插件类示例 #

#[Constraint(
  id: 'MediaDispositionFeedFile',
  label: new TranslatableMarkup('Media Disposition Feed File', [], ['context' => 'Validation']),
  type: 'file'
)]
class MediaDispositionFeedFileConstraint extends SymfonyConstraint {

  /**
   * The error message.
   *
   * @var string
   */
  public string $message = 'The uploaded file does not appear to match the required format.';

}

验证器类示例 #

/**
 * Validates that the uploaded XLSX file contains the correct columns.
 */
class MediaDispositionFeedFileConstraintValidator extends BaseFileConstraintValidator {

  private \PhpOffice\PhpSpreadsheet\Reader\IReader $reader;

  public function __construct(
  ) {
    $this->reader = IOFactory::createReader('Xlsx');
  }

  /**
   * {@inheritdoc}
   */
  public function validate(mixed $value, Constraint $constraint) {
    // ...
  }

}

我想了解：为何不能将::validate函数放在约束插件类中，必须单独使用验证器类？

核心原因是遵循单一职责原则与Symfony验证组件的设计规范 #

Drupal的约束验证体系完全基于Symfony的Validator组件，这种分离设计是Symfony的核心约定，背后有几个关键考量：

• 职责拆分清晰：
  Constraint类只负责定义"规则是什么"——比如验证的标识、适用类型、错误提示信息，以及规则的参数（比如文件大小验证的阈值）。它是纯数据载体，不包含业务逻辑。而Validator类则负责实现"怎么验证"——读取文件、解析内容、判断规则匹配性这些具体逻辑都在这里。拆分后代码更易维护，修改规则参数不用碰验证逻辑，调整验证逻辑也不会影响规则定义。

• 支持依赖注入：
  验证逻辑往往需要外部服务（比如示例中的PhpOffice\PhpSpreadsheet阅读器，或是Drupal的实体管理器、文件系统服务）。Validator类作为服务可以通过构造函数注入这些依赖，但Constraint类是作为配置对象被实例化的，无法直接使用依赖注入机制。如果把validate放在Constraint类里，很难优雅地引入这些外部依赖。

• 复用性与灵活性：
  同一个Constraint可以对应多个Validator，或者一个Validator处理多个Constraint（设计上支持这种场景）。比如你可以为同一个"文件格式验证"约束，分别实现针对XLSX、CSV的不同验证器，或是在不同场景下切换验证逻辑。如果把验证逻辑硬编码在Constraint里，这种复用就无从谈起。

• 与Drupal插件体系兼容：
  Constraint在Drupal里是插件，主要用于配置层面（比如在字段设置里选择要应用的约束）。插件类需要保持轻量，专注于定义元数据，而把执行逻辑交给专门的服务类，符合Drupal插件与服务分离的设计思路。

内容的提问来源于stack exchange，提问作者JonMcL