Javaコレクションを意味のあるクラス名でマスクする良い習慣か悪い習慣ですか？

最近、私は人間に優しいクラス名でJavaコレクションを「マスキング」する習慣を身につけています。いくつかの簡単な例：

// Facade class that makes code more readable and understandable.
public class WidgetCache extends Map<String, Widget> {
}

または：

// If you saw a ArrayList<ArrayList<?>> being passed around in the code, would you
// run away screaming, or would you actually understand what it is and what
// it represents?
public class Changelist extends ArrayList<ArrayList<SomePOJO>> {
}

同僚が私に、これは悪い習慣であり、ラグ/レイテンシーをもたらし、オブジェクト指向のアンチパターンであることを指摘しました。非常にわずかなパフォーマンスオーバーヘッドが発生することは理解できますが、それがまったく重要だとは想像できません。だから私は尋ねる：これは良いことか悪いことか、そしてその理由は？

遅延/遅延？私はその上でBSを呼び出します。このプラクティスによるオーバーヘッドはまったくゼロになります。（編集：この缶は、実際には、禁止の最適化は、HotSpot VMのことで実行したことをコメントで指摘されてきた私が確認するために、VMの実装について十分に知っているか、これを否定していない私は、Cのオフに私のコメントを基づかた++。仮想関数の実装。）

いくつかのコードのオーバーヘッドがあります。必要な基本クラスからすべてのコンストラクターを作成し、パラメーターを転送する必要があります。

また、それ自体がアンチパターンだとは思いません。しかし、私はそれを逃した機会だと考えています。名前を変更するためだけに基本クラスを派生するクラスを作成する代わりに、コレクションを含み、ケース固有の改善されたインターフェースを提供するクラスを作成しますか？ウィジェットキャッシュは、実際にマップの完全なインターフェイスを提供する必要がありますか？または、代わりに特殊なインターフェイスを提供する必要がありますか？

さらに、コレクションの場合、パターンは単に実装ではなく、インターフェイスを使用する一般的なルールと一緒に機能しません。つまり、プレーンコレクションコードでは、を作成しHashMap<String, Widget>、それをtypeの変数に割り当てますMap<String, Widget>。をWidgetCache拡張することはできませんMap<String, Widget>。これはインターフェースだからです。基本インターフェイスを拡張するインターフェイスにすることHashMap<String, Widget>はできません。そのインターフェイスは実装されておらず、他の標準コレクションも実装していないためです。そして、それを拡張するクラスにすることができますがHashMap<String, Widget>、変数をWidgetCacheor として宣言する必要Map<String, Widget>があり、最初のコレクションは別のコレクション（おそらくORMの遅延読み込みコレクション）を置き換える柔軟性を失い、2番目の種類はポイントを無効にしますクラスを持つことの。

これらのカウンターポイントのいくつかは、私の提案する専門クラスにも適用されます。

これらはすべて考慮すべき点です。正しい選択である場合とそうでない場合があります。いずれの場合も、同僚が提示した議論は無効です。もし彼がそれがアンチパターンだと思ったら、彼はそれに名前を付けるべきです。

IBMによると、これは実際にはアンチパターンです。これらの「typedef」のようなクラスは、疑似タイプと呼ばれます。

この記事では、私よりもずっとよく説明していますが、リンクがダウンした場合に備えて要約しようと思います。

• を予期するコードWidgetCacheはMap<String, Widget>
• 複数のパッケージを使用する場合、これらの疑似タイプは「バイラル」であり、非互換性をもたらしますが、ベースタイプ（単なる愚かなMap <...>）はすべてのパッケージですべてのケースで機能します。
• 疑似型は具体的な場合が多く、基本クラスはジェネリックバージョンのみを実装するため、特定のインターフェイスは実装しません。

この記事では、疑似型を使用せずに作業を簡単にするために、次のトリックを提案しています。

public static <K,V> Map<K,V> newHashMap() {
    return new HashMap<K,V>(); 
}

Map<Socket, Future<String>> socketOwner = Util.newHashMap();

自動型推論により機能します。

（私はこの関連するスタックオーバーフローの質問を介してこの答えに来ました）

