問題タブ [loose-coupling]

「疎結合」の概念が理解できないようです。「ゆるい」という言葉が通常否定的な意味合いを持っていることは役に立たないと思うので、疎結合が良いことであることをいつも忘れています。

誰かがこの概念を説明する「前」と「後」のコード (または疑似コード) を示してくれませんか?

最近、疎結合アプリケーションの構築方法に関するブログ記事をたくさん目にしました。疎結合アプリケーションを作成するときに最もよく使用するパターンはどれですか? 依存性注入？コントロールの反転？

ほぼ同一のデータベースの 2 つのバージョンがあります。以下に、基本的な違いを示す例の表を作成しました。つまり、ID 列が整数 ID から GUID に変更され、さまざまなプロパティが更新されました。アーカイブされた例では、読み取り専用に置き換えられ、非表示になっています。

レガシー バージョン:

新しいバージョン：

NHibernate などの O/R マッパーを使用して、これらのデータベース バージョンのいずれかに接続できるようにする必要があります。構成ファイルの設定を通じて、使用するバージョンをアプリケーションに伝えられるようにしたいと考えています。

私の最初の計画は、ビジネス ロジック用の共通インターフェイスを作成し、Unity などの IoC コンテナーを使用して、構成ファイル内の関連する具象クラスを交換することでした。

以下は、この理論をテストするために作成したコードの例です。

これが可能かどうか (具体的には Unity と NHibernate で)、誰でもアドバイスできますか? もしそうなら、関連する NHibernate マッピング ファイルを作成する方法を教えてください。

または、他の方法または他の IoC および O/R マッピング ツール (商用またはオープン ソース) を使用して、問題の解決策を提案できますか?

どうもありがとう、

ポール

IOC コンテナーを使用する際に注意すべきこと (落とし穴) は何ですか?

クラスを緩く結合しておくことは、理解、変更、およびデバッグが容易なコードを作成する上で重要な側面です。しかし、初心者として、私が苦労している最も単純な例を超えたときはいつでも。

私は、多かれ少なかれ、文字列、整数、および単純なデータ型を独自のクラスにカプセル化する方法を理解しています。ただし、リッチテキスト形式などの情報を扱い始めると、コンポーネントにすでに存在するさまざまなメソッドを使用しない限り、状況は非常に複雑になります。この例を続けるために、UIにRTFメモコンポーネントを含むものを書いていると仮定します。Delphiでは、コンポーネントには、フォーマットされたテキストの保存などを行うための組み込みメソッドがあります。さらに、RTFテキスト自体を操作する唯一の（または少なくとも最良の）方法は、コンポーネントに再度組み込まれているメソッドを使用することであるように思われる場合があります。

これらすべてを実行するコンポーネントがすでにある場合、別のクラスでテキストの保存、読み込み、フォーマットのすべての作業をどのように（またはなぜ）実行しますか？

私自身は通常、（a）必要以上に複雑に見えることを行うか、すでに存在するメソッドを再発明するか、（b）互いに緊密に結合された不十分なクラスを作成することになります。彼らがインフォマーシャルで言うように、「もっと良い方法がなければならない！」

私はその「より良い方法」がどのように機能するかについて概念的に迷っています。何かご意見は？

さかのぼる 12 月に、「[単純なオブジェクトに] 具象型を使用しても問題ない」という回答が寄せられたこの投稿がありました。

しかし、サンプル プロジェクトではインターフェイスを備えた単純なエンティティがますます増えており、制御したばかりの非常に大規模なエンタープライズ アプリケーション (89 個のインターフェイスを数えている) も見られます。

人々が最善のアプローチを選択しておらず、「私のプロジェクトは疎結合です!」と言ってプロジェクトを散発的にやっているだけなのでしょうか? アプローチ？

または、何か不足していますか。IService、IFactory、および IRepository 実装の具体的な型を使用して単体テストを実行できます (そして、非常にうまく機能します)。また、メイン ドメインから離れてこれらのサード パーティ ツールの多くを抽象化するための最初の「Anticorruption Layer」を構築しています。この腐敗防止レイヤーには、多くのファサード、トランスレーター、およびアダプターがあり、これらはすべて疎結合されています (または結合される予定です)。

