23

コンポーネント駆動型開発の用語は、特に広く使用され始めています。制御の反転に関連して。

  1. それは何ですか？
  2. それはどのような問題を解決しますか？
  3. それが適切なのはいつですか、そうでないのはいつですか？
4

7 に答える 7

18

それは何ですか？

あなたの答えの定義はこの質問をうまくカバーしていると思います。ただし、コンポーネントがその依存関係を明示的に定義する必要があることを定義に含める理由は疑問です。コンポーネントの標準的な例はActiveXコントロールです-依存関係を明示的に定義する必要がありますか？

それはどのような問題を解決しますか？

複雑さの管理。コンポーネントの実装についてのみ考えることができるようにすることで、これに対処しようとしています。コンポーネントを作成するだけでよく、それらを組み合わせたり管理したりする方法を考える必要はありません。これは、コンポーネントの外部にあるフレームワークまたはインフラストラクチャによって行われ、コンポーネントの作成者にとっては重要ではありません。

それが適切なのはいつですか、そうでないのはいつですか？

些細なアプリケーションや使い捨てのアプリケーションでは必ずしも適切ではありません。コンポーネントアーキテクチャの悪臭は、コンポーネント自体ではなく、コンポーネントを管理および結合するためのインフラストラクチャについて考えたり、作業したりすることに時間を費やしている場合です。

于 2009-06-06T23:54:47.403 に答える
12

それが「広く使われている」用語かどうかはわかりませんが、VCS（バージョン管理システム）では、プログラムの構築に必要な一連のファイルを管理する2つの方法を知っています。

  • システムベースのアプローチ。すべてのセットに共通のライフサイクルがあり、すべてとしてタグ付けする必要があります
  • コンポーネントベースのアプローチ。個々のファイルセットには独自のライフサイクルがあり、メタラベルはコンポーネントのすべてのラベルを参照して、それらのコンポーネント間の構成と依存関係によってすべてのシステムを指定します。

アプリケーションアーキテクチャは、これらのコンポーネントを識別するために使用されます。

  • 機能ドメインとアプリケーション
  • サードパーティのライブラリ
  • フレームワーク

IoCはあらゆるフレームワークの基盤であるため、ここでIoCが登場します。それが解決する問題は、アプリケーションの一部をより適切に識別できるようにすることです
。トレーダーの損益（ポジション）の計算を担当するPLR（損益）アプリケーションを設計するとします。
これは単一のアプリケーションではなく、複数のアプリケーションで構成されていることにすぐに気付くでしょう。

  • GUI
  • ランチャー
  • ディスパッチャ（すべてを計算するのに十分なメモリがないため、複数のサーバーに計算をディスパッチします！）
  • など

次に、さまざまなモジュールをプラグインできるようにする計算フレームワーク（Ioc）を特定できます。これらのモジュールは、フレームワークによって適切なタイミングで呼び出されます。

または、他の機能コンポーネントで使用できる純粋な技術フレームワーク（KPI、ログ、例外管理）を特定することもできます。

プロジェクト管理に関しては、VCSを介したグローバルな調整を保証しながら、各パーツを個別に開発することもできます。

于 2009-06-01T06:26:41.487 に答える
9

コンポーネントベースの開発は、本当に新しいものではありません。コンポーネント駆動型開発については知りませんが、CBDであると想定します。これがUnixの設計方法であり、それぞれが1つのことを非常にうまく実行している代替可能な小さなプログラムの集まりです。デスクトップの分野では、DelphiのVCLは、他に類を見ない豊富な再利用可能なコンポーネントとサードパーティ市場を備えたコンポーネントの使用に成功しています。いくつかの技術が成熟しつつある現在、CBDの復活が見られています。たとえば、単純なWebアプリはSOAとRESTfulWSに進化しています。Javaの人たちが話しているのは、モジュール性とIoCだけです。

あなたが探している答えは、KeJinによる制御の反転の理由と内容にあります。

さらに、これらの古典的なオブジェクト指向プログラミング言語の命令型の自然は、ツリー（低レベルの論理制御手続き型コード）のフォレスト（高レベルのアーキテクチャ/構造）を見逃す傾向があります。既存のアプリケーションを引き継ぐ開発および保守エンジニアは、その古い設計/アーキテクチャドキュメントと低レベルのコードコメント/パターンに依存する必要があります。

