Laravel类间通信、依赖注入与方法设计最佳实践咨询

项目结构 #

App
- Controller（Controller.php）
- DataProcessing（Processing.php）
  - Sub data process（RemoveCrapDp.php）
- Computed（Computed.php）

当前实现代码参考：

// Controller.php
class Controller
{
  public function index(Request $req, Processing $dp) {
    $dp->method($req->get('some_data'));
  }
}

// Processing.php
class Processing
{
  private string $data;

  public function method(string $data) {
    // 预处理
    // 问题1：在此方法中调用RemoveCrapDp的最佳方式是什么？
  }
}

问题1：Processing中调用RemoveCrapDp的最佳方式 #

针对你给出的四种实现，逐一分析优劣：

1. 依赖注入+setData传参：若RemoveCrapDp是无状态可复用的服务，这种方式可行，但如果每次处理都需要独立实例，构造传参更直接。
2. 构造函数传参实例化：推荐方案。RemoveCrapDp的核心职责是处理特定数据，构造时传入数据能保证实例创建后直接处于可用状态，避免未设置数据就调用方法的风险。
3. new后setData：逊于构造传参，实例创建后可能处于未就绪状态，需要额外保证setData先执行。
4. 静态方法调用：完全不推荐，静态方法会导致类间耦合过高，难以Mock测试和扩展，不符合依赖倒置原则。

最优写法示例：

// 场景1：RemoveCrapDp为单次处理类（有状态）
class Processing
{
    private string $data;

    public function method(string $data) {
        // 预处理
        $cleanedData = (new RemoveCrapDp($data))->process();
        // 后续逻辑
    }
}

class RemoveCrapDp
{
    private string $data;

    public function __construct(string $data) {
        $this->data = $data;
    }

    public function process(): string {
        return trim($this->data); // 去除空格等处理
    }
}

// 场景2：RemoveCrapDp为无状态服务
class Processing
{
    private RemoveCrapDp $removeCrapDp;

    // 构造注入RemoveCrapDp
    public function __construct(RemoveCrapDp $removeCrapDp) {
        $this->removeCrapDp = $removeCrapDp;
    }

    public function method(string $data) {
        // 预处理
        $cleanedData = $this->removeCrapDp->process($data);
        // 后续逻辑
    }
}

class RemoveCrapDp
{
    public function process(string $data): string {
        return trim($data);
    }
}

问题2：Computed类的调用位置与方式 #

调用位置选择

应该在Processing类中调用Computed，原因如下：

• Processing的核心职责是流程编排，负责串联数据处理的各个环节；
• RemoveCrapDp只专注于「数据清理」单一职责，不应该知晓后续的计算逻辑，符合单一职责原则。

调用方式

参考问题1的最优方案：

• 若Computed是无状态的纯计算工具类，可直接调用静态方法（逻辑简单时）或通过依赖注入实例（需扩展/测试时）；
• 若Computed需要维护计算上下文（有状态），则通过构造传参实例化。

更优建议

将Processing设计为纯流程编排器，只负责调用各职责单一的类，不实现具体业务逻辑。后续新增处理/计算步骤时，只需修改Processing的流程，不影响其他类的代码。

示例：

class Processing
{
    private RemoveCrapDp $removeCrapDp;
    private Computed $computed;

    public function __construct(RemoveCrapDp $removeCrapDp, Computed $computed) {
        $this->removeCrapDp = $removeCrapDp;
        $this->computed = $computed;
    }

    public function handle(string $data) {
        // 1. 清理数据
        $cleanedData = $this->removeCrapDp->process($data);
        // 2. 执行计算
        $computedResult = $this->computed->calculate($cleanedData);
        // 3. 返回或进一步处理
        return $computedResult;
    }
}

问题3：Computed类的合理设计 #

Computed类的核心是纯计算逻辑，设计遵循以下原则：

1. 优先无状态设计：计算逻辑只依赖输入参数，不依赖类成员变量，便于复用和测试；
2. 单一职责：每个方法只做一件事，避免职责混杂；
3. 避免不合理的状态耦合：禁止混合静态方法与实例成员变量（如你示例中setMode+静态someMethod2的写法，静态方法无法访问实例变量，逻辑不成立）。

针对你给出的Problem2，优化示例：

// 无状态设计（推荐，适合纯计算场景）
class Computed
{
    public static function checkMode(int $mode): bool {
        return $mode === 0;
    }

    public static function calculateValue(int $mode, int $base): int {
        return self::checkMode($mode) ? $base * 2 : $base;
    }

    // 依赖外部结果，降低耦合（推荐替代someMethod3）
    public static function processResult(bool isMode0, int number): int {
        return isMode0 ? number + 10 : number - 5;
    }
}

// 有状态设计（适合需要维护计算上下文的场景）
class Computed
{
    private int $mode;

    public function __construct(int $mode) {
        $this->mode = $mode;
    }

    public function checkMode(): bool {
        return $this->mode === 0;
    }

    public function calculateValue(int $base): int {
        return $this->checkMode() ? $base * 2 : $base;
    }
}

问题4：静态方法与普通方法的使用场景 #

静态方法

• 适用场景：无状态的纯工具类（如Computed的计算方法）、不需要实例化的通用逻辑、无状态的操作；
• 优缺点：调用方便，但耦合高、难以Mock测试、无法依赖注入和继承重写。

普通方法

• 适用场景：有状态的类（如Processing）、需要依赖注入的类、需要继承扩展的类、需维护上下文的逻辑；
• 优缺点：灵活可测、符合依赖倒置原则，但需要实例化后调用。

当前场景建议

• Controller、Processing：用普通方法，需依赖注入其他服务，可能维护处理状态；
• RemoveCrapDp：无状态服务用普通方法（依赖注入），单次处理类用普通方法（构造传参）；
• Computed：纯计算逻辑用静态方法，需维护上下文则用普通方法。

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