oop - ソフトウェアコンポーネントをどのように定義しますか？

Question

ソフトウェアコンポーネントをどのように定義し、OOPとコンポーネントプログラミングの間にはどのような関係がありますか？長所と短所は何ですか？これらのパラダイムの「黄金比」は何ですか？

Answer 1

コンポーネントは、オブジェクトよりもかなり高いレベルの編成概念であると思います。

多くの場合、コンポーネントはリリースと展開の単位です。それらが公開するインターフェースと、他のコンポーネントおよびインフラストラクチャーの側面でそれらが持つ依存関係の両方を定義することが期待されます。システム内のさまざまなコンポーネントは、非常にさまざまなテクノロジーを使用して開発される可能性があり、実際、単一のコンポーネントが同種である必要はありません。

あるオブジェクト指向言語でコンポーネントを開発する場合は、責任を分解し、そのコンポーネントのオブジェクト指向設計に到達します。

Answer 2

ソフトウェアコンポーネントの粒度は、再利用の粒度に対応している必要があります。ソフトウェアの塊を他の場所で再利用する場合は、独自のコンポーネントとしてバージョン管理してリリースする必要があります。他の場所で再利用されない場合、これはほとんど価値を追加しません。

完全なクラスよりも小さいものがコンポーネントと見なされ、クラスのコレクションがコンポーネントを形成すると予想される場合は、驚くべきことです。

Answer 3

コンポーネントプログラミングは本質的にooの再発明だと思います。

ooはブラックボックスを目指していました...しかし、そうではありません。コンポーネントプログラミングはブラックボックスを目指しています。

結果として、コンポーネントプログラミングは、エンジニアリングよりも（前向きに）意味があると思います。ブラックボックスになるには、将来のユースケースを予測し、すでにそれらに対応している必要があるためです。

それはまた、徹底的なテストの文書化の心理学を意味します。これは、私の経験では、とにかくオブジェクト指向コーディングに後れを取っているようです。

したがって、スレッド化と非同期のサポートを提供します。インターフェイス、ドキュメント、単体テストを公開します。明確なイベント構造と行動を持っている。

基本的に、誰かがそれを再利用できるようにし、再利用できるようにするためにできることは何でも。

重要なのは、コンポーネントには明確に定義されたインターフェースと明確に定義された機能があるということです。実際の実装の詳細は、コンポーネントの使用方法を検討する際に範囲外であるため、これには含まれていません。つまり、コンポーネントは非常に複雑なオブジェクトのセットになる可能性があります。

Answer 4

コンポーネントは、ブラック ボックスのようなアプリケーションのサブシステムと考えることができます。
したがって、OOD では、ボックスが何でできているかを知らなくても計算を実行できるようにする、明確な仕様を持つクラスとインターフェイスのグループです。

入力 -> [BlackBox] -> 出力

コンポーネントをさらに識別するものは次のとおりです。

• 高い内部結合
• コンポーネントを 1 つ以上のプロジェクトに簡単にインポートできるように、アプリケーションの残りの部分に関して依存関係はありません。

コンポーネント プログラミングとは、実際にはコンポーネントを組み立ててより大きなアプリケーションを構築することだと思います。
非常に「ユートピスティック」な見方では、仕様を満たすコンポーネントを探すことができる公開リポジトリが必要です。コンポーネントが見つかったら、アプリに統合できます。