PHPMD 和对象类之间的耦合 (CBO)答案

【问题标题】：PHPMD and Coupling Between Object classes (CBO)PHPMD 和对象类之间的耦合 (CBO)
【发布时间】：2019-06-05 07:28:58
【问题描述】：

我正在按照最佳实践（最佳描述 here）开发 Magento 2 CRUD 功能。在我正在进行的项目中，我们使用的是 PHPMD（php mess detection）。在其他规则中，我们将 CBO 限制设置为 13（我理解这是默认值）。我的存储库正在实现get、save、getList、delete、deleteById 方法，并且限制已经是 12。

如果我需要在不重叠 PHPMD CBO 限制的情况下向此存储库添加其他方法，最佳实践是什么？

附注我认为其他框架/平台中的实现也可能是这种情况，与 Magento 2 不严格相关。

【问题讨论】：

每个方法的接口，每个接口的实现。这在 SOLID 中称为 SRP。这是一个伟大的规则。防止人们创建怪异的神类。
您能否详细说明一下（如果您需要更多解释空间，可以添加问题的答案）。如果我要求不高，我会对一个示例非常感兴趣！

标签： php magento2 phpmd

【解决方案1】：

这是最重要的规则之一，有助于让您的课程保持专注并更易于维护。你见过多少次了：

class XXXRepository
{
    public function findOneByCode($code);
    public function findOneByParams($params);
    public function findAllByParams($params);
    public function findActive($params);
    public function findForProductList($params);
    ... 5000 lines of spaghetti
}

相反，拥抱接口，让您的应用程序依赖于抽象，而不是实现细节：

interface ProductByCode
{
    public function findByCode(string $code): ?Product;
}

interface ProductsByName
{
    public function findByName(string $name): array;
}

使用依赖注入组件，您可以将接口别名为其实现。每个接口都去实现。您可以使用一个抽象类来帮助您通过您选择的框架与持久层进行通信。

final class ProductByCodeRepository extends BaseRepository implements ProductByCode
{
    public function findByCode(string $code): ?Product
    {
        return $this->findOneBy(['code' => $code]);
    }
}

【讨论】：

有趣的想法！但是，是否存在最终文件过多的风险（在一定数量的大型项目中可能会成为问题）或需要注入的依赖项过多（例如在 SonarQube 中，您可能有限制为CI / CD场景中注入的依赖项数量定义=>您的构建不会通过）？我会研究并尝试这个然后回来。
定义“文件太多”。另一件事是，如果你的类有超过 3 到 5 个依赖项，那肯定也违反了 SRP 原则。查看它的圈复杂度。
文件太多..我不知道类乘以方法数.. 200？我不知道.. 无论如何，看来我肯定需要花一些时间研究 SRP。我会回来的！谢谢！