laravel 如何防止我们的代码和第三方库之间的耦合?

icomxhvb  于 2023-11-20  发布在  其他
关注(0)|答案(1)|浏览(109)

假设我们想像这样使用下面的库:

use GrahamCampbell\GitHub\GitHubManager;

class Foo
{
    private GitHubManager $github;

    public function __construct(GitHubManager $github)
    {
        $this->github = $github;
    }

    public function bar(): array
    {
        $this->github->issues()->show('GrahamCampbell', 'Laravel-GitHub', 2);
    }
}

字符串
创建一个像这样的接口是否有意义:

interface GitHubManagerInterface
{
    public function showIssues(): array;
}


然后实现它,并将实现绑定到接口,并在代码中使用它,如下所示?

class Foo
{
    private GitHubManagerInterface $github;

    public function __construct(GitHubManagerInterface $github)
    {
        $this->github = $github;
    }

    public function bar(): array
    {
        $this->github->showIssues('GrahamCampbell', 'Laravel-GitHub', 2);
    }
}


或者有更好的方法来防止耦合?或者是过度工程化?:)

kmynzznz

kmynzznz1#

如果是一个库,比如Redis客户端或者MongoDB客户端库,最好在基础架构层使用。将它们 Package 在接口中可以使代码解耦,但有时你无法消除依赖。
根据我使用MongoDB的经验,你的接口可能会被MongoDB驱动模型污染,因为库有很多模型来表达输出和输入。那么你有两个选择:

  • 通过定义模型来 Package 它所需要的一切,然后在后台将其转换为MongoDB模型,从而使您的方式独立。当然,独立更好,但以定义更多模型和编写翻译为代价。
  • 接受耦合并使用第三方模型。这更容易,但代价是依赖于库。在开发的早期,选择这种方式(更快地进入市场)是合理的,直到你知道你的产品的实际需求是什么,未来的需求是什么。当你更了解你的产品时,你会做出更精确的决策。

有时候你知道你不会改变第三方库。这有助于你接受与库的耦合。是的,你的项目将耦合到外部库,但只要你不想改变它,它就不会伤害你。
但是如果是外部服务,你应该使用ACL模式来防止你的项目被第三方服务逻辑污染。ACL模式建议为第三方服务定义一个接口,将客户端模型作为输入和输出,并在实现中将客户端模型转换为第三方模型。
这里有一些注意事项来决定是否将第三方库 Package 在接口中:

  • 你要衡量破坏向后兼容的可能性,如果这个库是知名的,有一个很好的社区,他们可能会关心用户,支持向后兼容,所以你的项目不会受到库更改的影响。
  • 你会改变第三方库还是不会?你不能确定。如果你有多个知名的库来满足你的需求,我认为这是合理的假设,你可能会改变它在未来。考虑到你未来的业务需求。如果你预测你的业务将需要扩展或及时改变其需求,这将影响你的决定。
  • 耦合并不总是坏的。因为它可以被算作一种技术债务。你为了更快地交付软件而负债。但请记住,总有一天你必须偿还你的债务。

相关问题