PHP naming conventions about abstract classes and interfaces

Question

Should an abstract class always be prefixed with Abstract and suffixed with Interface (when it's an interface)? Is there any standard naming convention, similar to PSR-0 for folder structure/namespaces, but for classes?

It seems redundant as the language has literal keywords for this very purpose.

abstract class AbstractFoo {}

interface InterfaceFoo {}

trait TraitFoo {}

Answer 1

Although there's not any convention, I think it is a good practice using Abstract prefix and Interface suffix for respective components. It helps to understand better the code at a glance, IMO.

Answer 2

The PHP-FIG project indeed suggests a naming convention via the PSR Naming Convention "ByLaw" https://www.php-fig.org/bylaws/psr-naming-conventions/

It states:

• Interfaces MUST be suffixed by Interface: eg Psr\\Foo\\BarInterface

• Abstract classes MUST be prefixed by Abstract: eg Psr\\Foo\\AbstractBar

• Traits MUST be suffixed by Trait: eg Psr\\Foo\\BarTrait

These conventions are generally followed in packages

Answer 3

There isn't a convention for this; especially in PHP. This can all be organized however you'd like.

With the additions of namespaces in PHP 5.3, I don't see the need to add Abstract or Interface prefixes/suffixes to the actual class names.

Just name things as they are!

Answer 4

Naming your abstract classes and interface by using:

• Abstract*
• *Interface

Will keep your codebase clean, nice and obvious to your team what are the prototypes, what are the contracts and what are the concrete implementations.

Naming conventions are here to increase our productivity in any circumstance, so "name as you like" is far from good idea.

Even though FIG group does not propose naming convention for abstract classes and interfaces - if you examine major open source PHP projects, you will see that almost all of them uses this convention.

Answer 5

Going against most of the other answers, I would suggest that it's better not to add a prefix or postfix to the class. The language has literal keywords such as abstract, interface, class, final for this purpose.

The following actually breaks clean code principals:

abstract class AbstractPerson 
{

   // ...
}

Similar thinking to "comments are generally bad, as it suggests the code is not easily readable". If your classes, inheritance and their contracts are engineered in a clear and readable fashion that makes sense, there is no need for prefixing.

Behavioural design

It's usually possible to name things in a manner that reflects their behaviour. For example in a logging subsystem:

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 6

Conventions are what you see them like: the language itself doesn't force any conventions other than those that makes the parser able to read your code. Basically, you should have conventions set up on your own for a particular project, or better, for all of your projects. However, working in teams of different people could lead to conventions not being followed, it really depends on the programmers.

From my experience, I would suggest following something like "design-by-contract". Name your contracts (interfaces) like you would name your implementation class, and then give your implementation a more specific name (or fallback to MyContractNameImpl, known mostly from Java I guess). Also, many modern IDEs know whether your class is an interface or abstract, so there is really no need to put that in it's name. I also find contracts named like "IMyContract" not really good, for the same reasons.

Answer 7

Interfaces:

Interfaces MUST be suffixed by Interface: eg Psr\\Foo\\BarInterface .

---

Abstract classes:

Abstract classes MUST be prefixed by Abstract: eg Psr\\Foo\\AbstractBar .

---

Traits

Traits MUST be suffixed by Trait: eg Psr\\Foo\\BarTrait .

---

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