What is our standard for naming interfaces and abstract classes?

As I've been doing a bit of refactoring in order to write tests for our AssetProvider I've been curious about how we want to name these interfaces I'm creating. It's worth keeping in mind that we have a good bit more flexibility now than we did previously in our naming because we can safely rename classes with aliases.

Interfaces

PSR-2 Bylaws

So the default to jump to here might be the PSR-2 naming conventions. These are not part of PSR-2. They are convention for PHP-FIG produced code. The long and short of it is:

• Suffix an interface with Interface.

Let's see a code sample in this style:

class WebpackAsset implements AssetInterface {
    public function __construct(RequestInterface $interface, CacheBusterInterface $cacheBuster) {}

    // implementation
}

Or another one.

class WebpackAssetProvider {
    public function __construct(
        RequestInterface $request,
        CacheBusterInterface $cacheBuster,
        AddonProviderInterface $addonProvider,
        ConfigurationInterface $configuration,
        LocaleInterface $locale
    ) {}

    // implementation
}

Mapping

In the end here our mapping from interface -> implementation would probably look something like this the way I tend to see things named:

• RequestInterface -> Request (Gdn_Request) & Fixtures\Request
• CacheBusterInterface -> CacheBuster
• AddonProviderInterface -> AddonProvider/AddonManager
• ConfigurationInterface -> Configuration/Gdn_Configuration
• LocaleInterface -> Locale/Gdn_Locale

Pros

• You can't mess up the names.
• You don't have to think about naming very much.
• When declaring implements things look pretty nice.

Cons

• These names are clunky. The don't really make sense at the time of usage. When I take the request, my code should feel and read like it's using the actual request. There is an interface here for testing purposes but it still feels weird.
• Our IDE (and the PHP runtime) both already enforce that we don't new up an interface. In this regard the naming is less useful. We also are trying to use new and use DI instead.

Laravel Style

Laravel does things a bit differently. They use the simplest possible naming for their interfaces and group them under a Contracts namespace.

I would propose that we use their Contracts where possible (increases) or organize our own similarly. In our case a few contracts we could define would be

• Contracts\Configuration -> GlobalConfiguration, MockConfiguration, SomeSpecificConfiguration.
• Contracts\Request -> Gdn_Request, Fixtures\Request
• Contracts\Addon -> Vanilla\Addon
• Contracts\AddonProvider -> Vanilla\AddonManager
• Contracts\CacheBuster -> DeploymentCacheBuster
• Contracts\TranslationProvider -> Gdn_Locale

Traits

PSR-2 Style

Suffix a trait with Trait.

Eg.

• AliasProviderTrait
• FormattableTextTrait
• PermissionsTranslationsTrait
• PrunableTrait
• DummyBreadCrumbTrait
• MiddlewareAwareTrait

Laravel Style

Name traits imperatively.

Eg.

• ProvidesAliases
• FormatsText
• TranslatesPermissions
• PrunesRecords
• ProvidesDummyBreadcrumbs
• ContainsMiddleware

In my opinion these are more straightforwards especially when reading their usage.

use TranslatesPermissions; vs use PermissionsTranslationsTrait;

Summary

I just felt like throwing this out there and am hoping you guys could chime in a bit.