保守可能なアプリケーションのための疎結合、高い結束
何度も聞く鬨の声です。コンポーネントを疎結合する方法については、多くのアドバイスがあります。
- インターフェイスに基づいて、すべての依存関係を注入します
- イベントを使用する
- 運行バスを利用する
- 等
しかし、結束力を高めるための具体的な提案を実際に聞いたことがないように感じます。誰か提供するものはありますか？
そこから回答を始めることができますが、特定の状況についてもアドバイスをお願いしたいと考えています。
私はかなり疎結合の C# Windows フォーム MVP アプリケーションを持っています。このアプリケーションは、そのコンポーネントの多くをインターフェイスに基づいており、コンストラクターを介してそれらを注入し、制御の反転コンテナー (Castle Windsor) を使用してすべてを組み立てます。
非常によく設計されていると言えます。すでにいくつかの大きな変更要求を受けており、それらを非常に簡単に処理しました。私は全体的に非常に満足していますが、特にまとまりがないというしつこい疑いを手放すことはできません. これは、唯一の開発者である私にとっては問題ではありませんが、アプリケーションを初めて使用する人にとってはかなり混乱する可能性があるのではないかと心配しています.
例を挙げましょう。このアプリケーションは、会社 A が出荷トラックに製品を充填して処理するために使用されています。これは、OutgoingTransactionInfoオブジェクト、OutgoingTransactionInfoControl (実際に情報を入力するため)、OutgoingTransactionValidator、およびOutgoingTransactionPersisterがあることを意味します。アプリを本番環境に置いて、着信トランザクションも処理するように要求されました。これらには、さまざまな情報が添付され、さまざまな検証が行われ、さまざまな方法で永続化されます。その後、B 社はトランザクション処理にもアプリケーションを使用したいと考えました。アイデアは似ていますが、情報、検証、永続性、およびおそらく他のいくつかのコンポーネントが異なります。
私のアプリケーションには優れたテスト スイートがあり、緩いので、これらの要求に非常に簡単に対応することができました。ただし、誤って無効な状態に構成するのは簡単すぎることを認識しています。たとえば、 IncomingTransactionValidatorで検証しながらOutgoingTransactionInfoオブジェクトを使用するように配線できます。違いが微妙な場合、エラーはしばらくの間検出されないことさえあります。
何か提案はありますか？そのようなリスクを軽減するためにどのような手法を使用していますか?