我正在开发一个相当复杂的物流管理系统，它将不断发展成为其他几个与 ERP 相关的模块。因此，我试图尽可能多地采用 SRP 和开放/关闭原则，以便于扩展和基于域的管理。
因此，我决定使用 Laravel 和以下模式（不确定这是否有名称）：
我将在我的示例中使用 PRODUCT 对象。对象/实体/域有一个类
class ProductService {}
这个类有一个服务提供者，它包含在提供者数组中并且也是自动加载的：
ProductServiceServiceProvider
服务提供者实例化（制作）ProductRepository一个接口。该接口当前有一个称为EloquentProductRepositoryimplementation(s) 的 MySQL（和一些 Eloquent），并ProductRepositoryServiceProvider绑定了同样加载并在 providers 数组中的 implementation。
现在一个产品有许多不同的属性和与其他领域的关系，因为其他领域（或实体）需要完全分离并再次遵守上述原则（SRP 等）。我决定为它们也有相同的结构我为产品做...我知道有些人可能认为这太过分了，但我们需要让系统非常可扩展，老实说，我喜欢有条理并有一个统一的模式（不需要那么多时间并在以后为我节省了很多）。
我的问题是这个。ProductService 处理产品的所有业务逻辑并使“产品”成为它的样子，它将通过构造函数在创建它的实例时注入几个依赖项。
这是它目前所拥有的：
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 名称空间时这些名称可能会改变）？
正如下面 Ben 所回答的那样，在这种情况下它不是。我的问题与 OOP 无关，而与性能等有关。原因是这个特定的类 ProductService 是 Web 开发人员对控制器所做的事情，即他们可能（并且违反原则）将所有数据库关系添加到一个 ProductController 中处理存储库服务（数据库等）并附加关系，然后它突然成为您的业务逻辑。
在我的应用程序中（我看到大多数应用程序都是这样），Web 层只是另一层。MVC 负责 Web 层，有时也负责其他 API，但除了与 MVC 中的视图和 JS 框架相关之外，我不会有任何逻辑。所有这些都在我的软件中。
总之：我知道这是一个非常可靠的设计，依赖项被注入并且它们确实是依赖项（即产品必须有税并且产品确实有重量等）并且它们可以很容易地与其他类交换，这要归功于接口和服务提供者。现在感谢答案，我也知道在构造函数中注入这么多依赖项是可以的。
我最终会写一篇关于我使用的设计模式以及我为什么在不同场景中使用它们的文章，如果您对此感兴趣，请关注我。
感谢大家