今ではすべてがオブジェクトであると言って、言語、多くの同類をプログラミングするために、多くのプログラマが堪能では、実際に、私はプログラミングのように、この朗読上のオブジェクト指向のみの滞在の多くを連絡するだけでなく、「経験を習得し、OOPを誇っています「」スキル "。
Javaインタフェースと抽象クラスは、オブジェクト設計のための2つの基本的なメカニズムです。
インターフェースは抽象動作するように設計されて、それが抽象メソッドの集合である、APIインターフェースの使用が規定され、分離の目的を達成するために実装することができます。
インターフェイスは、インスタンス化することはできません。FNALのpublic staticの意味暗示されている任意のフェルドのいずれかの非constメンバが含まれていない。同時に、それはどちらかの抽象メソッド、静的メソッドである達成するために何の非静的な方法はありません。Javaの標準クラスライブラリ、などのjava.util.Listとして、インタフェースの多くを定義します。
Javaの8彼らはクラス定義、いわゆる機能インタフェースを追加しましたので、それは単に一つだけ抽象メソッドのインタフェースである通常のマークに@FunctionalInterface注釈を推奨され、関数型プログラミングのサポートを追加します。
Javaの8以降では、インタフェースはサポートのデフォルトのメソッドを追加します。でもJavaの9、および民間のデフォルトのメソッドの定義の後。デフォルトの方法は、既存のバイナリ互換インタフェースを拡張するためのアプローチを提供します。たとえば、私たちはのjava.util.Collectionが、それは、Java 8のデフォルトの一連の方法を追加し、ルートインターフェイス収集システムである知っている、主にラムダ、ストリーム関連の機能を向上させます。私はツールのような前の列と同様のコレクションに述べたように、多くの方法は、内部インターフェイスに基づいて達成するためのデフォルトの方法として適しています。
ない負けじとし、デフォルトの方法の導入は、個人が少しは金型を破った感じ。
抽象クラスは、キーワード抽象クラスによって変更され、インスタンス化されていない、その主な目的は、コードの再利用です。インスタンス化、およびJavaクラスの一般的な形態とあまり異ならないことに加えて、抽象メソッドではないが、一つ以上の抽象メソッドが存在してもよいです。方法または共通のメンバ変数を実装し、その後、継承方法を介してオブジェクトコードの再利用に到達関連するJavaクラスを抽出するための最も一般的な抽象クラス。多くの共通部分を抽出し、そのようなコレクションフレームとしてJavaの標準ライブラリは、抽象クラス、例えばjava.util.AbstractListなります。
カプセル化、継承、ポリモーフィズム：オブジェクトは、基本的な要素を重視します。
パッケージの目的は、非表示の実装にあるセキュリティと簡素化プログラミングを改善するために、内政を詳しく説明します。パッケージには、外部の発信者内部の詳細との接触を防止するために、合理的な境界を提供します。私たちの日々の開発、あまり詳細に起因する不注意にさらさ厄介なバグ、およびマルチスレッド環境での内部状態に、露光、同時変更は、問題が発生したため。別の観点からは、この隠されたパッケージには、発信者の回避エネルギーの無駄あまりにも多くの無意味な細部に単純インタフェースを提供します。
継承は、私たちが馬、白い馬、ダーク馬のためにまとめたものに類似したコードの再利用の基本的なメカニズムです。ただし、継承は非常に密結合の関係として見ることができ、親クラスのコードの変更は、サブクラスの動作が変更されます。実際には、相続の過度の乱用は、逆効果になることがあります。継承を避けるために組み合わせることができます。
最も簡単な例では、）（> <多型変換上向き、例えば、我々書く地図<K、V>マップ=新しいHashMapのです。
SOLID原則。
単一責任の単一責任、またはオブジェクトクラスは、我々はプログラム設計のクラスクマより多くの義務を見つけた場合、分割を考慮し、単一の責任を持つことが最善です。これはまた、低カップリングの戦略です。
開閉は、拡張のためのオープン、修正のために近く、開口部及び設計の原則を閉じるには、拡張のために開いているが、修正のために閉鎖すべきです。言い換えれば、プログラムはスムーズな拡張性を確保するように設計されるべきで、同様の新機能や変更を実現されているので、避けるようにしてください。
、親や地域の基底クラスとサブクラスに置き換えることができますすることができリスコフ置換、オブジェクト指向の基本的な要素の一つであるリヒターの交換、継承抽象的に行います、。
あなたはそれの一部でしかありませんインタフェース、サブクラスは、ジレンマに直面する可能性がある中、あまりにも多くのメソッドを定義する場合、インタフェースの分離は、インターフェースの分離は、我々はプログラムを損なわ有意義な方法である、クラスとインタフェースの設計を行って結束。我々は非常に低いレートのインタフェースを実現するために単一の多重化よりも多くを達成することができません。
逆に依存依存関係の反転は、エンティティが抽象的に依存すべきではなく、達成すること。そのハイレベルのモジュールは、低レベルのモジュールに依存していないはずですが、抽象的に基づくべきです。この原則の実践は、魔法の製品コード間の結合の適切度を確保することです。
Javaは学ぶことではない本当に良いです
するvar A = 新しいのArrayList <Integer型> （）; a.add（ 1）。
エラーの例
理論的には、このようなサービスコード改善、結合効率と低膨張差に一緒に接合されていません
終わり