パフォーマンスヒットはせいぜいvtableルックアップに制限されますが、これはおそらく既に発生しています。それはそれに反対する正当な理由ではありません。

状況は十分に一般的であり、ほとんどすべての静的に型付けされたプログラミング言語は、通常aと呼ばれる、型をエイリアスするための特別な構文を持っていますtypedef。Javaは、元々パラメータ化された型を持っていなかったため、おそらくそれらをコピーしませんでした。クラスを拡張することは、Sebastianが答えで非常によく説明しているため、理想的ではありませんが、Javaの限られた構文の合理的な回避策になる可能性があります。

Typedefには多くの利点があります。より適切な抽象化レベルで、より良い名前でプログラマーの意図をより明確に表現します。デバッグやリファクタリングの目的で検索する方が簡単です。a WidgetCacheが使用されているすべての場所を見つけることと、aの特定の使用を見つけることを検討してくださいMap。変更が簡単です。たとえば、後でLinkedHashMap代わりに、または独自のカスタムコンテナが必要になった場合などです。

既に述べたように、継承よりも合成を使用することをお勧めします。そのため、実際に必要なメソッドのみを公開し、目的のユースケースに一致する名前を付けることができます。クラスのユーザーは、それWidgetCacheがマップであることを本当に知る必要がありますか？そして、彼らが望むものは何でもできるのでしょうか？または、ウィジェットのキャッシュであることを知る必要がありますか？

あなたが記述した同様の問題の解決策を備えた私のコードベースのクラスの例：

public class Translations {

    private Map<Locale, Properties> translations = new HashMap<>();

    public void appendMessage(Locale locale, String code, String message) {
        /* code */
    }

    public void addMessages(Locale locale, Properties messages) {
        /* code */
    }

    public String getMessage(Locale locale, String code) {
        /* code */
    }

    public boolean localeExists(Locale locale) {
        /* code */
    }
}

内部的には「単なる地図」であることがわかりますが、パブリックインターフェイスには表示されません。そして、appendMessage(Locale locale, String code, String message)新しいエントリを挿入するより簡単で意味のある方法のような「プログラマーに優しい」メソッドがあります。そして、クラスのユーザーが行うことができない、例えば、translations.clear()、理由はTranslations拡張されていませんMap。

オプションで、必要なメソッドの一部を内部的に使用されるマップにいつでも委任できます。

これは意味のある抽象化の例だと思います。優れた抽象化には、いくつかの特徴があります。

1. 消費するコードに関係のない実装の詳細を隠します。

2. 必要なだけ複雑です。

何セバスチャンREDLを示唆してやりたいと思いますので、拡張することによって、あなたは親のインタフェース全体を露出させているが、多くの場合、多くのことのより良い隠すことができる継承の上に好意組成をして、親のインスタンスを追加しますカスタムクラスのプライベートメンバー。抽象化に意味のあるインターフェースメソッドは、（この場合）内部コレクションに簡単に委任できます。

パフォーマンスへの影響については、最初にコードを読みやすいように最適化することをお勧めします。パフォーマンスへの影響が疑われる場合は、コードをプロファイリングして2つの実装を比較します。

ここで他の回答に+1します。また、ドメイン駆動設計（DDD）コミュニティによって実際に非常に良いプラクティスと見なされていることも付け加えます。彼らは、あなたのドメインとそれとの相互作用は、基礎となるデータ構造ではなく、セマンティックドメインの意味を持つべきだと主張します。A Map<String, Widget>はキャッシュかもしれませんが、他の何かかもしれません。あなたが正しくしていないこと（IMNSHO）は、コレクションが表すもの（この場合はキャッシュ）をモデル化することです。

基礎となるデータ構造のドメインクラスラッパーには、おそらくデータ構造だけではなく相互作用を持つドメインクラスになる他のメンバー変数または関数が必要になるという点で、重要な編集を追加します（Javaのみに値型がある場合） 、Java 10で取得します-約束！）

Java 8のストリームがこのすべてにどのような影響を与えるかを見るのは興味深いでしょう。おそらく、いくつかのパブリックインターフェイスは、Javaオブジェクトではなく（一般的なJavaプリミティブまたは文字列を挿入）のストリームを処理することを好むと想像できます。