Javaでのインターフェースの命名[終了]

ほとんどのOO言語は、インターフェース名の前に大文字のIを付けています。なぜJavaはこれを行わないのですか？この規則に従わない理由は何でしたか？

つまり、ユーザーインターフェイスとユーザー実装が必要な場合は、Javaで2つの選択肢があります。

1. クラス=ユーザー、インターフェース=ユーザーインターフェース
2. クラス= UserImpl、インターフェース= User

ほとんどの言語で：

クラス=ユーザー、インターフェース= IUser

今、あなたは常にユーザー実装に最も説明的な名前を選ぶことができ、問題はなくなると主張するかもしれませんが、Javaは物事へのPOJOアプローチを推進しており、ほとんどのIOCコンテナーはDynamicProxiesを広範囲に使用しています。これら2つのことを合わせると、1つのPOJO実装で多くのインターフェースができることになります。

つまり、私の質問は次のように要約されていると思います。「特に、Javaフレームワークが向かっているように見える場所を考慮して、より広いインターフェース命名規則に従う価値はありますか？」

私はインターフェースでプレフィックスを使用したくない：

• 接頭辞は読みやすさを損ないます。

• クライアントでインターフェイスを使用することは、プログラミングの標準的な最良の方法です。そのため、インターフェイス名はできるだけ短く、わかりやすいものにする必要があります。クラスの実装は、使用を阻止するために醜くする必要があります。

• 抽象クラスからインターフェースに変更するとき、接頭辞付きのコーディング規約は、クラスのすべてのオカレンスの名前を変更することを意味します---良くありません！

本当に違いはありますか：

class User implements IUser

そして

class UserImpl implements User

私たちが話しているすべてが命名規則であるなら？

個人的には、インターフェースのIコーディングをしたいので、インターフェースの前に置かない方が好きで、命名規則の観点からは、それがより重要であると考えています。インターフェースを呼び出す場合IUser、そのクラスのすべてのコンシューマーはそのを知る必要がありIUserます。クラスを呼び出すと、クラスUserImplとDIコンテナーImplだけがパーツを認識し、コンシューマーはで作業していることだけを認識しますUser。

繰り返しになりますImplが、適切な名前が表示されないために使用を余儀なくされた回数は、実装に応じて名前が付けられるため、ほとんどありません。

class DbBasedAccountDAO implements AccountDAO
class InMemoryAccountDAO implements AccountDAO

Javaが一般にIUser規則を使用しない理由はいくつかあります。

1. オブジェクト指向アプローチの一部は、クライアントがインターフェースを使用しているか、実装クラスを使用しているかを知る必要がないことです。そのため、ListがインターフェースでStringが実際のクラスである場合でも、メソッドは両方に渡される可能性があります。インターフェースを視覚的に区別しても意味がありません。

2. 一般的に、実際にはクライアントコードでのインターフェイスの使用を優先します（たとえば、ArrayListよりもListを優先します）。したがって、インターフェイスを例外として目立たせることは意味がありません。

3. Javaの命名規則では、ハンガリー語スタイルの接頭辞よりも実際の意味を持つ長い名前を優先しています。そのコードは可能な限り読みやすくなります。リストはリストを表し、ユーザーはIUserではなくユーザーを表します。

Springを含む多くのオープンソースプロジェクトで使用されている別の規約もあります。

interface User {
}

class DefaultUser implements User {
}

class AnotherClassOfUser implements User {
}

私は個人的に、「I」接頭辞がオプションの規則であるという単純な理由で、好きではありません。これを採用すると、IIOPConnectionはIOPConnectionのインターフェースを意味するのでしょうか？クラスに「I」プレフィックスがない場合はどうなりますか？それから、インターフェースではないことを知っていますか？ここでは答えはノーです。これは、規則が常に守られているわけではないためです。

別のポスターが言ったように、タイプではなく機能を定義するインターフェースを持つことが一般的に望ましいです。私は「ユーザー」のようなものを「実装」する傾向はありません。そのため、ここで説明する方法では「IUser」は必ずしも必要ではないことがよくあります。私はしばしばクラスを名詞と見なし、インターフェースを形容詞と見なしています。

class Number implements Comparable{...}  
class MyThread implements Runnable{...}
class SessionData implements Serializable{....}

時々形容詞は意味をなさないかもしれませんが、私はまだ一般的に振る舞い、アクション、機能、プロパティなどをモデル化するためにインターフェースを使用しています...型ではありません。

また、本当に1人のユーザーを作成し、それをユーザーと呼ぶつもりなら、IUserインターフェイスも持つ意味は何ですか？また、共通のインターフェースを実装する必要があるいくつかのタイプのユーザーがいる場合、インターフェースに「I」を追加すると、実装の名前を選択するときに何が節約できますか？

