我正在开发一个相当复杂的物流管理系统，该系统将不断发展成为其他几个与 ERP 相关的模块。因此，我正在尝试尽可能多地采用 SRP 和开放/关闭原则，以便于扩展和基于域的管理。

因此，我决定使用 Laravel 和以下模式(不确定是否有名称):

我将使用 PRODUCT 对象作为示例。 一个对象/实体/域有一个类 类 ProductService {}

这个类有一个 Service Provider，它包含在 providers 数组中，也是自动加载的: ProductServiceServiceProvider

服务提供商实例化(制作)作为接口(interface)的 ProductRepository。 该接口(interface)当前有一个名为 EloquentProductRepository 实现的 MySQL(和一些 Eloquent)和一个 ProductRepositoryServiceProvider 绑定(bind)实现，该实现也已加载并位于提供程序数组中。

现在一个产品有许多不同的属性和与其他领域的关系，因为其他领域(或实体)需要完全分离并再次遵守上述原则(SRP 等。)我决定也有相同的结构对他们来说，就像我对产品所做的那样......我知道有些人可能认为这太多了，但我们需要让系统具有很强的可扩展性，老实说，我喜欢有条理并有一个统一的模式(它不需要多了很多时间，以后也省了很多。

我的问题是这样的。 ProductService 处理 Product 的所有业务逻辑并使“Product”成为现实，将在通过构造函数创建其实例时注入(inject)多个依赖项。

目前是这样的:

namespace Ecommerce\Services\Product;

use Ecommerce\Repositories\Product\ProductRepository;
use Ecommerce\Services\ShopEntity\ShopEntityDescriptionService;
use Content\Services\Entity\EntitySeoService;
use Content\Services\Entity\EntitySlugService;
use Ecommerce\Services\Tax\TaxService;
use Ecommerce\Services\Product\ProductAttributeService;
use Ecommerce\Services\Product\ProductCustomAttributeService;
use Ecommerce\Services\Product\ProductVolumeDiscountService;
use Ecommerce\Services\Product\ProductWeightAttributeService;
use Ecommerce\Services\Product\ProductDimensionAttributeService;

/**
 * Class ProductService
 * @package Ecommerce\Services\Product
 */
class ProductService {

    /**
     * @var ProductRepository
     */
    protected $productRepo;

    /**
     * @var ShopEntityDescriptionService
     */
    protected $entityDescription;

    /**
     * @var EntitySeoService
     */
    protected $entitySeo;

    /**
     * @var EntitySlugService
     */
    protected $entitySlug;

    /**
     * @var TaxService
     */
    protected $tax;

    /**
     * @var ProductAttributeService
     */
    protected $attribute;

    /**
     * @var ProductCustomAttributeService
     */
    protected $customAttribute;

    /**
     * @var ProductVolumeDiscountService
     */
    protected $volumeDiscount;

    /**
     * @var ProductDimensionAttributeService
     */
    protected $dimension;

    /**
     * @var ProductWeightAttributeService
     */
    protected $weight;

    /**
     * @var int
     */
    protected $entityType = 3;


    public function __construct(ProductRepository $productRepo, ShopEntityDescriptionService $entityDescription, EntitySeoService $entitySeo, EntitySlugService $entitySlug, TaxService $tax, ProductAttributeService $attribute, ProductCustomAttributeService $customAttribute, ProductVolumeDiscountService $volumeDiscount, ProductDimensionAttributeService $dimension, ProductWeightAttributeService $weight)
    {
        $this->productRepo = $productRepo;
        $this->entityDescription = $entityDescription;
        $this->entitySeo = $entitySeo;
        $this->entitySlug = $entitySlug;
        $this->tax = $tax;
        $this->attribute = $attribute;
        $this->customAttribute = $customAttribute;
        $this->volumeDiscount = $volumeDiscount;
        $this->dimension = $dimension;
        $this->weight = $weight;
    }
`

在 PHP 中将尽可能多的参数传递给构造函数是否是一种不好的做法(请忽略服务的长名称，因为在确定 ERP namespace 后这些名称可能会发生变化)？

正如下面 Ben 的回答，在这种情况下不是。我的问题与 OOP 无关，而是与性能等有关。原因是这个特定的类 ProductService 是 Web 开发人员对 Controller 所做的事情，即他们可能(并且违反原则)在一个 ProductController 中添加所有数据库关系处理存储库服务(数据库等)并附加关系，然后突然变成您的业务逻辑。

在我的应用程序中(我看到大多数应用程序都是这样)，Web 层只是另一层。 MVC 负责 web 层，有时也负责其他 Apis，但除了与我的 MVC 中的 View 和 JS 框架相关的逻辑外，我不会有任何逻辑。所有这些都在我的软件中。

结论:我知道这是一个非常 SOLID 的设计，注入(inject)了依赖项，它们确实是依赖项(即产品必须有税，产品确实有重量等)，并且它们可以很容易地与其他产品交换类归功于接口(interface)和 ServiceProviders。现在多亏了答案，我也知道在构造函数中注入(inject)这么多依赖项是可以的。

我最终会写一篇关于我使用的设计模式以及为什么我在不同场景中使用它们的文章，如果您对此感兴趣，请关注我。

谢谢大家

最佳答案

一般来说，不，在大多数情况下，这不是一个坏习惯。但是在你的情况下，正如@zerkms 的评论中所说，看起来你的类依赖于很多依赖项，你应该研究它，并考虑如何最小化依赖项，但如果你实际使用他们，他们应该在那里，我根本看不出有什么问题。

但是，您应该使用依赖注入(inject)容器 (DIC)。

依赖注入(inject)容器，基本上是一种工具，它通过您提供的命名空间创建类，并创建包含所有依赖项的实例。您还可以共享对象，因此它不会在创建依赖项时创建它的新实例。

我建议你使用 Auryn DIC

用法:

 $provider = new Provider();
 $class = $provider->make("My\\App\MyClass");

这里发生的事情是这样的:

namespace My\App;

use Dependencies\DependencyOne,
    Dependencies\DependencyTwo,
    Dependencies\DependencyThree;

class MyClass {

    public function __construct(DependencyOne $one, Dependency $two, DependencyThree $three) {
         // .....
    }
}

基本上，Provider#make(namespace) 创建给定命名空间的实例，并创建其构造函数参数和所有参数的构造函数参数等所需的实例。

关于php - 向构造函数注入(inject)多个参数是不好的做法吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25715252/