コンポーネントベースの開発（CBD）パラダイムは、配管ロジックを、コンポーネントを操作し、ユーザー/開発者が提供する宣言型の説明に基づいてアプリケーションをセットアップするフレームワークにシフトすることにより、上記の2つの問題に取り組みます。一般的な混乱とは異なり、このような宣言型の説明は、アプリケーションのセットアップスクリプトを意図したものではありません。むしろ、彼らの基本的な意図は、命令型の配管手順を義務付けることなく、アプリケーションのアーキテクチャ/構造を明示的に表現することです（つまり、方法ではなく何を説明するか）。CBDパラダイムの目標は、これらのフレームワークによって効果的で柔軟なアプリケーション構成をサポートし、アプリケーション開発者が低レベルの配管の複雑さを気にせずにビジネスロジックとドメインの問題に集中できるようにすることです。

宣言型アプリケーションの説明とIoC手法を組み合わせたCBDフレームワークは、IoCフレームワークと呼ばれます。以前のフレームワークとは異なり、IoCフレームワークは 非侵襲的であり、 依存関係/構成の注入/設定のシナリオを使用します。

ウィキペディアによると、コンポーネントベースの開発はコンポーネントベースのソフトウェアエンジニアリング（CBSE）の別名です。

[それ]はソフトウェアエンジニアリングの一分野であり、その優先順位は、特定のソフトウェアシステム全体で利用可能な幅広い機能に関する関心の分離です。

これはやや曖昧なので、詳細を見てみましょう。

個々のコンポーネントは、関連する機能（またはデータ）のセットをカプセル化するソフトウェアパッケージまたはモジュールです。

すべてのシステムプロセスは別々のコンポーネントに配置されるため、各コンポーネント内のすべてのデータと関数は意味的に関連しています（クラスのコンテンツと同様）。この原理により、コンポーネントはモジュール式でまとまりがあるとよく言われます 。

したがって、この定義によれば、コンポーネントは、1つのことを本当にうまく実行し、1つのことだけを実行する限り、何でもかまいません。

システム全体の調整に関しては、コンポーネントはインターフェースを介して相互に通信します。[...]この原則により、カプセル化と呼ばれるコンポーネントが作成されます。

したがって、これは、優れたAPIまたはSOAがどのように見えるべきかについて私たちが考えるもののようにますます聞こえています。

提供されたインターフェースはロリポップで表され、必要なインターフェースはUMLのコンポーネントの外縁に取り付けられたオープンソケットシンボルで表されます。

代替テキスト
（出典：wikimedia.org）

コンポーネントのもう1つの重要な属性は、コンポーネントが 代替可能であるため、最初のコンポーネント（インターフェイスを介して表現される）の要件が後続のコンポーネントによって満たされる場合に、コンポーネントを別のコンポーネントに（設計時または実行時に）置き換えることができることです。

再利用性は、高品質のソフトウェアコンポーネントの重要な特性です。ソフトウェアコンポーネントは、さまざまなプログラムで再利用できるように設計および実装する必要があります。

代替可能性と再利用性は、コンポーネントをコンポーネントにするものです。では、これとオブジェクト指向プログラミングの違いは何ですか？

オブジェクト指向プログラミング（OOP）の考え方は、ソフトウェアは、それが表す実際のオブジェクトまたは想像上のオブジェクトのメンタルモデルに従って作成する必要があるというものです。[...]

対照的に、コンポーネントベースのソフトウェアエンジニアリングは、そのような仮定を行わず、代わりに、電子工学や力学の分野のように、プレハブのコンポーネントを接着することによってソフトウェアを開発する必要があると述べています。

于 2009-06-13T21:05:19.203 に答える
5

これがいくつかの調査を行った後の私の定義です。

コンポーネント駆動開発は、ソフトウェア開発におけるアプローチであり、コードが再利用可能でテスト可能なコンポーネントに断片化され、それらが組み合わされてビジネス機能を提供するためのアプリケーション基盤を形成します。コンポーネントの組み合わせと管理は通常、制御の反転に委任されます。

コンポーネント自体は、サービスコントラクトを実装し、このコントラクトを実行するために必要な依存関係を明示的に定義するクラスです。実際の実装は、コンポーネントの外部にいる他のすべての人から隠されています。

関連リンク：

于 2009-06-02T06:29:23.980 に答える
5

私は、コンポーネントベースのソフトウェアエンジニアリングを、プラグ可能なコンポーネントを使用してソフトウェアシステムを開発するためのアプローチと見なしています。コンポーネントは「契約上指定されたインターフェースと明示的なコンテキスト依存関係のみを持つ構成の単位」であり、「独立して展開でき、サードパーティの構成の対象となります」。（Clemens Szyperski、「コンポーネントソフトウェア：オブジェクト指向プログラミングを超えて」）

