Question

抽象类是否应始终以Abstract为前缀，并以Interface为后缀（当它是接口时）？是否存在任何标准命名约定，类似于文件夹结构/命名空间的PSR-0，但对于类？

Answer 1

虽然没有任何约定，但我认为对各个组件使用Abstract前缀和Interface后缀是一种很好的做法。有助于更好地理解代码，IMO。

Answer 2

没有这样的惯例;特别是在PHP中。这可以按照你的意愿进行组织。

在PHP 5.3中添加了namespaces，我认为不需要在实际的类名中添加Abstract或Interface前缀/后缀。

只要按原样命名！

Answer 3

PHP-FIG项目确实通过PSR命名约定“ ByLaw” https://www.php-fig.org/bylaws/psr-naming-conventions/

提出了命名约定。

它说明：

接口必须以接口为后缀：例如Psr\Foo\BarInterface
摘要类必须以摘要开头：例如Psr\Foo\AbstractBar
特质必须后缀特质：例如Psr\Foo\BarTrait

这些约定通常在软件包中遵循

Answer 4

使用：

命名您的抽象类和接口

抽象*
*接口

将保持您的代码库清洁，美观和明显的团队原型，合同是什么以及具体实现是什么。

命名惯例可以在任何情况下提高我们的工作效率，因此“随心所欲地命名”远非好主意。

即使FIG组没有提出抽象类和接口的命名约定 - 如果你检查主要的开源PHP项目，你会发现几乎所有的都使用这个约定。

Answer 5

约定就是你所看到的：语言本身不会强制除了使解析器能够读取代码的约定之外的任何约定。基本上，您应该为自己的特定项目设置约定，或者更好地为所有项目设置约定。但是，在不同人的团队中工作可能导致不遵循惯例，这实际上取决于程序员。

根据我的经验，我建议遵循“按合同设计”之类的内容。命名你的契约（接口），就像你命名你的实现类一样，然后给你的实现一个更具体的名称（或者回溯到MyContractNameImpl，我猜的主要来自Java）。此外，许多现代IDE都知道您的类是接口还是抽象，所以实际上没有必要将它放在它的名称中。由于同样的原因，我也发现名为“IMyContract”的合同并不是很好。

Answer 6

与大多数其他答案相反，我建议最好不要向类添加前缀或后缀。为此，该语言具有文字关键字，例如 abstract, interface, class, final。

以下实际上破坏了干净的代码原则：

abstract class AbstractPerson 
{

   // ...
}

类似于“评论通常很糟糕，因为它表明代码不易阅读”的想法。如果您的类、继承及其契约以清晰易读且有意义的方式设计，则无需添加前缀。

行为设计

通常可以以反映事物行为的方式命名事物。例如在日志子系统中：

interface Loggable
{
    public function getLog(): string;
}

trait WritesLogs
{
    public function writeLog(): void
    {
        file_put_contents("logs.txt", $this->getLog());
    }
}

abstract class Event implements Loggable
{
    use WritesLogs;

    public function asLog(): string
    {
        return "{$this->getName()} at {$this->created_at}";
    }

    abstract public function getName(): string;
}

class FooCreated extends Event
{
    public function getName(): string
    {
        return 'Foo was created';
    }
}

Answer 7

接口：

接口必须以接口为后缀：e.g. Psr\Foo\BarInterface。

抽象类：

抽象类必须以抽象为前缀：e.g. Psr\Foo\AbstractBar。

特性

特征必须以特征作为后缀：e.g. Psr\Foo\BarTrait。

来源：https://www.php-fig.org/bylaws/psr-naming-conventions/

关于抽象类和接口的PHP命名约定

7 个答案:

接口：

抽象类：

特性