gpt4 book ai didi

php - 与 src 处于同一级别的文件夹的 PSR-4 命名空间约定

转载 作者:可可西里 更新时间:2023-11-01 00:56:43 25 4
gpt4 key购买 nike

PSR-4 的当前约定是将 src 文件夹命名为 Vendor\Package。然后使用目录结构对其中的任何文件进行命名空间。所以

src/Model/MyModel.php

使用

namespace Vendor\Package\Model;

class MyModel {...}

这对于 src 文件夹中的任何文件夹来说都很直观,但是与 src 处于同一级别的文件夹的约定是什么?例如 tests, public, config etc etc

(我知道有些人会评论命名空间测试的意​​义,但想象一个大型项目有很多单独的包,每个包都有自己的测试,但有可以在包之间重用的通用测试。)

我看到了使用 Vendor\Package\Tests 的建议,但对我来说,遵循 src 约定,这给人的印象是有一个 Tests 文件夹在 src 中,但事实并非如此。尽管如果src Tests 文件夹,那么这些命名空间会发生冲突吗?

最佳答案

命名空间应该将逻辑上和语义上属于一起的代码分组。在我看来,配置、路由器和测试都属于整个应用程序的一部分,因此我的配置倾向于让它们共享命名空间:

autoload: { "psr-4": { "Vendor\\Package\\": [ "public", "conf", "src" ] } }
autoload-dev: { "psr-4": { "Vendor\\Package\\": [ "tests" ] } }

当然,通过共享 namespace ,这意味着必须对每个工件进行分类(通常按其“种类”)以防止类名冲突。例如,Vendor\Package\Foo 可能涉及以下相关工件:

  • Vendor\Package\FooTesttests/FooTest.php
  • 中 foo 的单元测试
  • Vendor\Package\FooIntegrationTest,在 tests/FooIntegrationTest.php
  • 中专门覆盖 foo 的集成测试
  • Vendor\Package\AbstractFoosrc/AbstractFoo.php
  • 中 foo 家族成员的基础
  • Vendor\Package\Fooablesrc/Fooable.php
  • 中的 foo 接口(interface)

沿着这些思路,您可能会考虑将不同类型的代码分离到不同的目录中,而不是一个“包罗万象”的src。对于大型项目,这使得查找特定类型的文件变得更加容易,但对于库或小型应用程序来说可能有点过头了:

autoload: { 
"psr-4": {
"Vendor\\Package\\": [
"public", "conf", "lib", "view", "contract", "exception"
]
}
}

至于“约定”,我特别发现在源代码和测试之间共享命名空间既方便又容易,因为当我想测试 Foo 时,我不必为了获得它而折腾命名空间。

// tests/Something/FooTest.php
namespace Vendor\Package\Test\Something;
use Vendor\Package\Test\BaseTestCase;
use Vendor\Package\Something\Foo; // extra work I don't want to do

class FooTest extends BaseTestCase {
public function testX() {
$sut = new Foo;
}
}

在每个测试文件中多一行,加上在编写测试时必须找到 SUT 的认知负担意味着编写测试的更多工作,这降低了我编写测试的愿望。因此,您可能会说在源和测试之间共享命名空间降低了编写测试的障碍。

归根结底,源码组织的问题真正落到了每个项目身上,建立一个促进高效开发和合理构建的布局。我会说尝试一个并没有什么坏处,如果它不成功则重构。

关于php - 与 src 处于同一级别的文件夹的 PSR-4 命名空间约定,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40305836/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com