1

たとえば、OSGi を使用せずにアプリケーション (モジュール化、依存性注入など) で OSGi の利点を利用したい場合、どの設計パターンを採用すればよいでしょうか?

4

2 に答える 2

1

あなたが言及した2つは私のリストの一番上にあります：

  1. モジュール性。クラスローダー分離の利点がないため、独自の規則を使用して、他のコンポーネントに「到達」しないようにする必要があります。OSGi への切り替えがプロジェクトの将来にあると思われる場合は、OSGi 環境ではうまく機能しない Class.forName、Thread.getContextClassLoader などを絶対に避けてください。

  2. サービス。個別のモジュール内のコンポーネントが疎結合のまま相互に検出および登録できるようにするサービス レジストリの利点がないため、同様のものを使用する必要があります。PojoSRがありますが、それ以外の場合は、依存性注入フレームワークを使用して疎結合できます。

OSGi の残りのほとんどは、フレームワークがユーザーのために行うことを仕様が保証しているもの (JVM シングルトン、セキュリティ、管理、ダイナミズムなど) であるため、自分で行う必要があります。OSGiを使用する利点のリストを参照して、不足しているものを確認するのがおそらく最も簡単です。

于 2013-06-22T14:10:02.723 に答える
0

OSGI はすぐに使用できる多くの機能を提供します。使用したくない場合でも、Spring などの何らかのフレームワークを使用することをお勧めします。

Spring はセットアップが簡単で、依存性注入コンテナーを備えています。もちろん、クラスを作成する方法で、いつでも独自の依存性注入を行うことができます。これには一般的に 2 つの方法があります。オブジェクトの作成時に必要なクラス/オブジェクトがコンストラクター引数で渡されるコンストラクター注入と、クラスが依存関係ごとにセッターを持つセッター注入です。すべての依存関係を必ず設定してください。そうしないと、オブジェクトが無効な状態になる可能性があります。

モジュール化は、どこまでやりたいかによって、多くのことを意味します。原則として、インターフェイスに対するプログラミングでは、ある程度のモジュール性が得られます。MVC や関連するパターンなどのよく知られたソフトウェア アーキテクチャを使用すると、ある程度の成果が得られます。OSGI はホワイトボード パターンとパブリッシュ/サブスクライブまたはリスナー パターンを使用しますが、どちらも同様のニーズを満たします。これらのパターンはどちらも、オブジェクトの広範な分離を可能にします。

あなたが達成しようとしていることの種類を投稿していただければ、私はあなたをもっと助けることができます.

于 2014-12-01T00:45:02.323 に答える