4

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

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

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

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

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

App::setLocale('lt');

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

多态性和依赖注入——太多的依赖

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

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

例如这篇文章指出——我们不应该使用门面：

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 的类少得多，并且看起来更易于阅读/遵循、扩展。

4

1 回答 1

2

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

通过国际奥委会解决

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
于 2015-11-01T18:59:59.513 回答