3

私は多くの someInterface - someInterfaceImpl-pairs を持つプロジェクトに取り組んでいます。数日前、デフォルトの実装を内部クラスとして含めるというアイデア (おそらく、目的の C コードを読んだことに触発されたもの) を思いつきました。現在、何人かの同僚 (全員が私より Java の経験が豊富) がこのアイデアに気づき、フィードバックはショックと驚きの間でした (「これは機能していますか?」)。

私は少しグーグルで検索しましたが、この「パターン」の有用性の証拠はあまり見つかりませんでした (個人的には気に入っています): pdf-paper and a faq about code style

特に「デフォルト」の実装がインターフェースに密接に結合されている場合はどう思いますか。

更新 私はこれを見つけました：Java Interface-Implementation Pair

（受け入れられた回答を参照）

4

3 に答える 3

8

インターフェイスの要点は、ユーザーを実装から分離することです (デフォルトかどうかに関係なく)。実装を内部クラスとして含めることで、これを無効にします。コード行をまったく保存せず、API を乱雑にします。内部クラスをインターフェイスのユーザーから非表示にするために、内部クラスをプライベートまたはデフォルトのスコープにするなど、回避する方がよい場合があります。また、デフォルトの実装を変更する必要があるが、インターフェースを API の一部として公開している場合はどうでしょうか。これはあまりメリットがなく、アンチパターンであるという点で悪い考えです。

最後に、本当にデフォルトの実装がある場合は、おそらくそれは (インターフェイスではなく) 基本クラスであり、他の実装はクラスを拡張して動作をオーバーライドする必要があります。

この投稿は、同様の質問に関する興味深い議論を提供すると思いました: 質問

于 2012-06-04T16:06:28.027 に答える
1

上記の回答に同意しますが、次のように、実装を含めることが論理的である場合がいくつかあります。

  • 匿名関数を書いている (インターフェイスにメソッドが 1 つしかなく、関数型言語の匿名関数のように使用している) のは問題ありませんが、まれです。
于 2012-06-04T16:23:03.963 に答える
1

デフォルトの実装がかなり些細なものであり、そのままの状態が続く可能性が高く、それを拡張するものが何もない場合、またはそうする可能性が低い場合は、これがおそらく進むべき道です。それを独自のファイルに入れたくありません。他にどこに入れますか? クラスをパブリックインスタンスでプライベートにすることをお勧めします（状態がない場合）：

/** An interface a lot like java.util.Collection. */
public interface WhatEver  {
    private class Default  implements Whatever  {
        // Methods...
    }
    /** A default implementation that is always empty.  Suitable as a NULL value. */
    public final WhatEver  DEFAULT = new Default();
    // Rest of interface...

実行に違いはないと思いますが (クラス インスタンスにデータはありません)、より良い Javadoc が得られるでしょう。また、匿名クラスを使用してコード行を節約できます。

他の「デフォルト」インスタンスがいくつか必要になる場合もあります。コレクションのようなインターフェイスの場合、単一のデフォルト エントリ、または同じデフォルト エントリの無限の数 (hasNext常に を返す) を持つものがあります。true

キーは、デフォルトの実装がインターフェースの外部に依存できないことだと思います。適切なインターフェイスの本体で参照されていない限り、外部のクラスとインターフェイスを使用しないでください。また、デフォルトを拡張する外部のクラスも使用しないでください。インターフェースは、インターフェースの標準的な考え方を少し超えていますが、それでも独立しています。

もう 1 つの重要なポイントは、1 つの .java ファイルにコードを入れすぎないようにすることですが、少なすぎてもいけません。

于 2012-06-04T20:35:56.773 に答える