Javaでは複数種類を達成することを可能にするインターフェースと抽象クラスを定義するために使用することができるが、インターフェースと抽象クラスは、2つの主な相違点を有します。
- 抽象クラスは、特定のメソッドを含む実現を可能にする、インタフェースが許可されていない[Java8は、デフォルトの方法で提供されています]
- 設計の観点から、抽象クラスによって定義された型を達成するために、クラスは、クラス図でそのレベルを制限する抽象クラスのサブクラスとして定義されなければならないが、インターフェースは、制限のこのレベルではありません。
実際の開発では、我々は原則に従うべきである - インターフェイスは、抽象クラスよりも優れている、主としてインタフェースに3つの領域での利点があります。
- 限り、新しいインターフェースの実現として、既存のクラスに新しい機能を追加することができます。しかし、このクラスは、親クラスから継承することができます。
- これは、ミックスイン（ハイブリッド型）を定義するのに非常に適しています。同等のオブジェクトの任意のタイプは、それらの主な機能と混合したオブジェクトを、比較する能力を提供するためにこのインタフェースを実装することができるためであるミックスインのインタフェースです。
- インターフェイスは、厳密なデザインで、それはより柔軟な実装するクラスのレベルを必要とされていません。
コーミング知識
Javaの抽象クラス
クラスとインタフェースの間の共通の抽象クラスを設計し、ターゲットは一般的な設計のための抽象クラスで、それは複数種類を達成することができます。
抽象クラスと呼ばれるクラスの抽象メソッドが含まれています。クラスは抽象クラスを継承する場合は、抽象クラスは、インスタンス化することはできない、とあなたがインスタンス化したい、抽象クラスを実装する必要がありますすべての抽象メソッド。
Javaでアプリケーションの抽象クラス、最も古典的には、「スケルトンモデル」である - とのインターフェースを使用して、できるように設計者はまた、抽象クラスとインタフェースの利点を持っている - システムを可能にしながら、抽象クラスの進化は、インタフェースの進化よりも簡単です他のクラスは、このスケルトン実装クラスを使用しないでください。
「スケルトンモデル」では、インターフェースの役割はまだ定義されているタイプは、スケルトン実装クラスは、インタフェースに関連するすべての作業を担当する抽象クラスです。例えば、フレームワーク「骨格モデル」の大規模なセットのアプリケーション、：AbstractCollection、AbstractList、クラスAbstractMapとAbstractSet、いくつかの一般的な操作はスケルトン実装クラスに実装され、このようなコンクリートのArrayListとLinkedListのは、それらの特性を達成することに集中することができ重複したコードを書くことは避けてください。
「スケルトンモデルは、」ビットテンプレートメソッドデザインパターンのように聞こえるが、両者の間に残っています同じではありません：「スケルトンモデル」は、コードレベルからコードの重複を避けるためです目標、「テンプレート方式」の目標は、設計レベルであります抽象的なものと拡張ポイントの特定のタイプのために設計されています。
Javaインタフェース
Javaインタフェースでのセマンティクスは「似ている」さ - インターフェイスにこの能力を持っているようにインターフェイスを実装するクラスは、それが見えます。
Javaでは、インターフェースは、3つのことを行うために使用することができます。
- 型定義。
- いくつかの定数を保存するための一定のインタフェースとして、
- ラベルとしてのみ。
ただし、第19条では「効果的なJavaは、」インタフェースのみのタイプを定義するために使用されるべきであると指摘しました。
Java8前に、唯一の実装が発生しないことができ、発生する可能性がありますインターフェイスメソッドで宣言されました。インターフェイスの強化を行うためのJava 8の能力：
- インタフェースは、デフォルトの方法であってもよいです。
- インターフェースは、静的方法であってもよいです。
- これは、この概念FunctionInterface提供します。
インタフェースの多くのオリジナルJDKを変更する必要があるのJava 8のラムダ式、でサポートされるように、しかし、界面の特性（その実装クラスがでインターフェイスを実装する必要があります。1.Java 8は、デフォルトの方式のための主な動機がある導入しましたこれは容認できない - 直接変更した場合に宣言されたすべてのメソッド）の限界が、それはすべての時に、Javaに8コンパイラエラーをアップグレードするために、既存のJavaアプリケーションにつながります。
実際の開発では、使用するデフォルトの方法のために、あなたはいくつかの点に注意を払うことができます。
- 既存の実装クラスの影響を心配することなく、インタフェースを拡張する必要性に従うことができます。
- 抽象クラスとインタフェースほとんど差がないように、および利点は、デフォルトの方法抽象クラスを使用して得ることができるが、安全に、使用されるインタフェースの背後に得ることができます。
- インタフェースを提供するためのツールの多くを保存し、これらのツールのようにこのクラスのメソッドとして、インターフェース上に実装することができるコレクションがCollectionインタフェースに配置されていることができます。
2は、同様のデフォルトの方法で、静的メソッドは、インタフェースで実装することができますが、もちろんで静的メソッドをカバーすることはできません、あなたが特定のカテゴリを破壊されないようにする方法がある場合、したがって、それは文が静的方法であってもよいです。
実際の開発では、静的メソッドを使用して、あなたはいくつかの点に注意を払うことができます。
- 静的メソッドは、オブジェクトに属していない、インターフェイスに属します。
- 静的方法は、例えばチェックヌル、設定順序などに、インタフェース手段に係る方法を実施するのに適しています。
- 簡単に対応する方法を見つけるために、開発者を有効にするモバイルインターフェースにメソッドコレクションコレクションは、このメソッドは静的メソッドを使用することも適しています。
図3は、ラムダ式をサポートするために、Javaの8は新しいコメントが導入されています。
@FunctionalInterface //メソッド注
インタフェースはこのコメントを変更されている場合、このインターフェースは、機能インタフェースと呼ばれます。機能注釈のインターフェイスが必要ですが、お勧めしていません。
インターフェースマッチング「機能インターフェイス」が定義されている場合は、ノートをやったは影響を受けません。プラスノートは、より良いコンパイラがチェックするようにします。書き込みが機能インタフェースではなく、@FunctionInterfaceを追加した場合、コンパイラは文句を言うでしょう。。