より現実的な例としては、特定のAPIにログインできるようにする必要があるタイプのユーザーがいるでしょう。Loginインターフェースを定義し、SuperUser、DefaultUser、AdminUser、AdministrativeContactなどのサブクラスを持つ「User」親クラスを作成できます。これらの一部は、必要に応じてLogin（Loginable？）インターフェースを実装するか、実装しません。

ボブ・リーはプレゼンテーションで一度言った：

実装が1つしかない場合のインターフェースの要点。

したがって、1つの実装、つまりインターフェースなしで開始します。後で決めるのは、まあ、ここにインターフェイスが必要なので、クラスをインターフェイスに変換することです。

その後、それが明らかになります。元のクラスはUserと呼ばれていました。あなたのインターフェースは現在Userと呼ばれています。多分あなたはUserProdImplとUserTestImplを持っています。アプリケーションを適切に設計した場合、すべてのクラス（Userをインスタンス化するクラスを除く）は変更されず、突然インターフェイスに渡されることに気付かないでしょう。

そのため、明らかになります->インターフェイスユーザー実装UserImpl。

C＃では

public class AdminForumUser : UserBase, IUser

Javaは言うだろう

public class AdminForumUser extends User implements ForumUserInterface

そのため、継承とインターフェイスの実装には明確な違いがあるため、インターフェイスのJavaでは規約はそれほど重要ではないと思います。一貫性があり、インターフェースであることを人々に示すために何かを使用している限り、好きな命名規則を選択するだけです。数年でJavaを実行していませんが、すべてのインターフェイスは独自のディレクトリにあり、それが慣例でした。実際には問題はありませんでした。

私の経験では、「I」の規則は、特にインターフェース自体がクラスの抽象的な概念ではない場合に、クラスへのコントラクトを提供することを目的としたインターフェースに適用されます。

たとえば、あなたのケースでは、あなたIUserが持っているつもりの唯一のユーザーがであるかどうかを確認することだけを期待していますUser。-あなたは、ユーザーのさまざまな種類持つように計画している場合NoviceUser、ExpertUserなどを、 -私が見ることを期待するUserインターフェース（と、おそらく、AbstractUserクラス実装はいくつかの共通の機能、のようなことをget/setName()）。

また、機能を定義するインターフェース-、、- などComparableはIterable、そのように名前が付けられており、IComparableまたはのような名前ではないことを期待しますIIterable。

適切なOO原則に従って、コードは（実用的/可能な限り）具体的なクラスではなく抽象化に依存する必要があります。たとえば、一般的には次のようなメソッドを記述する方が適切です。

public void doSomething(Collection someStuff) {
    ...
}

これより：

public void doSomething(Vector someStuff) {
    ...
}

このアイデアに従えば、 "IUser"や "UserInterface"などのバリエーションではなく、 "User"や "BankAccount"などのインターフェイス名を指定すると、コードが読みやすくなると思います。

実際の具象クラスに注意する必要があるコードは、具象クラスが構築される場所だけです。その他はすべて、インターフェースを使用して作成する必要があります。

これを行う場合、「UserImpl」などの「醜い」具象クラス名は、コードの残りの部分から安全に非表示にする必要があります。これにより、「素敵な」インターフェース名を使用できます。

= v =「I」接頭辞はWicketフレームワークでも使用されており、すぐに慣れました。一般に、面倒なJavaクラス名を短くするあらゆる規約を歓迎します。ただし、ディレクトリとJavadocの「I」の下にすべてアルファベット順になっているのは面倒です。

Wicketのコーディング方法はSwingに似ていますが、多くのコントロール/ウィジェットインスタンスは、インラインメソッド宣言を持つ匿名の内部クラスとして構築されます。厄介なことに、Swingは実装クラスに接頭辞（ "J"）を使用するという点でSwingと180°異なります。

「Impl」サフィックスは、非常に複雑な略語であり、国際化がうまくいっていません。少なくとも "Imp"を使用していれば、それはよりかわいい（そしてより短い）でしょう。"Impl"はIOC、特にSpringに使用されているので、今のところはそれにこだわっています。ただし、1つのコードベースの3つの異なる部分にある3つの異なる規則に従って、少し簡単になります。

これは、本当の意味でのより広い命名規則ですか？私はC ++のほうが好きで、Javaやその子孫についてはあまり気にしていません。I規約を使用する言語コミュニティはいくつありますか？

ここに言語に依存しないショップ標準の命名規則がある場合は、それを使用してください。そうでない場合は、言語の命名規則に従ってください。