最近、疎結合アプリケーションの構築方法に関するブログ記事をたくさん目にしました。疎結合アプリケーションを作成するときに最もよく使用するパターンはどれですか? 依存性注入？コントロールの反転？
Fossmo
質問する
3641 次
13 に答える
13
余談ですが、結合アプリケーションの作成を妨げているのは、パターンだけではありません。
命名。クラスの名前を簡単に思いつかない場合は、何もしないか、あまりにも多くのことを行います。
テスト容易性。クラスの依存関係を簡単に模倣できない場合、それは結合設計です。
于 2008-12-22T13:44:04.727 に答える
7
Commandパターンを頻繁に使用していることに気づきました。プロジェクトを次から次へと与え続けるパターンです。
于 2008-12-22T13:53:42.977 に答える
6
春の依存性注入は私のお気に入りです。さらに、maven では、API モジュールの背後にあるすべての実装を隠すという、この非常に巧妙なトリックを行うのが一般的です。したがって、コードに「application-core」、「externalsystems-api」、「externalsystems」の 3 つのモジュールがある場合、「application-core」を externalsystems-api のみに依存させることができます。実際の実装とそのすべての依存関係は、アプリケーション コア モジュールからはまったく見えない可能性があります。これにより、懸念事項の分離が非常に困難になり、疎結合が容易になります。
すばらしいのは、これらの Maven セットアップをロードする IDE がこれらの可視性の制約を強制することです。したがって、アプリケーションコアで SQL、AXIS、JAXB などを参照することはできません。
于 2008-12-22T13:46:08.000 に答える
2
基本的なテクニックの一つは「Tell Don't Ask Principle、Law of Demeter」だと思います。DI や UI などのデザイン パターンとは違うかもしれませんが、この原則に当てはまらないオブジェクトは疎結合で、1 つのことをうまく実行していると思います。
"Keep It Shy Keep It Dry Keep It The Other Guy"
于 2008-12-22T13:56:13.783 に答える
2
SOA 関連のパターンの一部 (エンタープライズ サービス バスなど) は、より高いレベルでの抽象化を提供し、ビジネス サービスと技術サービス間の関心の分離をサポートします。サービス間の疎結合は、(ほぼ間違いなく) ソリューション内のサービスを分離するブローカーまたはバスを導入することによってサポートされます。
于 2008-12-22T13:58:20.300 に答える
2
訪問者パターンは非常にうまく機能します
于 2008-12-22T14:24:40.043 に答える
1
はい、重要なのは依存性注入と制御の反転ですが、抽象ファクトリとレジストリを忘れないでください。
于 2008-12-22T13:43:01.250 に答える
1
ブリッジ パターン ( http://en.wikipedia.org/wiki/Bridge_pattern )
于 2008-12-22T14:19:47.883 に答える
1
依存性注入は、制御の反転の一種です。
Spring Framework には Java プログラマーの大規模な基盤があり、.NET 実装もあります。
于 2008-12-22T14:33:26.047 に答える
1
これがまだ言及されていないことに驚いています。戦略を使用すると、ドメイン モデルのさまざまな型について知りすぎるクラスを作成することを避けることができます。各戦略は、特定のタイプが関与する特定の相互作用を成文化する責任があります。これにより、他の多くのタイプとそれぞれの実装のニュアンスを認識するマスター タイプを作成することを回避できます。
ウィキペディアから:
戦略パターンは、継承の代わりに構成を使用します。戦略パターンでは、振る舞いは別個のインターフェースと、これらのインターフェースを実装する特定のクラスとして定義されます。特定のクラスは、これらのインターフェイスをカプセル化します。これにより、動作とその動作を使用するクラスとの間の分離が向上します。動作は、それを使用するクラスを壊すことなく変更できます。クラスは、コードを大幅に変更することなく、使用される特定の実装を変更することで動作を切り替えることができます。動作は、設計時だけでなく実行時にも変更できます。
于 2010-01-07T19:47:56.727 に答える
0
全体的なコード/アーキテクチャスタイルとしての制御の反転。
IoCを構成するメカニズムとしてのDI。
ローカル抽象化（私はこれを「理想的な環境開発」と呼んでいます-あなたが望む正確な環境を持っているかのように書いてください）。
オブジェクトは通常、ゲッター/セッターを使用するのではなく、voidメソッドを使用し、データを渡すことによって通信します。
コアビジネスクラスで依存関係を直接使用することはありません。依存関係は常にローカル抽象化に抽象化され、明示的なBridgeが依存関係を処理します。
この組み合わせにより、非常に構成的な感覚を備えた非常に柔軟なコードが可能になることがわかりました。
于 2010-02-22T00:35:03.400 に答える
0
依存性注入は、私が作成するほぼすべてのクラスで使用するパターンです。クラスに依存性がある場合は、常に (コンストラクター注入を使用して) 注入します。依存関係のないクラス (値オブジェクトなど) だけが DI パターンを使用しません。DI を使用するクラスをテストできることは、大きなメリットです。
DI の利点については、次の 2 つのプレゼンテーションが非常に優れてい ます 。 2008/11/clean-code-talks-global-state-and.html
DI パターンを使用するために DI コンテナーは必要ありませんが、プログラムが大きくなった場合 (数十のクラスまたは多くのスコープ)、DI コンテナーは定型文を大幅に削減できます。JVM では、私のデフォルトの選択はGuiceです。
于 2010-02-22T00:30:29.970 に答える
0
依存性注入と IOC は、どちらもコードの分離に優れています。
Dotnetrocks show 362は非常に優れた定義を提供します。また、関連する DNR TV のエピソードを見て、より明確に理解してください。
于 2008-12-22T14:12:35.340 に答える