我刚刚通过NDepend运行我的一个项目，报告将我的组件放在痛苦区域的角落。我只是想知道这是否应该让我担心。
疼痛区域的真正含义是什么？这是否意味着存在很多耦合，事情不容易改变。
我最近删除了很多接口并密封了很多类，因为我不希望用户扩展API（仅在某些地方）。它是com对象的.NET包装器，因此用户不需要扩展任何东西。
有什么好办法可以让我走出痛苦的区域？
由于
答案 0 :(得分：11)
疼痛区域的想法是检测以下两个组件： - 具体（即他们的用户绑定类而不是接口） - 很受欢迎（即它们被很多其他组件使用）。
流行是指稳定的概念。组件是稳定的，如果更改，它会破坏许多正在使用它的其他组件。总之：热门=稳定
另一个想法是接口比类更不受变化的影响。这就是为什么人们普遍认为最好使用界面而不是类，你没有机会被“静态”打破+你没有机会被“语义”打破，因为你的代码不应该是绑定任何实现细节（很容易受到更改）。
因此，具体+稳定会使组件面临一些潜在的开发难题：它很容易受到变化的影响+每次更改都可能会破坏大量代码。
在你的情况和其他一些情况下，进入痛苦区并不一定是坏事。重要的是要意识到这个事实+如果你的组件确实引起了痛苦，那么将你的代码回滚到接口。
答案 1 :(得分：3)
我认为Scott Hanselman撰写了一篇关于NDepend及其区域影响的相当冗长的帖子
http://www.hanselman.com/blog/ExitingTheZoneOfPainStaticAnalysisWithNDepend.aspx
正如他所说，我同意，在痛苦区域徘徊的集会不一定是坏事。但是，当决定使用另一个组件（COM或其他）来实现相同的功能层时，表示您需要进行更改。
要问的问题可能是，“我们有多大可能将这一层换成另一个框架/库？”