18

抽象类是否应该始终以(当它是接口时)为前缀Abstract和后缀?Interface是否有任何标准命名约定,类似于 PSR-0 用于文件夹结构/命名空间,但用于类?

这似乎是多余的,因为该语言为此目的具有文字关键字。

abstract class AbstractFoo {}

interface InterfaceFoo {}

trait TraitFoo {}
4

7 回答 7

18

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

于 2012-11-26T11:55:59.013 回答
17

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

它指出:

  • 接口必须以接口为后缀:例如 Psr\Foo\BarInterface

  • 抽象类必须以抽象为前缀:例如 Psr\Foo\AbstractBar

  • Traits 必须以 Trait 为后缀:例如 Psr\Foo\BarTrait

这些约定通常在包中遵循

于 2018-09-10T19:36:24.433 回答
10

对此没有约定。特别是在 PHP 中。这一切都可以按照您的意愿进行组织。

随着 PHP 5.3 中命名空间的添加,我认为不需要在实际类名中添加Abstract或前缀/后缀。Interface

只需按原样命名即可!

于 2012-11-26T11:43:01.230 回答
4

与大多数其他答案相反,我建议最好不要在类中添加前缀或后缀。该语言具有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';
    }
}
于 2021-02-12T04:04:57.583 回答
4

接口:

接口必须以 Interface: 为后缀e.g. Psr\Foo\BarInterface


抽象类:

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


性状

特征必须以 Trait: 为后缀e.g. Psr\Foo\BarTrait


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

于 2021-04-27T10:29:12.363 回答
3

使用以下命令命名抽象类和接口:

  • 抽象的*
  • *界面

将使您的代码库保持干净、美观且对您的团队显而易见,原型是什么,合同是什么以及具体的实现是什么。

在任何情况下,命名约定都是为了提高我们的生产力,因此“随心所欲地命名”远非好主意。

尽管 FIG 小组没有提出抽象类和接口的命名约定——如果您查看主要的开源 PHP 项目,您会发现几乎所有项目都使用这种约定。

于 2015-01-29T14:52:10.017 回答
1

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

根据我的经验,我建议遵循“按合同设计”之类的方法。像命名实现类一样命名您的合约(接口),然后给您的实现一个更具体的名称(或回退到 MyContractNameImpl,我猜主要来自 Java)。此外,许多现代 IDE 都知道您的类是接口还是抽象类,因此实际上没有必要将其放在它的名称中。出于同样的原因,我还发现名为“IMyContract”的合同并不是很好。

于 2012-11-26T12:02:39.710 回答