NDepend を介して自分のプロジェクトの 1 つを実行していたところ、レポートによってアセンブリが苦痛の領域の隅に追いやられました。それは私が心配する必要があるものなのだろうかと思っていました。
ゾーン・オブ・ペインの本当の意味とは？カップリングが多くて簡単には変えられないということではないでしょうか。
ユーザーがAPIを拡張したくないので（一部の場所でのみ）、最近、多くのインターフェースを削除し、多くのクラスを封印しました。これは com オブジェクトの .NET ラッパーであるため、ユーザーが何かを拡張する必要はあまりありません。
痛みのゾーンから抜け出すための良い方法は何ですか?
ありがとう
Zone of Pain の考え方は、次の両方のコンポーネントを検出することです。
ポピュラーとは、安定性の概念を指します。コンポーネントを変更すると、それを使用している他の多くのコンポーネントが壊れる場合、そのコンポーネントは安定しています。一言で言うと人気＝安定
もう 1 つの考えは、インターフェイスはクラスよりも変更の影響を受けにくいということです。これが、クラスの代わりにインターフェイスを使用する方が望ましいと一般に認められている理由です。「静的に」壊れる可能性が低く、コードが「意味的に」壊れる可能性が低くなります。実装の詳細 (変更される可能性が高い) にバインドされます。
結果として、具体的で安定していると、コンポーネントが潜在的な開発上の問題にさらされます。変更の影響を大きく受け、変更のたびに多くのコードが壊れる可能性があります。
あなたの場合と他のいくつかの場合では、痛みのゾーンにいることは必ずしも悪いことではありません. 重要なことは、両方ともこの事実に注意することです + 実際にコンポーネントが痛みを引き起こす場合は、コードをインターフェースにロールバックしてください。
Scott Hanselman が NDepend とそのゾーンへの影響についてかなり長い記事を書いたと思います。
http://www.hanselman.com/blog/ExitingTheZoneOfPainStaticAnalysisWithNDepend.aspx
彼が述べたように、そして私も同意見ですが、痛みのゾーンに浮かぶアセンブリは必ずしも悪いことではありません. ただし、これは、別のコンポーネント (COM またはその他) を使用して同じ機能層を実現する決定が下されたときに、変更が必要になることを示しています。
おそらく、「このレイヤーを別のフレームワーク/ライブラリに交換する可能性はどのくらいありますか?」という質問をする必要があります。