LoginSignup
163
122

More than 5 years have passed since last update.

人生いろいろ、インターフェイス命名規則いろいろ

Posted at

「PHPのinterfaceの命名規約ってどういうのがいいんだろう?」

フレームワークや他言語の命名規則をあつめてみた。(パターン名は勝手にでっち上げたものであり、実在の人物・団体・事件などとは一切関係ありません。 )

○とか☓と書いたのは個人的な感想です。どれが優れている劣っているという主張ではありません。炎上しないでください><。

I-接頭辞パターン

I をインターフェイス名の頭につけるパターン。それを実装するクラスは I を取り除いたインターフェイス名を引き継ぐ。.NETやJavaで見かけます。

<?php
interface IUser {}
class User implements IUser{}
  • ○ 慣れればインターフェイスだと比較的分かりやすいかも。
  • ○ ファイル名でソートしたときに、インターフェイスが集まる。
  • × Iが見えにくい。細い。
  • × ハンガリアン記法っぽくて。

小文字 I-接頭辞パターン

I接頭辞パターンの小文字版です。i 接頭辞をインターフェイス名の頭につけます。

<?php
interface iUser {}
class User implements iUser{}
  • ○ 慣れればインターフェイスだと比較的分かりやすいかも。
  • ○ ファイル名でソートしたときに、インターフェイスが集まる。
  • × iが見えにくい。細い。
  • × ハンガリアン記法っぽくて。
  • × PSR-0的に小文字なのに違和感。

-Interface接尾辞パターン

Interface をインターフェイスの後ろにつけるパターンです。Zend Frameworkの命名規則Google C++ Style Codeをはじめ、Javaなど複数の言語で見かけます。

<?php
interface UserInterface {}
class User implements User {}
  • ○ インターフェイスって分かりやすい。
  • ○ もうクラスがあって、それをインターフェイスに抽象化するときは、クラス名に接尾辞つけるだけ。
  • × インターフェイス定義だけ見ると冗長。
  • × 長い。

-able接尾辞パターン

-able をインターフェイスの後ろにつけるパターンです。PHPの一部のインターフェイス(Countableなど)やJavaなど他の言語にも見られます。

<?php
interface Serializable {}
class User implements Serializable {}
  • ○ 慣れればインターフェイスって分かりやすい。
  • ○ インターフェイス=能力と考えるとエレガント。
  • ○ クラス名との関連が疎になるので、複数 implements する場合に馴染みやすい。
  • × -ableは原則的に動詞につける接尾辞なので語彙力が問われる。
  • × IDEなどのスペルチェック警告に引っかかりやすい。
  • × 英語の-ableの文法的生産性はさほど高くない。

I--able接周辞パターン

I-接頭辞パターンと-able接尾辞パターンを組み合わせたパターンです。

<?php
interface ISerializable {}
class User implements ISerializable {}
  • ○ これだけ冗長的であればクラスと見間違うまい。
  • ☓ -ableパターンと同じ弱点がある。

-ing接尾辞パターン

-ing をインターフェイスの後ろにつけるパターンです。Objective-C Cococaの命名規則などでみることができます。

<?php
interface Locking {}
class Lock implements Locking {}
  • ○ 慣れればインターフェイスって分かりやすい。
  • ○ クラス名との関連が疎になるので、複数 implements する場合に馴染みやすい。
  • ○ 英語の-ingの文法的生産性は-ableより高い。
  • × -ingは原則的に動詞につける接尾辞なので語彙力が問われる。
  • × インターフェイス名は基本動詞という縛りができる。

-Implクラス接尾辞パターン

インターフェイス名には特別な接辞をつけず、そのインターフェイスを実装したクラスに Impl 接尾辞をつけるパターン。Javaなどで見られる。

<?php
interface User {}
class UserImpl implements User {}
  • ○ 抽象が先にあり、抽象に依存するイメージがあっていいかも。
  • × インターフェイスを実装したクラス全部にImplとつけるとごちゃごちゃしそう。
  • × Implという省略が好みじゃない。スペルチェックに引っかかりそう。

Interfaceネームスペースパターン

インターフェイス用に特別なネームスペースを設けるパターンです。命名規則というよりは設計に関する部分かもしれません。

<?php
interface Foo_Interface_User {}
class Foo_Model_User implements Foo_Interface_User {}
  • ○ PSR-0に従えば、Interfaceフォルダにインターフェイスが集まる。
  • × namespaceInterface を使うと予約語にひっかかる。

パスパターン

インターフェイスであることのヒントをネームスペースの階層で表現するパターンです。抽象はより浅いパスで表現され、実装はより深いパスで表現されます。

<?php
interface Foo_User {}
class Foo_User_Admin implements Foo_User {}
class Foo_User_Visitor implements Foo_User {}
  • ○ 冗長的情報(-Interfaceや-able)をつけなくていい。
  • ○ プロトタイプ的な発想が好き。
  • × 使う側でぱっと見インターフェイスと分かりにくい。
  • × 複数のインターフェイスを実装するケースには向かない。

無印パターン

インターフェイス名やクラス名にインターフェイスかどうか判断する符号をつけないパターンです。インターフェイスに接辞をつけてはならない規約を設定しているプロジェクトもあるでしょう。

<?php
interface FooBar {}
class Baz implements FooBar {}
  • ○ 臨機応変に名前をつけられる。
  • ○ 冗長的情報(-Interfaceや-able)をつけなくていい。
  • × クラス名とかぶるとめんどくさい。
  • × インターフェイスを使う側のコード(type-hintingとかuseとかinstanceof)でインターフェイスって分かりにくい。

おわり

さて、みなさんはどのパターンを使っていますか?他にも「こんなパターンもあるよ」というのがあれば教えてください!

163
122
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
163
122