README

保护您免受第三方依赖的有害光线。

在软件开发中，重新发明轮子常被视为一件坏事。与此同时，过度依赖第三方依赖也被视为一件坏事。这是一个什么困境呢？

关于这一点的一般建议似乎是，当然，使用第三方依赖，但请负责任地使用。将它们包装在你自己的接口中，这样如果依赖项过时、失效或不再适合使用，你就有自己的接口，可以随时更换依赖项或提供自己的实现。《六边形架构》和所有那些。

Sunscreen旨在通过自动为支持的依赖项创建接口和适配器来帮助这个过程。太棒了！

需要注意的一点是，这旨在简单地给你一个起点，让你养成将依赖项包装在你自己接口中的习惯。它是通过几乎逐字复制第三方依赖项的主要接口/类的。这对于简单的依赖项可能是可以的，但对于那些接口或方法众多的类来说就有点不足了。这里的建议是，定义你的接口为《你》需要的，并使其他接口适应它。实际上，这就是以这种方式包装依赖项的期望用途。这个库不会这样做，它只会按原样使用接口/类。因此，一旦这个库完成了它的工作，你应该根据你的需要审查和更改/更新接口。

安装

composer require jenko/sunscreen --dev

然后将其添加到你的 composer.json

    "scripts": {
        "post-package-install": [
            "Jenko\\Sunscreen\\Sunscreen::postPackageInstall"
        ]
    }

工作原理

在通过composer安装了一个包之后，脚本会启动。它将检查该包的composer文件，并查找以下内容

    "extra": {
        "sunscreen": {
            "interfaces": [
                "Acme\\Package\\MyPackageInterface"
            ]
        }
    }

有了关于包的这些信息，它将使用这些信息生成接口/类和一个适配器。

如果为该包不存在配置，它将尝试从一组预配置的json文件中加载配置。

如果它仍然找不到任何配置，它将尝试通过假设一个包有一个名为PackageNameInterface的接口或主源目录中的抽象类AbstractPackageName来猜测主要接口。这显然非常不可靠，配置是首选的。

听起来很棒，我编写了一个包，我能做什么呢？

如上所述，只需将以下部分配置添加到你的包的composer.json文件中。

    "extra": {
        "sunscreen": {
            "interfaces": [
                "Acme\\Package\\MyPackageInterface"
            ]
        }
    }

或者如果你没有主接口但有一个类，那么它将是

    "extra": {
        "sunscreen": {
            "classes": [
                "Acme\\Package\\MyPackage"
            ]
        }
    }

哦，我最喜欢的包没有合并我的PR，那现在怎么办？

为你的依赖项创建一个带有预配置json的PR到这个仓库。

jenko / sunscreen

维护者

详细信息

README

安装

工作原理

听起来很棒，我编写了一个包，我能做什么呢？

哦，我最喜欢的包没有合并我的PR，那现在怎么办？