我已经读过一个类应该没有太多依赖。在一本书中，它指出4个依赖关系可能是一个类可能做得太多的迹象。
假设我写了一个使用10个依赖项的类：6个类和4个外观。我是否应该只关心这6个课程并将它们分开，或关心4个立面？
如果有人想知道我如何获得如此多的外观：
use Input;
use App;
use Session;
use Log;
经常需要这些。我听说过问题 - 为什么我需要App？要调用函数：
App::setLocale('lt');
有人说外墙不依赖，也在这里：
Polymorphism and dependency injection - too many dependencies
关于这个问题，有很多不同的观点（课时 取决于某些东西），但类依赖性通常被视为 什么传递给构造函数，即该类需要什么 被实例化为一个对象。
我想我自己可以从一个类创建一个Facade，我将以这种方式减少依赖。但这有意义吗？
例如，这篇文章指出 - 我们不应该使用外墙：
http://taylorotwell.com/response-dont-use-facades/
据我所知，外墙不会那么糟糕，但不好的是，班级开始做太多事情。
我在谈论Laravel 4，但可能同样适用于Laravel 5或其他使用它的框架。我刚刚听说Laravel 5没有像Laravel 4那样使用外墙。
更新
此外，我想得到这样一个论点，以便我可以在讨论这个主题时与其他人一起使用它。就像我说的那样 - 来自互联网的一些人（即使具有良好的stackoverflow配置文件）告诉我外墙很糟糕，它们就像全局变量，它们会立即告诉 - 这与全球不一样，它们是可模仿的，你不应该关心。他们也可能会说，这是家伙的意见。所以我希望有能力保护自己。所以我可以像2 * 2 = 4那样解释它，没有人能够不同意。或者至少接近那个。
更新
如果那些是依赖项，并且我希望一个类最多有4个依赖项，我只有一个想法 - 创建分组类，就像类树一样。但我最终得到了许多小功能课程。就像这10个依赖项一样，如果我想拥有最多4个依赖项，我想我需要3-5个类而不是1个。所以如果我有大项目，你将拥有数百万个小类。那看起来不会那么复杂吗？像Laravel一样，我看到有很多类，而CodeIgniter有更少的类，看起来更容易阅读/跟随，扩展。
答案 0 :(得分：1)
Laravel外观肯定是依赖项，它们的目的是用于控制器，在构建服务和业务逻辑时，您应该尽量使依赖项尽可能透明。
如果您的目标是实现SOLID实现，您将希望将所有依赖项作为参数或类构造函数传递。
让我们举一点说明这个抽象：
重构前的Class PhotoService {
protected $photosModel = null;
public function getPhotos()
{
$photos = Cache::get('photos');
if (is_null($photos)) {
return Photo::all();
}
}
}
Class PhotoService {
protected $photosModel = null;
public function __construct(PhotoInterface $photoModel) {
$this->photosModel = $photoModel;
}
public function getPhotos()
{
$photos = Cache::get('photos');
if (is_null($photos)) {
return $this->photosModel->getPhotos();
}
}
}
Class PhotoService {
protected $photosModel = null;
public function __construct(PhotoInterface $photoModel) {
$this->photosModel = $photoModel;
}
public function getPhotos(CacheInterface $cache)
{
$photos = $cache->get('photos');
if (is_null($photos)) {
return $this->photosModel->getPhotos();
}
}
}
在我看来外部化代码时的最佳示例，即使您在自己的项目之间共享代码也是如此。如果通过接口提供完整签名，而不是必须查看任何外观的旧代码或测试，新实现更容易工作。
我认为在控制器中使用Facades没有任何损害。
这种设置只提供了它们之间的优势：