抽象类是否应该始终以(当它是接口时)为前缀Abstract
和后缀?Interface
是否有任何标准命名约定,类似于 PSR-0 用于文件夹结构/命名空间,但用于类?
这似乎是多余的,因为该语言为此目的具有文字关键字。
abstract class AbstractFoo {}
interface InterfaceFoo {}
trait TraitFoo {}
抽象类是否应该始终以(当它是接口时)为前缀Abstract
和后缀?Interface
是否有任何标准命名约定,类似于 PSR-0 用于文件夹结构/命名空间,但用于类?
这似乎是多余的,因为该语言为此目的具有文字关键字。
abstract class AbstractFoo {}
interface InterfaceFoo {}
trait TraitFoo {}
尽管没有任何约定,但我认为对各个组件使用Abstract
前缀和Interface
后缀是一种很好的做法。它有助于一目了然地更好地理解代码,IMO。
PHP-FIG 项目确实通过 PSR 命名约定“ByLaw”建议了命名约定https://www.php-fig.org/bylaws/psr-naming-conventions/
它指出:
接口必须以接口为后缀:例如 Psr\Foo\BarInterface
抽象类必须以抽象为前缀:例如 Psr\Foo\AbstractBar
Traits 必须以 Trait 为后缀:例如 Psr\Foo\BarTrait
这些约定通常在包中遵循
对此没有约定。特别是在 PHP 中。这一切都可以按照您的意愿进行组织。
随着 PHP 5.3 中命名空间的添加,我认为不需要在实际类名中添加Abstract
或前缀/后缀。Interface
只需按原样命名即可!
与大多数其他答案相反,我建议最好不要在类中添加前缀或后缀。该语言具有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';
}
}
接口必须以 Interface: 为后缀e.g. Psr\Foo\BarInterface
。
抽象类必须以 Abstract: 为前缀e.g. Psr\Foo\AbstractBar
。
特征必须以 Trait: 为后缀e.g. Psr\Foo\BarTrait
。
使用以下命令命名抽象类和接口:
将使您的代码库保持干净、美观且对您的团队显而易见,原型是什么,合同是什么以及具体的实现是什么。
在任何情况下,命名约定都是为了提高我们的生产力,因此“随心所欲地命名”远非好主意。
尽管 FIG 小组没有提出抽象类和接口的命名约定——如果您查看主要的开源 PHP 项目,您会发现几乎所有项目都使用这种约定。
约定就是您所看到的:语言本身不会强制执行任何约定,除了那些使解析器能够读取您的代码的约定。基本上,您应该为特定项目自行设置约定,或者更好地为所有项目设置约定。但是,在不同人的团队中工作可能会导致不遵守约定,这实际上取决于程序员。
根据我的经验,我建议遵循“按合同设计”之类的方法。像命名实现类一样命名您的合约(接口),然后给您的实现一个更具体的名称(或回退到 MyContractNameImpl,我猜主要来自 Java)。此外,许多现代 IDE 都知道您的类是接口还是抽象类,因此实际上没有必要将其放在它的名称中。出于同样的原因,我还发现名为“IMyContract”的合同并不是很好。