CBSEは、コードの再利用と柔軟で適応可能なソフトウェアシステムの迅速な組み立てを容易にします。

何年もの間このトピックに焦点を合わせてきた実質的な研究があります。フラッグシップイベント（コンポーネントベースのソフトウェアエンジニアリングに関するACM SIGSOFTシンポジウム）は現在14年目であり、かなりの数の新しいトレンドが出現しています。

また、今日の業界で頻繁に使用されている、再利用可能、プラグ可能、および拡張可能なコンポーネントの良い例が必要な場合は、MSEnterpriseLibraryをご覧ください。

于 2011-02-19T20:41:23.057 に答える
1

コンポーネント（または他の再利用可能な資産）をアプリケーションに結合することに興味がある場合は、ソフトウェア製品ラインの方法論も検討する必要があります。

ソフトウェア製品ラインでは、コンポーネント（または下位レベルのコード要素）間の依存関係は、それらのコンポーネントの外部で明示的に管理されます。これは通常、次のようなルールを含む機能モデルを使用して行われます。

  • これらの2つのコンポーネントを一緒に使用しないでください（相互排他性）
  • このコンポーネントを使用する場合は、この他のコンポーネントを使用する必要がありますまたは（相互依存性）
  • 指定されたコンポーネントのセットの任意の組み合わせを使用できます（オプション）

モデル化する依存関係の複雑さに応じて、他のより複雑なルールが可能です。

機能モデリングの代わりに使用されることがある別のアプローチは、コードジェネレーターを使用して、完成したアプリケーションにアセンブルされるさまざまなコンポーネントを構成することです。機能モデリングとコード生成を組み合わせることも可能です。

コード生成とは別に、ドメイン固有のモデリング、モデル駆動型ソフトウェア開発、ソフトウェアファミリとして検索する可能性のある他のいくつかの用語。

于 2009-06-13T14:05:12.503 に答える
-4

Unity 3Dを使おうとするまで、実際にコンポーネント駆動型開発とは何かを理解することはできません。これはActiveXやこれまでに見たものではなく、以前に見たものには別のコンポーネントの意味があります。

コンポーネント駆動型開発は、最近話しているすべての人について、2つのことを意味します。

  1. オブジェクト-これは、OOPプログラミングまたは実世界のオブジェクトのオブジェクトとまったく同じです。
  2. オブジェクトのコンポーネント-オブジェクトの機能の一部またはその能力の1つに似ています。

したがって、コンポーネント-はオブジェクトではありません。それは-オブジェクトの機能です。

したがって、標準のOOPプログラミングでは、新しい機能でベースオブジェクトを拡張する必要がある場合、ベースオブジェクトを継承して新しい派生オブジェクトを作成する必要があります。

コンポーネント駆動型開発では、拡張オブジェクトが必要な場合は、空のオブジェクトを作成し、継承せずにさまざまなコンポーネントで埋めるだけです。コンポーネント駆動型開発では、クラスはなく、代わりにプレハブがあります。これは、事前定義されたコンポーネント、事前定義されたコンポーネント、子オブジェクトを備えた事前定義されたオブジェクトです。

私が言ったように、あなたが試みるまであなたは決して理解しないでしょう。コンポーネント駆動型開発では、常にプログラミングを使用する必要はありません。代わりにグラフィカルエディターを使用できます。また、通常のOOPの継承地獄から解放されます。コンポーネント自体は通常のプログラミングでプログラミングされていますが、オブジェクトを含む高レベルのシステムでは、ほとんどの場合、エディターでコンポーネントを使用および結合し、カスタマイズされたオブジェクトの動作を受け取るだけで済みます。

したがって、コンポーネント駆動型開発は次のことを実現します。

  1. プログラミングなしでエディタだけを使用して、プログラムのロジックを作成する大きな力。
  2. OOP継承地獄からあなたの心を解放します。開発をよりシンプルかつ迅速にします。
  3. コードに触れることなく、プログラムを高度にカスタマイズ可能でスケーラブルにします。エラーやバグが少なくなります。
  4. Restシステムに大きな影響を与えることなく、特定のコンポーネントを再プログラミングするだけで、プログラムのコードを簡単に保守できます。
  5. 等...

また、コンポーネントベース（ドリブン）プログラミングはOOPプログラミングの代わりではなく、OOPまたは通常のプログラミングのTOPにあることも付け加えておきます。低レベルのコンポーネントの実装のためにCBPでまだ使用されている通常のプログラミング。この記事には、CBPについての簡潔な説明も含まれていると思います：http：//acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf

于 2013-05-17T09:47:11.023 に答える