我读到，一个类不应该有太多的依赖关系。在一本书中，它指出 4 个依赖项可能表明类可能做了太多事情。

假设我编写了一个使用 10 个依赖项的类：6 个类和 4 个外观。我应该只关心这 6 个类并将它们分开，还是也关心 4 个外观？

如果有人想知道我是如何得到这么多门面的：

use Input;
use App;
use Session;
use Log;

这些都是经常需要的。我听到一个问题 - 为什么我需要应用程序？调用函数：

App::setLocale('lt');

有人说门面不是依赖，也在这里：

多态性和依赖注入——太多的依赖 https://stackoverflow.com/questions/27922492/polymorphism-and-dependency-injection-too-many-dependencies

关于这个问题有很多不同的观点（什么时候上课？ 依赖于某些东西），但类依赖通常被视为 传递给构造函数的内容，即类需要什么 被实例化为对象。

我想我自己可以从一个类创建一个外观，并且我将通过这种方式减少依赖关系。但这有什么意义吗？

例如这篇文章指出 - 我们不应该使用外观：

http://taylorotwell.com/response-dont-use-facades/ http://taylorotwell.com/response-dont-use-facades/

从这里我知道门面并没有那么糟糕，但糟糕的是类开始做太多的事情。

我说的是 Laravel 4，但可能同样适用于 Laravel 5 或其他使用相同框架的框架。我刚刚听说 Laravel 5 使用的门面数量没有 Laravel 4 那么多。

Update:

我也想得到这样的论点，以便我可以在讨论这个话题时与其他人一起使用它。就像我说的那样——互联网上的一些人（即使拥有良好的 stackoverflow 配置文件）对我说外观很糟糕，它们就像全局变量，他们会立即告诉我——这与全局不同，它们是可嘲笑的，你不应该关心。他们也可能会说，这是他们的意见。所以我想要用强项来捍卫自己。所以我可以像 2*2 = 4 一样解释它，没有人会不同意。或者至少接近那个。

Update:

如果这些是依赖项，并且我希望一个类最多有大约 4 个依赖项，那么我只有一个想法 - 创建分组类，就像类树一样。但我最终还是为小功能开设了很多课程。就像这 10 个依赖项一样，如果我想要最多 4 个依赖项，我想我需要 3-5 个类，而不是 1 个。所以，如果我有一个大项目，你将有数百万个小类。那样的话是不是会显得更复杂呢？就像 Laravel 一样，我看到有很多类，而 CodeIgniter 的类少得多，并且看起来更易于阅读/遵循和扩展。

Laravel 外观绝对是依赖项，它们的预期用途是用于控制器，在构建服务和业务逻辑时，您应该尝试使依赖项尽可能透明。

如果您的目标是实现 SOLID 实现，您将希望将所有依赖项作为参数或在类构造函数中传递。

让我们稍微说明一下这个抽象：

重构前

Class PhotoService {

    protected $photosModel = null;

    public function getPhotos()
    { 
        $photos = Cache::get('photos');

        if (is_null($photos)) {
           return Photo::all();
        }
    }
}

仍然使用门面，但通过 IOC 解决其他依赖关系

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();
       }
    }
}

通过IOC解决

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 没有任何坏处。

这种设置仅提供以下优点：

• 能够轻松切换缓存策略
• 切换数据库类型的能力
• 通过 ioc 注入模拟来关闭功能的能力
• 通过易于实施来鼓励 TDD