私はポッドキャスト Java posse を聞いています。これには、コンポーネントに関する議論がよくあります (コンポーネントは (明らかに) オブジェクトではないことに注意してください)。彼らは、Java にはコンポーネントがないことを嘆き、コンポーネントがある .NET とは対照的です。コンポーネントを使用すると、(GUI アプリだけでなく) アプリケーションの開発が容易になるようです。
議論から、コンポーネントが持つ特定の性質、デカップリングと関係があることを理解できます (あるコンポーネントを別のコンポーネントに置き換えることは、単に配管の問題です)。プロパティと関係があり、イベントとデリゲートと関係があることは間違いありません。
質問に：
./コンポーネントとは何か説明してくれませんか。(そして、Java Bean がコンポーネントではない理由)。
./開発にどのように役立つか誰か説明できますか.
./ Java が非常に便利な場合、Java にそれらがない理由を誰でも説明できます。
Java の初期には、コンポーネントの概念は多くの場合、Gui コンポーネントに関連付けられていましたが、ソフトウェア エンジニアリングにおけるコンポーネントの一般的な意味は、その概念を超えています。
簡単に言えば、コンポーネントは再利用可能なソフトウェアの一部です。レンガのように、それらを組み合わせて結合し、アプリケーション全体を構築します。現代の環境におけるソフトウェア コンポーネントの重要な洞察は、コンポーネントのコンテンツを記述し、再利用を可能にするメタデータです。
1996 年、JDK 1.0 はコンポーネントにメタデータを提供する最初のマネージド ランタイム環境でした。この場合、コンポーネントはバイトコードとメタデータ.classを含むファイルです。しかし、Java 仕様によれば、ファイルには型定義が 1 つしか含まれていません。したがって、タイプのバンドルをコンポーネントとしてデプロイするには、いくつかのファイルを含む Jar アーカイブを使用することがあります。.class.class
一方、再利用可能なコンポーネントという同じ考え方を提供する .Net プラットフォームでは、コンポーネントに複数の型定義を含めることができます。この場合、コンポーネント (別名.Net のアセンブリ) は.dllまたは.exeファイルです。
Software Engineering Radio には、まさにこのトピックに関するエピソードがあります: http://se-radio.net/podcast/2008-02/episode-87-software-components
一般的な考え方は、ソフトウェア コンポーネントは、それ自身の依存関係とサービスが何であるかをメタデータの形式で記述できるということです。Java にはコンポーネントがないと聞いたことがあるかもしれませんが、コンポーネントがメタデータを通じてそれ自体を記述する Java のアーキテクチャを確かに想像できるからです。Java プラットフォームの定義自体には、実際にはコンポーネント アーキテクチャがないだけだと思います。
更新: 確かに、他の人が指摘したように、Java Beans またはサーブレットは確かにコンポーネントベースのアーキテクチャと見なすことができるため、そのようなアーキテクチャを想像する必要はありません。
コンポーネントという用語は、オブジェクト指向で最もあいまいで使い古された用語の 1 つです。
ほとんどの人は、コンポーネントがクラスのグループで構成されており、それらが連携して 1 つ以上のインターフェイスを実装することに同意するでしょう。クラスの 1 つは「フロントエンド」の役割を担います。つまり、インターフェイスを実装しますが、グループ内の他のクラスに作業を委譲します。あなたが言うように、コンポーネントはシステムの残りの部分が知らないうちに交換可能であるべきです。
コンポーネント ベースのアーキテクチャの好例は COM でした。非常に頻繁に使用され、厳密に指定されているため、これは素晴らしい例です。ただし、このアーキテクチャの必要性は、C++ のコンパイルおよび展開モデルの柔軟性に基づいていたことに注意してください。
Java では、システムの残りの部分とのバイナリ互換性を損なうことなく、クラスに対して非常に多くのことを行うことができます。そのため、厳格なコンポーネント ベースのアーキテクチャを構築する必要はあまりありません。しかし、それはすべて、用語の定義方法に依存します。たとえば、依存性注入を使用して構築されたプロジェクトは、「コンポーネント ベース」と見なすことができます。
「コンポーネント」の意味によって異なります。この用語は、さまざまな文脈でさまざまなことを意味する可能性があるため、混乱を招きやすい. そうは言っても、この件に関する私の理解は次のとおりです。
コンポーネントはオブジェクトとは異なります (ただし、オブジェクトはコンポーネントを表現および構築するためによく使用されます)。違いはいくつかあります：
コンポーネント指向設計の良い例はたくさんありますが、私が最初に選んだのは UNIX です。UNIX の背後にある基本的な考え方は、UNIX は複数のモノリシック プログラムで構成されているのではなく、連携して動作するように設計された一連の小さなプログラムであるということです。
ソフトウェアはいくつかのグループに分けられます。ここに Java チャンクがあります。
「コンポーネント」、「レイヤー」、「ティア」、およびその他の哲学的グループは、一般的には概念的なものです。VB COM 環境には、コンポーネントの形式がありました。他の誰もがそれらを単なるアイデアとして扱います。
Bean はクラスです。単一のクラスをコンポーネントにすることはできますか? 多分。コンポーネントは通常、一連のクラスです。正式なインターフェースと実装の 2 つの場合もあります。
コンポーネントは、クラス、パッケージ、グループ化などの論理的なグループ化に集中するのに役立ちます。
コンポーネントは概念的なものであるため、多かれ少なかれすべての言語にコンポーネントがあります。コンポーネントの言語形式はほとんどありません。それらは本当に必要ありません。これは、思考を構築するために使用するアイデアまたは原則です。
インターフェースとメタデータ、およびその他の多数の機能を使用して、「コンポーネント」へのアプローチを慎重に定義できます。
特に .NET コンポーネントについては知りませんが、Java POV から考えると、コンポーネントとは、定義されたインターフェース/使用原理を持つべき機能単位であると言えます。Java には言語概念としてのコンポーネントはありませんが、Java には IMHO コンポーネントがあります。技術的なコンポーネントは次のとおりです。
機能コンポーネントは次のとおりです。
アーキテクチャ コンポーネントは、JAR ファイルまたは OSGi バンドルである可能性があります。
もちろん、解釈の余地は常にあります ;)