反射機構のコンセプト
私たちはシナリオを考え、私たちはプログラム、あなたは彼らが独自のプロパティを表示するオブジェクトのメンバを実行する場合、それがどのように動作しますか？
私たちは、そのプロパティ、コンストラクタ、一般的なアプローチとして、実行時にクラスのクラスに関する情報を取得すると、その後、どのようにそれを行うには、このような状況をそのオブジェクトを作成するかどうかを検討している場合その後、別のシナリオを検討？どこ反射なのです！
私たちは、コンパイル後の.javaファイルは、実際には、彼らが同じで、ミラー内の.classは、ミラー自体は.javaファイルであるように、それはだ、の.classファイルになります。
同じトークンだから、我々は逆コンパイルすることができます、ミラーで反射が.classファイルで見る、私は本当の色の.javaファイルを学びました。
反射の概念については、公式を与えられた：リフレクションは、実行時間（ノートではないコンパイル時）のプログラムは自己検査と内部動作のメンバーを遂行することを可能にするJava言語の機能です。
例：これは、Javaクラスは、そのすべてのメンバ変数やメソッドを取得し、表示することができます。
一次反射手段は、自身の状態や動作を検出して修正する能力をプログラムにアクセスし、アプリケーションの状態と関連する挙動セマンティクスに記載されているように行動し、結果の状態に応じて、調整または改変することができます。
Javaでは、単に特定のクラスに名前を付けるために、あなたはリフレクション経由クラスにすべての情報を得ることができます。
Javaがアセンブリコードは、コンポーネント間のソースコードのリンクせずに、再び時に実行することができ、私たちは簡単に柔軟なコードを作成することを可能にする強力なツールに反映されています。
しかし、高反射が誤っ要することができます！どのような種類の情報は、どのような情報の反射を利用して取得することができますが、前提は、クラスの名前を知っている必要があります。
ROLEの反射機構
1.いずれかのオブジェクトは、実行時にクラスに属する分析します。
実行時にオブジェクトクラスを取得します。2.。
3.アクセスJavaは実行時のプロパティ、メソッド、施工法等でオブジェクト。
私たちは、最初の理由は、使用リフレクションを把握しなければなりませんか？直接ではなく、動的および静的な概念を伴う、まだその上にオブジェクトを作成します。
静的にコンパイル：すなわちを通じて、オブジェクトを結合、コンパイル時の型で決定。
動的コンパイル：オブジェクトを結合、実行しているのタイプを決定します。動的にコンパイルされたJavaのクラス間の結合を低減することがあり、多型がアプリケーションを反映し、柔軟性を最大化します。
III。長所と反射の欠点
リフレクション利点：あなたは、動的オブジェクトを作成し、コンパイルすることができ、大きな柔軟性反映（特にその柔軟性のパフォーマンスには、J2EEの開発に明白です）。
私たちは、デコンパイル反射によって、コンテンツのクラスの多様性を得ることができます。JAVA言語コンパイラはこれを最初に実行するために、反射機構は、コードをより柔軟に行うことができますし、簡単にオブジェクト指向実装します。
例えば：
大規模なソフトウェアは、それがこのプログラムをコンパイルした後、公開、完全にデザインを入れることは不可能であり、特定の機能を更新する必要が見つけたとき、私たちは、ユーザーが以前の再インストール新しいをアンインストールすることはできませんバージョン、
もしそうなら、このソフトウェアは、多くの人が使用し、確かではありません。静的は、その後、プログラム全体を再コンパイルする必要性は、それがアンインストールすることはできません、リフレクションを使用しながら、唯一の更新機能いったん達成することができ、
のみ、動的に作成してコンパイルする必要があり、実行時にこの機能を実現することができます。
反射の欠点：パフォーマンスへの影響。リフレクションを使用して、基本的な解釈の操作で、我々は我々がやると、それは我々の要求を満たすようにしたい、何JVMを伝えることができます。このような操作は、常に直接同じ操作を実行するよりも遅いです。
4 .IOCコンテナのテクニカル分析
IOC最も基本的な技術は、「リフレクション（反射）」プログラミング、人気のある用語である、動的に生成されたオブジェクトが、最終的に決定された唯一のプログラミングモードを可能に与えられたクラス名（文字列）に基づいてオブジェクトを生成することですオブジェクトの種類。
ただ、設定ファイルで指定した春・オブジェクト定義で生産されるように、目的は、柔軟性と保守性を向上させることです。
現在、C＃、Javaとも時にはとして翻訳PHP5技術的な書籍、他の言語のPHP5のサポート反射、「マッピング。」反射の概念と使用方法、それは非常に明確でなければなりません。
反射の適用は、非常に広いようにNHibernateのでJava、Hibernateは、春のフレームワーク、.NET、Spring.NETフレームワークは、最も基本的なテクニックとして「反射」であるなど、多くの成熟したフレームワークです。
反射技術は、実際には非常に早い見えたが、さらに利用されていない、無視されてきました。オブジェクト生成遅いように法線に対して少なくとも10倍モードのプログラミング時間を反映しています。
反射を最適化する改良介して現在の技術は、十分に確立され、典型的には反射物体生成モードでオブジェクトを生成し、速度が少し違い、約1~2倍のギャップを有します。
我々は、工場モデルの昇華として見モードIOCコンテナを働かせることができるIOCコンテナ工場として見ることができ、生産オブジェクトにこのファクトリが指定された構成ファイルで定義され、
次いで、プログラミング言語を使用すると、構成ファイルに指定された対応するオブジェクトのクラス名を形成するために反射機構を提供します。実装の観点からは、IOCが死んだオブジェクトコードの生成を記述するためにファクトリメソッドの前に置かれ、
つまり、定義する構成ファイルを変更することによって、植物が独立したオブジェクトの両方により分離生成し、目的は、柔軟性および保守性を改善することです。
ファイブ.IOCの別名：依存性注入（DI）
IOCは終わりで、その後、制御の反転であるされているため、2004年に、Martin Fowler氏は、同じ問題を論じ、「それのコントロールをどのように反転する？」、そして詳細な分析後のデモの後、
彼は答えました：「逆転され、依存オブジェクトを取得するプロセスを」制御が反転された後、アクティブな管理からそれらの依存オブジェクトを取得するプロセスは、IOC容器から注入なります。
彼は「制御の反転」ので、より適切な名前がある「依存性注入（依存性注入）」でした。注入：彼の答えは、実際には、IOCを達成する方法を示しています。
、動作中のIOC容器、いわゆる依存性注入は、ダイナミック依存性は、特定のオブジェクトに注入しました。
したがって、依存性注入（DI）及び逆方向制御（IOC）は、オブジェクト間のデカップリング、注入依存性の方法によってIOC容器の導入を指す同じもの、の異なる角度から説明されています。
いくつかの6 .IOCコンテナ製品
Sun ONEの技術システムの下でIOCのコンテナは、次のとおりです。軽量春、Guiceの、ピココンテナ、アバロン、HiveMindのがあり、ヘビー級は、EJBを持っています。
ライトヘビーないのJBoss、Jdonと上のようがありません。Java開発SSHで三銃士、中小事業の一つとして、春のフレームワーク（Strutsの、春、Hibernateは）、使用されている非常に成熟し、広く使われています、
EJBはまた、特定の電気通信サービスなどの重要な産業プロジェクトで使用します。
.NETテクノロジシステムの下でIOCのコンテナがあります。Spring.Net、城などを。Spring.NetはIOCコンテナの上に春Javaから移植され、城ウィンザーは、IOCコンテナの一部です。
彼らはますます様々なプロジェクトで使用されているSpring.Netを、軽量フレームワークは、より成熟しています。
VII。IOCフレームワークを使用すると、何に注意を払う必要があります
IOCフレームワーク製品を使用することにより、当社の開発プロセスに大きな利益をもたらすだけでなく、IOCフレームワークと短所を十分に認識し、を認識して、虐待の枠組みを防ぐことができます。
サードパーティ製のIOCコンテナの導入に伴う1.ソフトウェアシステム、オブジェクトを生成するステップは、ややそれが両者の間に何かあったが、している可能性があり、複雑になる手順のうち何も、私たちはIOCの時間枠を使用して開始したので、システムはあまり直感的になった感じ。
そのため、新たな枠組みの導入は、学習やトレーニングチームメンバーが出会ったのコストを増加し、運用・保守の後、新規参入者は知識の同じボディを作るために持っていました。
2.オブジェクトがIOCコンテナ反射モード、運転効率の一定の損失によって生成されるように。あなたが運用効率を追求したい場合は、この比較検討しなければなりません。
（Springなど）製品3. IOCフレームワークの特定が懸念している、それはいくつかの小さなプロジェクトのために、客観的にも可能性の高い作品のいくつかのコストを増加させることであり、より複雑な、準備作業の多くを必要とします。
自身が評価する必要のある製品の4.IOCフレームワークの成熟製品はIOCフレームワークの未熟を導入すれば、それはプロジェクト全体に影響しますので、これは隠れたリスクです。
利用IOCフレームワーク製品に適したいくつかの小規模なプロジェクトや作業成果物、ではない：私たちは、おおよそことを結論付けることができます。また、知識とチームメンバーの能力の欠如、製品の深い理解の欠如のためにIOCフレームワーク、および導入する急いでいない場合。
ケースのWEB2.0のウェブサイトであるとして最後に、プロジェクトや製品の効率に特に重点を置いて、それは、製品IOCフレームワークの導入に適していません。