それで、インターフェースを持つエンティティについて私が見逃しているものはありますか?

編集：これらのインターフェースをすべて備えた私が持っているエンタープライズアプリには、単体テストがないことにも言及する必要があります。笑

TDDを実行していると、依存性注入の原則を採用せざるを得なくなり、コードが緩く結合されてしまいます。

コードがゆるく結合しているアプリケーションを理解するのは難しいと言われました。

ゆるく結合されたコードの長所と短所を教えてください。

モデルと実装を可能な限り緩く結合しようとしている状況がありますが、結合が必要以上に近づく可能性があるという状況に直面しています。

私は「モデル」クラスの選択を持っており、すべてがインターフェースを実装しています。さらに、「データアクセス」クラスがあります。このクラスは、整数のルックアップ値を完全な「オブジェクト」表現にデコードする関数を提供します。

モデルクラス内で、モデルがデータアクセスクラスについて知る必要なしに、これらのデコードされた値へのアクセスを提供したいと思います。

簡単な例は次のとおりです。

クラスがResolveMakeクラスを直接認識せずに、消費するクラスにオブジェクトをCar提供できるようにするにはどうすればよいですか？IMakeInfo実際のインスタンスでは、Carクラスを操作していますが、ResolveMakeクラスと同じ名前空間になく、そのインスタンスへの参照は含まれていません。

私のオプションのいくつか：

• メソッドCarのインスタンスを提供できるデリゲートを実装します。GetMakeInfo
• ある種の依存性注入
• CarをResolveMakeに緊密に結合し、それで完了します。
• 他のオプションはありますか？

どんな提案も歓迎します！

保守可能なアプリケーションのための疎結合、高い結束

何度も聞く鬨の声です。コンポーネントを疎結合する方法については、多くのアドバイスがあります。

• インターフェイスに基づいて、すべての依存関係を注入します
• イベントを使用する
• 運行バスを利用する
• 等

しかし、結束力を高めるための具体的な提案を実際に聞いたことがないように感じます。誰か提供するものはありますか？

そこから回答を始めることができますが、特定の状況についてもアドバイスをお願いしたいと考えています。

私はかなり疎結合の C# Windows フォーム MVP アプリケーションを持っています。このアプリケーションは、そのコンポーネントの多くをインターフェイスに基づいており、コンストラクターを介してそれらを注入し、制御の反転コンテナー (Castle Windsor) を使用してすべてを組み立てます。

非常によく設計されていると言えます。すでにいくつかの大きな変更要求を受けており、それらを非常に簡単に処理しました。私は全体的に非常に満足していますが、特にまとまりがないというしつこい疑いを手放すことはできません. これは、唯一の開発者である私にとっては問題ではありませんが、アプリケーションを初めて使用する人にとってはかなり混乱する可能性があるのではないかと心配しています.

例を挙げましょう。このアプリケーションは、会社 A が出荷トラックに製品を充填して処理するために使用されています。これは、OutgoingTransactionInfoオブジェクト、OutgoingTransactionInfoControl (実際に情報を入力するため)、OutgoingTransactionValidator、およびOutgoingTransactionPersisterがあることを意味します。アプリを本番環境に置いて、着信トランザクションも処理するように要求されました。これらには、さまざまな情報が添付され、さまざまな検証が行われ、さまざまな方法で永続化されます。その後、B 社はトランザクション処理にもアプリケーションを使用したいと考えました。アイデアは似ていますが、情報、検証、永続性、およびおそらく他のいくつかのコンポーネントが異なります。

私のアプリケーションには優れたテスト スイートがあり、緩いので、これらの要求に非常に簡単に対応することができました。ただし、誤って無効な状態に構成するのは簡単すぎることを認識しています。たとえば、 IncomingTransactionValidatorで検証しながらOutgoingTransactionInfoオブジェクトを使用するように配線できます。違いが微妙な場合、エラーはしばらくの間検出されないことさえあります。

何か提案はありますか？そのようなリスクを軽減するためにどのような手法を使用していますか?