コレクションへのインターフェース参照を使用します。それは良いコーディング慣行のためだけですか、それともその背後にいくつかのロジックがありますか?誰か説明できますか?
例えば:
を使用しております
Map<String, Integer> map = new HashMap<String,Integer>();
それ以外の
HashMap<String, Integer> map = new HashMap<String,Integer>();
コレクションへのインターフェース参照を使用します。それは良いコーディング慣行のためだけですか、それともその背後にいくつかのロジックがありますか?誰か説明できますか?
例えば:
を使用しております
Map<String, Integer> map = new HashMap<String,Integer>();
それ以外の
HashMap<String, Integer> map = new HashMap<String,Integer>();
これにより、将来的に透過的に実装をinterface
変更できるようになります(クライアント側で多くの変更を行う必要はありません)。
例えば:
Map<String, Integer> map = new LinkedHashMap<String,Integer>();
実装をLinkedHashMapに変更しても、クライアントは自分の側で変更を加える必要はありません。
使用する場合
HashMap<String, Integer> map = new HashMap<String,Integer>();
クライアントは実装と緊密に結合されています。実装を変更する場合は、クライアントも変更する必要があります。
1つの欠点は、実装固有のメソッドを使用する場合は、対応するタイプにキャストして使用する必要があるということです。
HashMap
実装を使用する場合はに固有になりますHashMap
が、使用する場合は将来的Map
に任意に変更できます。Map Implementation
項目52:効果的なJavaからのインターフェースによるオブジェクトの参照を読むことができます。
アイデアは、実装ではなく、コンポーネントのコントラクトにコーディングすることです。java.util.Mapには多くの実装があり、コードがインターフェースのみに依存している場合は、必要に応じてシームレスに交換できます。
一般に、緩い結合は良い習慣です。
コードのメンテナンスは1つの利点です。誰かが他のコンクリートを使用したい場合は、Map
数十行に対して1行だけを変更する必要があります。コードスニペットの例では、オブジェクト参照の使用がパラメータとリターンタイプで一般的になっている場合にのみ、問題が発生するようには見えない場合があります。これらの問題を引き起こすコードを書く傾向を避けるために、オブジェクトよりも「インターフェースで考える」ことから始める方が良いと思います。ここでAllenHollubを引用
特定のクラスによる実際の実装ではなく、インターフェイスによって保証される機能のみに関係するようにクライアントコードを記述した場合、将来、実装を変更する自由が広がります。
次のようなもので-
class MapTest {
Map<String, Integer> map;
public MapTest(Map<String, Integer> map) {
this.map = map;
}
public void setMap(Map<String, Integer> map) {
this.map = map;
}
//do stuffs with map
}
のさまざまな実装を渡すことができますMap
。ただしmap
、タイプがタイプの場合は、HashMap
常にHashMap
(またはサブクラス化する場合はサブクラス)である必要があります。
最初のアプローチは、2番目のアプローチよりもはるかに柔軟です。
Map<String, Integer> map = new HashMap<String,Integer>();
TreeMap
このように、代わりに使用する場合は、1行だけ変更する必要があります。
また、セットを操作するメソッドは、次のタイプのパラメーターを指定する必要がありますMap
。
public static void print(Map<String, Integer> s)
その後、このメソッドはすべてのマップ実装に使用できます。
理論的には、リンクリストに対して同じ推奨事項を作成する必要があります。つまりLinkedList
、タイプの変数に参照を保存する必要がありますList
。